InsightSentry MCP

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

With no annotations provided, description carries full burden by disclosing return structure (pagination fields, data array schema), noting delay_seconds in response data, and explaining the dependency on get_crypto_screener_params. Lacks rate limits or auth details but covers essential behavioral traits.

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?

Information-dense and well-structured: leads with purpose, uses arrow notation (→) for return values, capitalizes WORKFLOW for scanability, and includes precise example. No wasted words despite covering 8 parameters plus return structure.

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 8 parameters, no annotations, and no structured output schema, description comprehensively fills gaps by documenting return object structure, pagination behavior, and explicit workflow. Minor gap regarding error handling or rate limiting prevents a 5.

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?

Despite 100% schema coverage (baseline 3), description adds significant value through concrete JSON example showing valid field combinations and sort syntax, plus workflow context linking fields parameter to the sibling discovery tool.

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 explicitly states 'Retrieve cryptocurrency data based on specified filter criteria' and distinguishes from siblings by noting 'country filtering NOT supported for crypto,' clearly delineating its domain against screen_stocks, screen_bonds, and screen_etfs.

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?

Provides explicit WORKFLOW with numbered steps (1. Call get_crypto_screener_params, 2. POST with chosen fields) and explicitly states limitations ('country filtering NOT supported'), giving clear prerequisites and when-not-to-use guidance.

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