Skip to main content
Glama
Sign In
nyc-charter-laws-rules

nyc-charter-laws-rules

by BetaNYC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

get_version

Returns the currency date for each NYC Charter, Administrative Code, and Rules document so you can confirm which version of the law grounds an answer before responding.

Instructions

Return the currency date for each document — how current the Charter, Administrative Code, and Rules are. Each corpus updates on its own schedule. Always call this tool before answering legal questions so responses are grounded in the correct version of the law. For informational purposes only. Not legal advice. Verify against official sources at codelibrary.amlegal.com before relying on any result.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.4

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the burden, and it does disclose the key behavior: results are per-corpus and can differ because each corpus updates on its own schedule. It also flags that output is informational, not legal advice, and should be verified against official sources. It does not describe error conditions or the exact return shape (e.g., date format per corpus), which keeps it short of 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 the purpose and the mandatory usage rule in the first three sentences. The trailing two sentences (informational-only, not-legal-advice, verify against official sources) are boilerplate but plausibly load-bearing for a legal-domain tool, so they cost little.

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 zero-parameter, no-output-schema tool this covers what an agent needs: what is returned (a currency date per corpus), why it matters, and when to call it. Only a hint at the concrete return format (per-corpus structure/date encoding) is missing, which is a minor gap.

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 tool takes no parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly signals the call needs no input by describing the operation as a global currency lookup across corpora.

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: 'Return the currency date for each document — how current the Charter, Administrative Code, and Rules are.' The added note that 'Each corpus updates on its own schedule' makes clear this is version/currency metadata, distinguishing it from the content-retrieval siblings (get_section, get_title, list_titles, search) without needing to name them.

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?

Gives an explicit, actionable trigger: 'Always call this tool before answering legal questions so responses are grounded in the correct version of the law.' For a zero-argument prerequisite tool this is exactly the routing instruction an agent needs, leaving little 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

Other Tools