Skip to main content
Glama
WillHsiaoNYC

NYC Open Data Capital Projects MCP Server

by WillHsiaoNYC

schedule_breakdown

Read-onlyIdempotent

Group NYC capital projects by agency, borough, phase, or category to count schedules or average variance, with role-aware attribution and deduplication by entity grain.

Instructions

Counts/averages of schedule metrics by agency/sponsor/borough/phase/category. agency scopes to one agency; agency_role ('auto'|'sponsor'|'managing') picks owner vs builder lens (auto: sponsor, except DDC/DCAS/EDC -> managing). Category grouping counts a PID once in EACH of its categories (non-additive). Report neutral, signed variance.

Interpretation rules:

  • [grain] Schedule questions use PID; budget questions use the BUDGET LINE key (managing_agency, fms_id). The same FMS ID under different holders is distinct lines. Schedule history is PID x reporting_period; budget history is budget line x reporting_period; fiscal-year budgets also key on fiscal_year. The schedule source has no fms_id; budget sources have no pid. The combined source repeats rows across PID-budget links and location splits: deduplicate at the requested entity grain before counting or summing. Never compare budgets using fms_id alone.

  • [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.

  • [agency_roles] Agency attribution is role-aware: an agency's projects mean its sponsor (owner) view, except DDC/DCAS/EDC default to managing (builder). State the returned agency_scope. managing_agency is the executor on schedules and the budget-holder on budgets; a budget-only holder is not a schedule executor. list_agencies exposes is_schedule_executor. For sponsor-scoped budget totals, use a semi-join to fms_sponsor; a value-bearing join can multiply lines. Co-owner totals can overlap and must not be added together.

  • [categories] Classify with the curated category_dim, not project-name searches: specific ten-year labels/FMS prefixes precede sponsor routing, then generic facility keywords and Other. Categories key on (managing_agency, fms_id); institution owner rules can use all-history ownership. Schedule category_scope='current' uses each PID's current funding links; 'all_history' includes former links. A PID can count in multiple categories, so schedule category counts are non-additive; each budget line has one category.

  • [signed_values] Report neutral, SIGNED changes: "moved 45 days later" or "budget decreased $2M". Do not echo loaded terms in the answer. "slippage" means positive schedule change and "overrun" means positive budget growth; neither includes the decreasing side. Preserve the returned direction and metric basis.

  • [schedule_coverage] Schedule totals and cumulative variance use dashboard-aligned schedule_history. source_schedule_history retains native observations absent from that population; schedule_source_coverage reconciles them. State the schedule universe and cumulative basis. Parenthesized phases are no-schedule reasons. Respect excluded variance artifacts and missing/invalid-duration counts; forward duration statistics exclude reversed dates.

  • [presence] Presence in a selected reporting snapshot means reportable at that period. There is no separate active flag. Historical presence or a latest-known row does not prove presence in the current complete snapshot. A completed project can retain an open budget line for years; presence does not mean construction is in progress.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agencyNo
metricNocount
periodNocurrent
group_byYes
statisticNocount
agency_roleNoauto

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupsYes
metricYes
periodYes
provenanceYes
interpretation_rulesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • addedInput schema / properties / agency_role / enum
      Added value: +[
      +  "auto",
      +  "sponsor",
      +  "managing"
      +]
    • addedInput schema / properties / group_by / enum
      Added value: +[
      +  "managing_agency",
      +  "sponsor_agency",
      +  "borough",
      +  "phase_norm",
      +  "lifecycle_status",
      +  "category"
      +]
    • addedInput schema / properties / metric / enum
      Added value: +[
      +  "count",
      +  "schedule_variance"
      +]
    • addedInput schema / properties / statistic / enum
      Added value: +[
      +  "count",
      +  "mean",
      +  "median",
      +  "sum",
      +  "min",
      +  "max"
      +]
    • 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": {
      +    "groups": {
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "title": "Groups",
      +      "type": "array"
      +    },
      +    "interpretation_rules": {
      +      "items": {
      +        "$ref": "#/$defs/InterpretationRule"
      +      },
      +      "title": "Interpretation Rules",
      +      "type": "array"
      +    },
      +    "metric": {
      +      "title": "Metric",
      +      "type": "string"
      +    },
      +    "period": {
      +      "title": "Period",
      +      "type": "string"
      +    },
      +    "provenance": {
      +      "additionalProperties": true,
      +      "title": "Provenance",
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "provenance",
      +    "interpretation_rules",
      +    "groups",
      +    "period",
      +    "metric"
      +  ],
      +  "title": "BreakdownResult",
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior5/5

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

Despite readOnlyHint/idempotentHint covering safety, the description adds substantial behavioral context: non-additive category counts, deduplication requirements at entity grain, signed variance direction conventions, defaulting to latest complete snapshot, and the distinction between schedule_history and source_schedule_history. This goes well beyond the annotations and is rich enough for a high score.

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

Conciseness2/5

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

The description is very long with a dense block of interpretation rules that resembles internal documentation rather than tool-selection guidance. Critical scoping information is buried after the opening, and the bulk of the rules concerns data-model semantics that are not strictly needed before invoking the tool.

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?

The tool has an output schema and rich annotations, but the description still supplies enough grain, period, and categorization semantics to call the tool correctly. It does not document the underlying data sources for the caller to reconcile beyond what it provides, leaving minor gaps for the six-parameter surface.

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 description coverage is 0% and six parameters are undocumented in the schema, so the description must compensate. It does so for several key parameters — agency_role values and auto-routing rules, period defaulting to latest snapshot, and the non-additive behavior of category grouping. It does not clarify the metric/statistic enum semantics (e.g., what 'sum' means on a variance field), leaving a gap.

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 specific verb (counts/averages) and resource (schedule metrics) plus the grouping dimensions for the scheduled breakdown. It is nearly indistinguishable in framing from the sibling budget_breakdown, but the schedule-metric focus and the explicit group_by dimensions differentiate it adequately for selection.

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 give extensive when-to-use context (segment grain, period basis, agency roles, category behavior), effectively telling the agent which analytical framing to apply. However, there is no explicit routing to siblings like budget_breakdown or rank_projects, so the agent must infer when this tool is preferable to alternatives.

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