Synapze — Financial Intermediary MCP

get_quote

Read-only

Tarification protection juridique / Generate a real legal protection insurance quote (protection juridique) from a licensed French broker's partner insurers. Returns indicative monthly and annual prices per formula.

Call find_broker first to get a broker_code, then get_products to see the available formulas. Only two client inputs are needed: age (in years) and French postal code. Never ask the client for a date of birth, an identity document, or any personal detail beyond these two — this connector does not accept them.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`age`	Yes	Client age in whole years (e.g. 40). Used for rating. Do NOT send a date of birth.
`budget`	No	Client's monthly budget in euros (e.g. 20). Results sorted by proximity to budget.
`show_all`	No	Return ALL quotes instead of top 5. Use only when the client asks for more options.
`broker_code`	No	Broker code returned by find_broker. Optional in broker-authenticated mode.
`postal_code`	Yes	French postal code, 5 digits (e.g. '75011'). Used for territorial rating.
`product_type`	No	Product type. Legal protection only — the sole product this connector covers.	protection_juridique
`formula_level`	No	Desired formula level, if the client already has a preference.
`coverage_areas`	No	Dispute areas the client wants covered: consumer, housing, employment, neighbourhood, automotive, digital, tax, administrative.

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Synapze — Financial Intermediary MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct role in the workflow: searching for a broker, retrieving broker branding/identity, listing products, and generating a quote. No two tools appear to overlap in purpose.

Naming Consistency5/5

All tool names follow the same lower_snake_case verb_noun pattern: find_broker, get_broker_info, get_products, get_quote. This makes the toolset easy to navigate and predict.

Tool Count5/5

The connector is narrowly scoped to legal protection insurance quotes, and four tools cover its core workflow without unnecessary bloat. Each tool earns its place in the flow.

Completeness5/5

The toolset covers the full intended workflow: find a broker, get broker branding/information, list the broker's legal protection products, and generate a quote. No update, delete, or document-generation tools are required for the connector's stated scope.

Resources

Need Help?