NYC Open Data Capital Projects MCP Server

by WillHsiaoNYC

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists between budget-related tools (e.g., budget_breakdown, budget_change, get_project_budget, rank_projects). Detailed descriptions help differentiate, but agents might occasionally misselect.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_agencies, get_project_budget, resolve_project_reference). No mixing of conventions.
Tool Count5/5
16 tools is appropriate for the domain, covering budget, schedule, agencies, categories, and a SQL interface. Not too few or too many.
Completeness4/5
The tool set covers most essential operations for capital projects data: breakdowns, changes, rankings, portfolio listing, reference resolution, and custom SQL. Minor gaps exist (e.g., no explicit tool for full project history), but the SQL interface fills many needs.
Average 3.7/5 across 16 of 16 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It hints at response fields ('CPD presence', 'schedule-executor flag') but does not clarify if the tool is read-only, filters, or returns a list. No disclosure of destructive potential or required auth.
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 short but not effectively concise; it uses unclear jargon without front-loading a clear verb and resource. The single sentence would be better replaced with a clearer explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and simple parameter, the description should provide complete context. It fails to describe what the tool returns, how the parameter works, or how it differs from sibling tools like list_categories. Extremely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'contains' with zero description coverage (0%). The tool description does not mention this parameter or explain its purpose, leaving the agent without guidance on how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Agency dictionary with live CPD presence + schedule-executor flag' is vague and jargon-heavy. It does not clearly state that the tool lists agencies, and the terms 'CPD presence' and 'schedule-executor flag' are unexplained, making the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like dataset_info or resolve_project_reference. The description lacks context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It lacks details on read/write nature, authentication, error handling, or side effects. Only mentions output fields and a note on budget state.
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?
Concise, with effective front-loading. Each sentence adds value, though slightly brief. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks essential details about output format, parameter semantics, and behavioral context. With no output schema and incomplete param coverage, the description is too sparse for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters fms_id or managing_agency. It only references 'FMS line' without connecting to parameters.
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?
Description clearly states it retrieves budget data for an FMS line including total, spend, variance, and lists linked schedules. However, it does not differentiate from sibling tools like budget_breakdown and budget_change, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The note about budget not having a 'completed' state is a contextual caveat but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It states the output fields but omits whether the operation is read-only, safe, or has side effects. There is no mention of permissions, rate limits, or error conditions.
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?
The description is very short and to the point, but the phrasing is awkward and somewhat cryptic. It conveys essential information in one sentence but sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists some return fields (phase, lifecycle, signed variance, reason, linked budgets), providing a partial picture. However, it does not explain the structure or relationships fully, leaving ambiguity about what 'linked budgets' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions PID in the text but does not describe what PID represents or its format. The description adds minimal value over the bare schema, lacking detail on constraints or usage.
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?
The description indicates the tool returns schedule data including phase, lifecycle, signed variance, reason, and linked budgets. It clearly identifies the resource (schedule) and the key fields, distinguishing it from generic project tools, but lacks an explicit verb like 'retrieve' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like schedule_breakdown or schedule_changes. The description does not mention prerequisites, alternatives, or context for use, leaving the agent without differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the 'as-of caveat' in results and explains the behavior of agency_role parameter. However, it does not mention auth requirements, rate limits, or whether the operation is read-only or destructive. The description adds some behavioral context but leaves gaps.
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?
The description is two sentences long, with the core purpose front-loaded. Each sentence provides useful information without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 5 parameters, and 0% schema coverage, the description should cover return format, period format, metric options, and any caveats. It mentions an 'as-of caveat' but doesn't specify the result structure. Key details about parameters like metric and period formatting are missing, making the description incomplete for precise invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the format for target ('agency:DEP' or 'fms:ABC') and the meaning of agency_role. However, it does not describe the exact format for from_period and to_period, or the allowed values for metric. The description adds some meaning beyond the schema but not enough to fully clarify all parameters.
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?
The description clearly states the tool calculates change in budget/spend between two periods for an agency or FMS line, with specific examples ('agency:DEP', 'fms:ABC'). However, it does not explicitly differentiate from sibling tools like budget_breakdown or get_project_budget, which might also relate to budget data.
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 description indicates when to use the tool (for agency or FMS line targets) and mentions the agency_role parameter, but it does not provide explicit guidance on when not to use it or how it compares to alternatives like budget_breakdown or schedule_changes, which are listed as siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'newly completed' and 'delayed' but lacks details on data freshness, pagination, limits, or side effects. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 3 required, no output schema, and no annotations, the description is too sparse. It lacks details on return format, all parameter semantics, and behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains agency and agency_role, but not from_period, to_period, or include_cancelled. Partially adds meaning but misses several parameters.
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?
Description clearly states it retrieves newly completed (DR1) or newly delayed projects between two periods, with a specific verb and resource. It distinguishes from sibling tools like schedule_breakdown.
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?
Description explains agency and agency_role parameters for scoping, but does not explicitly state when to use this tool vs alternatives like get_project_schedule or schedule_breakdown. Usage context is implied but not fully defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what information is returned (freshness, period, row counts, caveats), implying a read-only operation. However, it does not mention any additional behavioral traits such as performance, data recency, or required permissions, which would be valuable given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that lists the key pieces of information provided. Every word contributes to clarity without waste, earning a top score.
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 and no output schema, the description adequately conveys what the tool returns. It lacks details about the return format or whether it applies to a single dataset, but it is fairly complete for a simple metadata tool.
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 are defined in the input schema, so the description does not need to add parameter meaning. The baseline score of 4 is appropriate, as there is no burden to compensate for schema coverage.
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?
The description clearly states the tool provides per-dataset freshness, current period, row counts, and key caveats. It specifies the type of information, distinguishing it from sibling tools that focus on budgets, schedules, or other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. While sibling tools exist for other analyses, the description does not provide context or criteria for selecting dataset_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results are citywide by default and per-group with group_by, but does not mention behaviors like error handling when milestones are missing, read-only nature (implied but not stated), or limits on data volume. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and adding the optional parameter in the second sentence. No redundant words or restatements of the name. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description lacks detail on the return format (e.g., is it a list of durations, statistical summary?). It also does not cover edge cases like invalid milestone names or from_milestone after to_milestone. It is sufficient for simple use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the group_by parameter with explicit values and implies from_milestone and to_milestone are actual milestones needed in pairs. However, it does not define what 'actual' means or provide examples for milestone string values, leaving some ambiguity.
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?
The description clearly states the tool computes duration distribution between two actual milestones, specifying it requires both dates. It distinguishes from sibling tools like delay_reason_stats and schedule_breakdown by focusing on distribution between milestones rather than reasons or timeline views. However, it could be more specific about what 'distribution' means (e.g., histogram, percentiles).
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 description provides some guidance: it requires both dates and explains the optional group_by parameter with allowed values. It does not, however, mention when not to use this tool or suggest alternatives among the 16 siblings, nor does it clarify prerequisites like milestone existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It discloses that the tool echoes ranked_entity and agency_scope and explains agency_role default behavior. However, it does not mention safety traits (read-only, permissions) or response pagination/limitations, leaving some behavioral aspects unclear.
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?
The description is a single paragraph that efficiently conveys core functionality and key parameters. It is front-loaded with purpose and avoids filler. While a bullet list could improve scannability, every sentence contributes meaning, making it concise for the information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description only hints at return values ('Echoes ranked_entity' and 'agency_scope') without specifying format, fields, or pagination. For a complex tool with 10 parameters, this is a notable gap, though the behavioral details partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains several parameters (entity, rank_by, category, agency, agency_role) with concrete examples and default logic. However, it omits details for n, direction, min/max_total_budget, and delayed_only, so coverage is partial but adds value beyond schema.
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?
The description clearly states the tool ranks schedules or budgets based on entity and rank_by, with specific examples for budget rank_by values. It distinguishes between two entities (schedule and budget) and lists optional filters, making the purpose unambiguous and distinct from siblings.
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 description does not explicitly state when to use this tool versus alternatives like get_project_budget or schedule_breakdown. It implies usage for ranking but lacks 'when not to use' or comparative guidance, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides substantial behavioral context: agency_role logic, non-additive category counting, and signed variance. However, it omits details like required permissions or performance implications.
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?
The description is relatively concise and front-loaded with the main purpose, but the dense clauses could be better structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers key grouping and behavior nuances, it fails to explain several parameters and does not describe the output format, leaving gaps for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 'agency' and 'agency_role' are explained beyond schema names. 'group_by', 'metric', 'statistic', and 'period' lack description, leaving 4 of 6 parameters undocumented despite 0% schema coverage.
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?
The description clearly states it computes counts/averages of schedule metrics by specified grouping dimensions, distinguishing it from sibling tools like budget_breakdown which handle budget metrics.
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 description explains agency_role behavior and category grouping nuance, but does not explicitly state when to use this tool versus alternatives like budget_breakdown or delay_reason_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses dedup logic on (fms_id, managing_agency), granularity (line-grain additive), and the effect of agency_role options. It does not mention read-only status or error behaviors, but the provided details are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a third for the alternative. It is front-loaded with the main purpose, and every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no schema descriptions and no output schema, the description covers the core purpose, dedup logic, and two parameters. However, it omits details on metric and period, and the output format, leaving it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains agency and agency_role parameters explicitly, and implies group_by values. However, metric and period parameters are not described, leaving gaps.
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?
The description clearly states that the tool returns total budget/spend by managing_agency or category, with dedup logic and optional filtering. It distinguishes itself from the sibling tool run_sql, which is for richer queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use this tool (for simple budget breakdowns) and provides an alternative (run_sql for richer cuts). It does not explicitly exclude other sibling tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the distribution is only populated when variance>0, and explains the effects of the scope and agency_role parameters. However, it does not mention whether the operation is read-only, any required permissions, or potential side effects, though for a stats tool the behavioral assumption is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: purpose and condition, defaults and scope options, and agency_role explanation. No redundant or extraneous information; perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers inputs well and mentions the condition for data availability, it does not describe the output format (e.g., counts, percentages, structure). Since no output schema exists, the description should clarify what the tool returns to be fully complete for an agent.
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%, so the description must compensate. It explains period (default 'current'), scope ('all_history' for lifetime), and agency_role (three modes with lens interpretation). However, the 'agency' parameter is not mentioned, leaving one of four parameters undocumented. Overall, it adds significant value beyond the bare schema.
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?
The description clearly states it provides a 'distribution of reason-for-delay', which is a specific verb and resource. It also specifies the condition (variance>0) and differentiates by scope and agency_role, making its purpose unambiguous.
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 description gives usage defaults and options (current period, all_history, agency_role values) but does not explicitly state when to use this tool versus alternatives or when not to use it. Sibling tools like schedule_breakdown and schedule_changes suggest related but distinct purposes, yet no comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: ordering by nearest completion date with NULLs last, row content (schedule state, attributed_budget), summary coverage, and multi-borough matching. No contradictions.
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?
The description is a single, dense paragraph that front-loads the core purpose. Each sentence adds value, though some could be tightened. It is efficient for the given complexity.
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?
Despite no output schema or annotations, the description is thorough: it explains filtering, ordering, row content, summary details, and a behavioral nuance about borough matching. It is nearly complete for an agent to use correctly.
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?
With 0% schema description coverage, the description adds meaning for several parameters (category, lifecycle_status, borough matching, agency_role default). It explains filtering logic and references list_categories, though not all parameters are fully detailed.
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?
The description clearly states the tool lists projects (PIDs) with filtering and ordering options. It distinguishes from sibling tools by specifying it provides a cross-section listing with summary, not a budget breakdown or schedule detail.
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 description lists filter parameters but does not explicitly state when to use this tool versus alternatives like rank_projects or get_project_budget. Usage is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool returns field definitions with specific attributes, implying a read-only query. However, it lacks details on response format, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. The first sentence states the purpose and contents, the second explains parameter usage and special behavior (omitting both for full dictionary). Efficient and front-loaded.
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 no output schema, the description should ideally describe the return structure. It lists the contents (description, allowed values, etc.) but does not specify whether the output is an array, object, or key-value pairs. Still, it provides enough context for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds significant meaning: it specifies that 'field' accepts a column name or display name, and 'dataset' accepts a RAW table name or socrata_id. This clarifies the expected values beyond the schema's type definitions.
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?
The description clearly states the tool returns 'Official field definitions' and enumerates what they include (description, allowed values, primary/foreign key, limitations, notes). This distinctly identifies the tool's purpose and differentiates it from sibling tools that deal with budgets, projects, and schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two optional parameters and their usage, including the effect of omitting both (full dictionary). While it does not explicitly state when not to use this tool or compare to alternatives, the sibling tools are unrelated, making the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that categories are derived from ten_year_plan_category + sponsor_agency + fms-id prefix, and explicitly states what they are NOT based on (managing_agency or project name). This adds useful behavioral context beyond a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the output and then providing usage and derivation. Every sentence is informative with no waste.
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?
Given no parameters and no output schema, the description is complete: it specifies the output (categories with counts and total budget), how to use the result (filter for rank_projects), and the derivation logic. No missing information.
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?
There are no parameters, so the description needs to add no parameter info. With 0 parameters, the baseline is 4, and the description adequately explains the output without needing to elaborate on inputs.
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?
The description clearly states the tool lists program/facility categories with budget-line counts and total budget, with examples. It distinguishes itself by explaining how categories are derived and that they serve as filter values for rank_projects, differentiating from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (to retrieve categories with budget stats) and how to use its output (as a filter on rank_projects). It does not explicitly state when not to use or provide alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the mapping from identifier to data but does not mention any side effects, error handling, authentication requirements, or whether the tool is read-only. The lack of behavioral details limits transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value, making it highly concise and well-structured.
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 the tool has one required parameter, no output schema, and no annotations, the description explains the return value ('schedule+budget matches bucketed by entity') but does not specify the exact structure or error handling. It is fairly complete for a simple resolver, but could be improved by noting what happens when a query matches no project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'query' with no description (0% schema coverage). The description adds significant meaning by specifying what types of identifiers are accepted: PID, FMS ID, name, partial. This fully compensates for the missing schema description.
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?
The description clearly states the tool resolves any project identifier (PID, FMS ID, name, partial) into schedule and budget matches bucketed by entity. It explicitly mentions input types and output, and differentiates from siblings by advising to call this first for any named-project question.
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?
The description includes explicit guidance: 'Call this first for any named-project question.' This tells the agent when to use this tool before other project-specific tools like get_project_budget or get_project_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behaviors: read-only nature, output options with row caps and file writing, grain rules, and data type notes (VARCHAR). No contradictions.
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?
The description is front-loaded with the main purpose and well-structured, but it is lengthy. Most sentences add value, but some detail could be condensed.
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?
Given the complexity of a SQL tool with many tables, the description provides comprehensive context: table list, grain rules, period basis, and output options. It is complete for an agent to use correctly.
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?
The description adds meaning to the output parameter (inline/csv/xlsx) but does not describe the query parameter format or constraints. Given 0% schema coverage, the description compensates partially.
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?
The description clearly states it runs a read-only SELECT against a specific database. It distinguishes from sibling tools by being a general SQL interface, while siblings are specific analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance, including preferred tables, grain rules, period basis, and output options. However, it does not explicitly compare to alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

NYC-Opendata-Capital-Projects-MCP MCP server

Copy to your README.md:

[![NYC-Opendata-Capital-Projects-MCP MCP server](https://glama.ai/mcp/servers/WillHsiaoNYC/NYC-Opendata-Capital-Projects-MCP/badges/card.svg)](https://glama.ai/mcp/servers/WillHsiaoNYC/NYC-Opendata-Capital-Projects-MCP)

Score Badge

Copy to your README.md:

[![NYC-Opendata-Capital-Projects-MCP MCP server](https://glama.ai/mcp/servers/WillHsiaoNYC/NYC-Opendata-Capital-Projects-MCP/badges/score.svg)](https://glama.ai/mcp/servers/WillHsiaoNYC/NYC-Opendata-Capital-Projects-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/WillHsiaoNYC/NYC-Opendata-Capital-Projects-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server