Skip to main content
Glama
WillHsiaoNYC

NYC Open Data Capital Projects MCP Server

by WillHsiaoNYC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

dataset_info

Read-onlyIdempotent

Retrieve per-dataset freshness, current reporting period, row counts, and key caveats for NYC capital projects to choose accurate comparisons.

Instructions

Per-dataset freshness, current period, row counts, and the key caveats.

Interpretation rules:

  • [freshness] Reporting snapshots publish three times yearly (Jan/May/Sep, YYYYMM ending 01/05/09). Reporting periods, source revisions and ingestion timestamps are different clocks. dataset_info is local-only metadata, not an upstream freshness check. Use its available periods and complete snapshot information when choosing a comparison.

  • [period_basis] Reporting-period basis: state the returned period for every count, total or ranking and both periods for comparisons. Period aggregates default to the latest complete snapshot, which may precede a partially published newer period. fms_location, fms_sponsor and lifetime_budget_variance are all-history dimensions without reporting_period: use them for enrichment or lifetime figures, never as a single period's inventory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
caveatsYes
datasetsYes
provenanceYes
domain_rulesYes
interpretation_rulesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$defs": {
+    "InterpretationRule": {
+      "properties": {
+        "id": {
+          "description": "Stable identifier of the domain rule.",
+          "title": "Id",
+          "type": "string"
+        },
+        "text": {
+          "description": "Guidance for interpreting and reporting this tool's result.",
+          "title": "Text",
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "text"
+      ],
+      "title": "InterpretationRule",
+      "type": "object"
+    }
+  },
+  "additionalProperties": true,
+  "properties": {
+    "caveats": {
+      "items": {
+        "type": "string"
+      },
+      "title": "Caveats",
+      "type": "array"
+    },
+    "datasets": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "title": "Datasets",
+      "type": "array"
+    },
+    "domain_rules": {
+      "items": {
+        "type": "string"
+      },
+      "title": "Domain Rules",
+      "type": "array"
+    },
+    "interpretation_rules": {
+      "items": {
+        "$ref": "#/$defs/InterpretationRule"
+      },
+      "title": "Interpretation Rules",
+      "type": "array"
+    },
+    "provenance": {
+      "additionalProperties": true,
+      "title": "Provenance",
+      "type": "object"
+    }
+  },
+  "required": [
+    "provenance",
+    "interpretation_rules",
+    "datasets",
+    "domain_rules",
+    "caveats"
+  ],
+  "title": "DatasetInfoResult",
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world, so the description adds substantial value by disclosing that this is local-only metadata rather than an upstream check and that the latest period may precede a partially published snapshot. That is genuine behavioral context about data staleness and scope that annotations don't cover.

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

Conciseness3/5

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

Front-loads the summary line then two long bullet rules, which is reasonable, but the prose is dense and the rules are somewhat run-on, mixing several concepts per sentence. It is not excessively long but could be more scannable.

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

Completeness4/5

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

Given zero parameters, a rich output schema (so return format needn't be re-explained), and annotations covering safety, the description fills the remaining gap: how to interpret freshness and period basis. It is complete for the call itself, though it doesn't tie usage to specific sibling tools.

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?

No parameters, so the schema carries nothing and the description correctly focuses on output semantics. It describes the freshness and period_basis caveats that shape how returned values should be interpreted, which is appropriate use of the space.

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

Purpose4/5

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

States a specific resource (per-dataset metadata) and enumerates what it returns (freshness, period, row counts, caveats). It's clearly distinct from sibling tools like describe_table or run_sql, though the phrasing 'Per-dataset' isn't further elaborated on what a dataset is.

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

Usage Guidelines3/5

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

The interpretation rules imply when to use the returned periods ('use them for enrichment or lifetime figures, never as a single period's inventory') and warn it is local metadata, not an upstream freshness check. But it never explicitly states when to call dataset_info versus alternatives in the sibling list, nor gives a directive like 'call this before any aggregation'.

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

Deploy Server

Other Tools