Synapze — Financial Intermediary MCP

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds return field context (DDA compliance, endpoint) but does not disclose additional behavioral traits like rate limits, result limits, or authentication needs. It does not contradict annotations.

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 bilingual (FR/EN), making it longer but necessary for the target audience. It is front-loaded with the main purpose and structured clearly: search criteria and output. It could be slightly more concise by removing redundancy (e.g., repeating product list in both languages) but is generally efficient.

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?

For a search tool with 5 parameters and no output schema, the description adequately explains what the tool does and what it returns (broker name, specialties, DDA compliance, endpoint). It does not cover pagination or result limits, but given the moderate complexity and good annotations, it is sufficiently complete.

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?

The input schema has 100% description coverage for all 5 parameters, so the schema already explains each parameter. The tool description lists search criteria (product, city, language) and examples but adds no new meaning beyond the schema. Baseline 3 is appropriate.

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 that the tool finds licensed insurance brokers in France, specifying search criteria (product, city, language) and output (name, specialties, DDA compliance, connection endpoint). It is distinct from siblings like get_broker_info (specific broker info) and get_quote (quotes).

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 provides clear context for when to use the tool (find a broker by product, city, language) and implies its search nature. However, it does not explicitly state when not to use it or mention alternatives like get_broker_info for known brokers. Still, the purpose is clear enough to guide usage.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so description adds limited behavioral context beyond listing return fields. Does not disclose additional traits like auth requirements or rate limits.

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?

Front-loaded with purpose, lists returned fields, then provides a clear usage instruction. Every sentence is earned; no waste.

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?

Despite no output schema, the description enumerates all return fields and explains when to call. Adequate for a simple info retrieval tool.

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 100%, and the tool description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate.

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 it returns broker information and branding, listing specific fields. It distinguishes from sibling tools (find_broker searches, this retrieves 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?

Explicitly states to always call this before generating any document (PDF, PPTX, etc.) to brand it with broker's logo, color, etc. Provides clear context on when to use.

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

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

Annotations already indicate readOnlyHint, so the description adds the return content (eligibility, coverage, pricing) and the category requirement. However, it does not disclose additional behavioral traits like pagination or permissions.

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 with two functional sentences and a list of categories. No wasted words; front-loaded with purpose.

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 no output schema, the description sufficiently outlines what is returned (eligibility, coverage, pricing). It lacks details on broker_code usage but overall covers the core functionality.

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 the description adds little beyond the schema. It reinforces the category requirement but does not elaborate on broker_code usage.

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 lists insurance products with eligibility criteria, coverage details, and pricing. It specifies the required category and enumerates all valid categories, distinguishing it from siblings like get_quote.

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 implies usage for listing products but does not explicitly state when to use this tool over alternatives (e.g., get_quote for quotes). No when-not-to-use guidance is provided.

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

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

Description adds behavioral context beyond annotations: 'Returns monthly prices per product and level. No PII stored or returned' and explains sorting by budget proximity and show_all behavior. Annotations already indicate read-only (readOnlyHint=true), so the description complements them well.

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?

Description is well-structured with a clear main statement, an important note, and organized examples. It is relatively long but each sentence serves a purpose. Slightly verbose due to extensive examples, but front-loaded with key info.

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 12 parameters, nested product_data, and no output schema, the description is highly complete. It explains all key parameters, required fields, behavioral notes (budget sorting, show_all), and provides concrete examples. No critical gaps.

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%, but description adds significant value with detailed product_data examples per product_type (auto, moto, mrh, etc.), which goes beyond the schema's generic description. This helps the agent construct correct input parameters.

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 generates real insurance quotes from partner APIs for various products. The verb 'generate' and resource 'insurance quotes' are specific. Sibling tools (find_broker, get_products) have distinct purposes, making the tool's function unambiguous.

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 guidance: 'birth_date + postal_code are REQUIRED for all products' and 'Call get_products first to see quoteRequirements.guidance'. This tells the agent when to use the tool and what prerequisites are needed. Lacks explicit when-not-to-use but alternatives are implicitly covered by sibling tools.

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