Skip to main content
Glama

Table Data

table_data
Read-onlyIdempotent

Fetch the time-series data rows for a Singapore statistics table. Pass resourceId ONLY if you already have a real one from a prior search_tables/table_metadata call. Otherwise pass search with the topic in plain words (e.g. "resident unemployment rate", "gdp by industry") and this tool resolves the best-matching table itself — the response carries a resolved field naming exactly which table id and title were used, so NEVER guess or reuse an id you saw in an example; it is almost certainly for a different table. Data is returned under Data with a row array of series, each containing dated columns. Filter time periods with timeFilter (comma-separated periods like "2020,2021") or between (a from,to range like "2010,2020"); page with offset/limit.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "resourceId": "M810001"
    },
    "name": "table_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax number of rows to return.
offsetNoNumber of rows to skip (pagination).
searchNoFree-text topic to resolve a resourceId automatically when you do not already have one, e.g. "resident unemployment rate". Ignored if `resourceId` is given. Equivalent to calling search_tables yourself and picking the closest title match.
sortByNoSort expression, e.g. "rowtext asc".
betweenNoInclusive period range "from,to", e.g. "2010,2020".
resourceIdNoA table id you already have (from search_tables or table_metadata). Omit this and use `search` instead when you only know the topic, not a real id — do not invent or copy one from an unrelated example.
timeFilterNoComma-separated specific periods to return, e.g. "2020,2021,2022".
seriesNoORrowNoNoComma-separated series/row numbers to limit which series are returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / examples
      Previous value: -[
      -  {
      -    "resourceId": "M810001"
      -  },
      -  {
      -    "limit": 10,
      -    "resourceId": "M810001",
      -    "timeFilter": "2020,2021,2022"
      -  }
      -]New value: +[
      +  {
      +    "resourceId": "M810001"
      +  },
      +  {
      +    "limit": 10,
      +    "resourceId": "M810001",
      +    "timeFilter": "2020,2021,2022"
      +  },
      +  {
      +    "search": "resident unemployment rate"
      +  }
      +]
    • changedInput schema / properties / resourceId / description
      Previous value: -"Table id from search_tables, e.g. \"M810001\"."New value: +"A table id you already have (from search_tables or table_metadata). Omit this and use `search` instead when you only know the topic, not a real id — do not invent or copy one from an unrelated example."
    • addedInput schema / properties / search
      Added value: +{
      +  "description": "Free-text topic to resolve a resourceId automatically when you do not already have one, e.g. \"resident unemployment rate\". Ignored if `resourceId` is given. Equivalent to calling search_tables yourself and picking the closest title match.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "resourceId"
      -]New value: +[]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "resourceId": "M810001"
      +  },
      +  {
      +    "limit": 10,
      +    "resourceId": "M810001",
      +    "timeFilter": "2020,2021,2022"
      +  }
      +]
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent/non-destructive, but the description adds real behavioral context beyond them: the response carries a `resolved` field naming the table used, data lives under `Data` with a `row` array, and it warns not to guess or reuse ids from examples. It does not mention rate limits or auth, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and then the id-vs-search decision, then return shape and filtering. It is dense but every sentence carries actionable information; the id-guessing warning is emphatic but justified given the risk of wrong-table results.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully explains the return shape (`Data`/`row`/`columns`) and the `resolved` field, and covers filtering and pagination. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds relational meaning: search is ignored when resourceId is given, and timeFilter (discrete periods) is contrasted with between (a from,to range) plus pagination via offset/limit. That clarifies how the parameters interact beyond their individual schema docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Fetch) and resource (time-series data rows for a Singapore statistics table). It is clearly distinguishable from search_tables and table_metadata, which it names as upstream sources for the id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to pass resourceId ONLY with a real id from a prior search_tables/table_metadata call and otherwise use search with plain words. It gives concrete topic examples and names the alternatives, so an agent knows exactly when to use which path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.