CongressMCP-full

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal detail. It mentions 'Returns professional-grade research data' but does not disclose rate limits, caching behavior, authentication requirements, or whether operations are read-only versus mutating. The mention of 'enhanced analytics' is vague without quantitative or qualitative context.

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 structure uses clear section headers and bullet points, which aids scannability. However, the opening sentence repeats the title verbatim, and the six operation bullets consume space without explicitly mapping to the required 'operation' parameter values. The 'Key params' line at the end is redundant given the schema already lists parameter names.

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 10 parameters with zero schema documentation and a required 'operation' switch parameter, the description is incomplete. It fails to specify valid values for the 'operation' parameter (critical for invocation), explain parameter dependencies, or document the four parameters not mentioned in the 'Key params' list. While an output schema exists (reducing the need for return value documentation), the input contract remains severely under-specified.

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 description coverage is 0% (all ten parameters lack descriptions), requiring the description to compensate heavily. While it lists six operation names that presumably map to the 'operation' parameter, it does not explicitly state these are valid enum values, nor does it explain which parameters apply to which operations (e.g., does 'report_number' work with 'get_congress_info'?). The other four parameters (current, limit, detailed, format_type) are completely undocumented.

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 identifies the resource domain (CRS reports, Congress analytics) and lists six specific operations, but frames the tool as a generic 'Access' mechanism rather than clarifying it acts as a router/switch based on the 'operation' parameter. It does not effectively distinguish from siblings like 'bills' or 'committee_intelligence' which also access congressional data, leaving ambiguity about when to use this aggregate tool versus specific alternatives.

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 guidance on when to use this tool versus the seventeen sibling tools (e.g., when to use 'search_crs_reports' via this tool versus other research tools). No mention of prerequisites, required parameter combinations, or workflow context. The six operation bullets imply capabilities but do not constitute usage guidelines.

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