About this server

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

The description discloses that the default response is compact (<1KB) and that `section` expands specific slices. The annotations already indicate read-only, idempotent, non-destructive behavior, so the description adds value by detailing the response size and expansion mechanism, but it could mention that the tool returns metadata about the server itself, which is already clear from the purpose.

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

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

The description is concise and well-structured, front-loading the core purpose and then detailing optional expansions. It could be slightly more concise by trimming the parenthetical list of sections, but it remains efficient overall.

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

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

Given the tool's simplicity with only 2 optional parameters, an output schema exists, and annotations cover safety, the description is complete. It explains all behaviors, parameter interactions, and distinguishes from `list_jurisdictions`. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already documented. The description adds context by explaining the default behavior when no section is provided and how the 'jurisdiction' parameter is used conditionally with section='jurisdiction'. However, it repeats some schema description details, like the enum list, which are already in the schema.

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

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

The description clearly states the tool provides a compact self-description of the server including name, version, jurisdiction codes, tool names, pricing, and rate limits. It also explains optional expansion via the `section` parameter, differentiating its purpose from the sibling `list_jurisdictions` which provides per-jurisdiction schema details.

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

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

The description explicitly tells when to use this tool (for a compact self-description) and when to prefer an alternative (`list_jurisdictions` for full per-jurisdiction schema). It also explains how to use the `section` parameter to expand specific slices, including the 'jurisdiction' section combined with the `jurisdiction` parameter.

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