CongressMCP-full

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

No annotations provided, so description carries full burden. It adds return value semantics ('Member who represented...') and implies read-only lookup, but lacks disclosure on error behavior (e.g., invalid district numbers), rate limits, or whether the member object includes full biographical details or just identifiers.

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?

Uses efficient docstring format with Args and Returns sections. Every sentence earns its place: opening line defines purpose, Args section provides examples for all parameters, Returns clarifies the single object response. No redundant or wasted language.

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?

Adequate for a lookup tool with output schema present. Covers all parameters and basic return semantics. Minor gap: does not specify behavior for invalid combinations (e.g., non-existent district numbers) or whether the tool validates that the district existed in that Congress.

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?

With 0% schema description coverage, the description fully compensates by documenting all three parameters with concrete examples (e.g., '118 for 118th Congress', 'CA', 'TX', 'NY') and clarifying constraints (two-letter state code, district number within state) that the schema does not provide.

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?

Description clearly states the tool retrieves 'the member representing a specific congressional district in a specific Congress' with specific verb (Get) and resource (member). The parameter combination (congress+state+district) inherently distinguishes it from siblings like get_members_by_congress (all members) or get_members_by_state (state-wide).

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?

No explicit when-to-use or alternative recommendations provided. While the specific parameter combination implies usage for targeted historical lookups versus bulk retrieval, the description does not explicitly contrast with siblings like get_members_by_district or note that this returns a single member versus lists from other endpoints.

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