docs(mcp): update get_observations and get_child_observations response schema to tabular format in researcher skills

[premr]

Summary

This PR updates the response schema documentation in the MCP skill playbooks:

• data-commons-child-places-researcher/SKILL.md (Section 9)
• data-commons-researcher/SKILL.md (Section 8)

Context & Problem

Currently, the researcher skills describe the response structure for get_observations and get_child_observations using a legacy placeObservations format:

{
  "variable": { "dcid": "...", "name": "..." },
  "placeObservations": [
    {
      "place": { "dcid": "...", "name": "...", "typeOf": [...] },
      "timeSeries": [{ "date": "2024", "value": 5.4 }]
    }
  ]
}

However, the live Agent API and MCP server return a compact, dual-table tabular format:

{
  "variable": { ... },
  "sourceMetadata": { ... },
  "alternativeSources": [],
  "entityMetadata": [
    ["geoId/06037", "Los Angeles County", ["County"]]
  ],
  "data": {
    "columns": ["observationAbout", "date", "value"],
    "rows": [
      ["geoId/06037", "2024", 5.4]
    ]
  }
}

This mismatch causes LLMs and autonomous agents following the skill instructions to write parsers targeting placeObservations and timeSeries, leading to unexpected parsing failures and 0 results errors.

Changes

• Updated Section 8 of data-commons-researcher/SKILL.md to document the entityMetadata and data.columns / data.rows structure.
• Updated Section 9 of data-commons-child-places-researcher/SKILL.md to document the same tabular dual-table structure.
• Aligned both skill documents with data-commons-multi-entity-researcher/SKILL.md (which already references the dual-table format).

[gemini-code-assist]

Code Review

This pull request updates the documentation in the SKILL.md files for both get_child_observations and get_observations responses to reflect a new uniform dual-table structure consisting of entityMetadata and a data table. The review feedback correctly identifies that the JSON examples in both files use sourceId (camelCase), whereas the underlying Pydantic model defines this field as source_id (snake_case) without an alias, and suggests updating the examples to ensure consistency with the actual API serialization.

[premr]

Fixing the MCP related skills so that the response example in skill://data-commons-child-places-researcher/SKILL.md to reflect data.rows and data.columns rather than placeObservations objects

[keyurva]

Thanks for the fix!

[keyurva]

Can you update entityMetadata so it is structured as an object with columns and rows to match the live API?

Testing against the live endpoint returns:

  "sourceMetadata": {
    "sourceId": "10031152674915191256",
    "measurementMethod": "BLSSeasonallyUnadjusted",
    "observationPeriod": "P1M",
    "provenanceUrl": "https://www.bls.gov/lau/"
  },
  "entityMetadata": {
    "columns": ["dcid", "name", "typeOf"],
    "rows": [
      ["geoId/06037", "Los Angeles County", ["AdministrativeArea2", "County", "Place"]],
      ["geoId/06075", "San Francisco County", ["AdministrativeArea2", "County", "Place"]]
    ]
  }

Notice also that sourceMetadata uses camelCase sourceId rather than source_id.

[keyurva]

Can we clarify the subfield breakdown for entityMetadata similarly to data? For example:

* **`entityMetadata`**: Matrix of child entity metadata:
  * `columns`: Array of column names (`dcid`, `name`, `typeOf`).
  * `rows`: Tabular arrays of `[child_dcid, entity_name, entity_types]`.

[premr]

Better? Fixed and added the enumeration in both places.