nyc-charter-laws-rules

search

Find matching NYC Charter, Administrative Code, and Rules sections using short keywords or exact phrases, with relevance-ranked results by heading, citation, and body text.

Instructions

Keyword search across the NYC Charter, Administrative Code, and Rules of the City of New York. This is keyword matching, not a question-answering engine: short keyword queries work best (e.g. 'sidewalk shed', 'water tank inspection'), not full questions. The query is first matched as an exact phrase (quotes around the whole query are removed first); results are relevance-ranked, with heading matches above citation matches above body-text matches, and whole-word matches above substring matches. If the phrase matches nothing, question words and common words are dropped and sections containing the remaining terms are returned, those with every term first; the response's first line says when this happened and which terms were used. For informational purposes only. Not legal advice. Verify against official sources at codelibrary.amlegal.com before relying on any result.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max results to return (default 10, max 50)
`query`	Yes	Keywords or an exact phrase (short keyword queries work best)
`corpus`	No	Which document to search (default: all)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.4Nov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so well: it discloses the exact-phrase-first strategy, quote stripping, the ranking hierarchy (heading > citation > body, whole-word > substring), and the term-dropping fallback. It further explains that the response's first line reports when the fallback fired and which terms were used, which is non-obvious behavior an agent cannot get from the schema.

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, then query guidance, ranking, fallback, and finally the required legal disclaimer. The ranking/fallback sentences are dense but each conveys operative behavior; the legal boilerplate is mandated rather than wasted, though it could be compressed.

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?

For a three-parameter search tool with no output schema and no annotations, the definition covers matching strategy, ranking, fallback, and the response's signaling line. It stops short of describing what a result record contains (citation, heading, snippet), which the agent must discover by calling.

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 a baseline of 3 applies, but the description genuinely adds meaning beyond it: it explains that quotes around the whole query are stripped before phrase matching and that keyword-style queries outperform natural-language ones. Only the query parameter is enriched this way; limit and corpus behavior is left entirely to their schema descriptions.

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 and resource set: 'Keyword search across the NYC Charter, Administrative Code, and Rules of the City of New York.' The explicit 'keyword matching, not a question-answering engine' framing makes the modality unambiguous and clearly separates it from the get_section/get_title/list_titles siblings, which are retrieval-by-identifier 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?

Gives concrete when-to-use guidance with example queries ('sidewalk shed', 'water tank inspection') and rules out full-question phrasing. It does not, however, name an alternative for cases where the agent already knows a section or title identifier, so routing between this and the get_* siblings is left to inference.

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

Deploy Server