Synapze — Financial Intermediary MCP

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint:false, but the description adds meaningful behavioral specifics: the tool returns a payload that includes an 'endpoint to quote with', and the connector is explicitly limited to French legal protection insurance. These behaviors are not inferable from the annotations or the tool title, so the description earns credit beyond the disclosure.

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?

Two compact bilingual sentences carry the full payload: purpose, search dimensions, return values, and scope. The most important information is front-loaded and every clause earns its place. There is no fluff or repetition outside the intentional language replica.

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 read-only search tool with full parameter documentation and rich annotations, the description is nearly complete: it names the return payload and the exact scope of the connector. It does not clarify how to consume the returned 'endpoint to quote with' or how ticket and sub_specialty affect search results, but those are edge details for the core broker-lookup invocation.

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 schema description coverage is 100%, so the baseline is 3. The description reinforces city/language as the primary search dimensions and restates that only protection_juridique is valid, which slightly amplifies the product field's semantics. It does not add meaningful explanation about ticket or sub_specialty beyond what the schema already provides, so it does not push above the baseline.

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 uses a specific verb ('find') with a concrete resource ('a licensed French insurance broker for legal protection insurance') and defines scope via search dimensions (city and language) and return payload (broker name, city, regulatory status, endpoint to quote with). The exclusivity statement ('Legal protection is the only product this connector covers') helps distinguish it from broader insurance or product-shopping tools, though it does not explicitly name sibling tools like get_broker_info.

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?

There is a clear implied use case: search for a broker in a city/language, and the product exclusivity provides a partial exclusion ('only legal protection'). However, it never explicitly points to alternatives such as get_products or get_quote, nor tells the agent when this tool should not be used in favor of a sibling. The routing is left implicit.

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?

The description discloses exactly what the tool returns: name, logo URL, brand color, address, phone, ORIAS number, specialties, and DDA compliance status. The annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds operational context by explaining the returned values are used for document branding.

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 front-loaded with the tool's purpose and return fields, and the ALWAYS guidance is valuable. There is minor redundancy between the bilingual opening and the repeated branding fields in the final sentence, but overall it remains efficient and readable.

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 simple input (one optional parameter), no output schema, and annotations covering safety, the description provides a complete picture: what the tool returns, why it matters, and when the agent must call it. No critical piece of context is missing.

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 schema already documents broker_code well, including its source (find_broker) and that it is optional in broker-authenticated mode. With 100% schema description coverage, the description does not need to add much parameter-level detail, and it does not.

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 identifies the tool as the source for broker branding and identity, with a specific list of returned fields. It distinguishes itself from siblings (get_products, get_quote) and pairs naturally with find_broker by mentioning broker_code. The intended use case — document branding — is explicit and meaningful.

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 strong, explicit guidance: 'ALWAYS call this before generating any document'. It places the tool correctly in the workflow but does not explicitly mention when not to use it or compare it against alternatives beyond the broker_code connection. This is clear context without formal exclusions.

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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so a safe read-only behavior is established. The description adds useful context beyond annotations by specifying the returned scope: 'formulas, eligibility criteriaand coverage details' and Amazon's role, which helps agents understand the behavioral emphasis on catalogue listing.

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 compact: a two-sentence format with both the purpose and a usage note about get_quote. The bilingual repetition of 'protection juridique' is a minor redundancy, but it does not harm readability or decision-making.

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 simple read-only/list tool with both endpoint parameters clearly documented and strong annotations, the description gives enough context to call it confidently: it names the broker scope, the category of products, and the workflow position relative to get_quote. No output schema is present, but the description compensates by naming the key data domains.

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%, and the schema already clearly documents both category and broker_code, including aliases and the broker-authenticated mode. The description does not add meaningful endpoint-specific or parameter formatting behavior beyond what the schema provides, so the baseline score of 3 applies.

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 a specific verb and resource: 'List a broker's legal protection products (protection juridique)' with formulas, eligibility criteria, and coverage details. It also distinguishes itself from get_quote by explaining it provides the catalogue that precedes quoting.

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 says 'Call this before get_quote to see which formulas the broker distributes,' giving a clear sequencing/usage rule and context within the workflow. It does not explicitly explain when not to use it versus siblings like get_broker_info, so it stops short of a fully explicit all-alternatives comparison.

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?

Even though annotations already declare readOnlyHint and destructiveHint, the description adds meaningful behavioral detail: it produces real indicative quotes from partner insurers, returns monthly and annual prices, enforces broker dependency, and refuses extra personal data. This goes well beyond what the annotations alone provide.

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 compact, front-loaded with the core purpose, and uses complementary sentences to convey prerequisites and client-input limitations. No sentence is wasted, and the structure proceeds logically from what the tool does, to how to use it, to guarding against inappropriate inputs.

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?

Even without an output schema, the description states the key return information (indicative monthly and annual prices per formula) and gives enough about required inputs and prerequisites for an agent to invoke the tool correctly. It also provides privacy/behavioral context that is especially useful for an external data connector.

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 schema already documents each parameter. The description adds valuable operational semantics by narrowing the client-facing inputs to age and postal code, and by prohibiting unnecessary personal information. It doesn't redundantly redefine each parameter, which is appropriate given the schema coverage.

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 states exactly what the tool does: generate a real legal protection insurance quote from French partner insurers and return monthly/annual prices per formula. It clearly differentiates the tool from its siblings by describing the quote generation step after find_broker and get_products.

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 gives explicit sequencing guidance: call find_broker first to obtain broker_code, then get_products to see available formulas, then this tool. It also explains the only client inputs required and what the agent must never ask for, giving strong when-to-use and when-not-to-use direction.

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