Skip to main content
Glama

Synapze — Financial Intermediary MCP

by eu.synapze
OverviewDiscussionsAdmin

Server Details

Connect AI agents to licensed financial intermediaries in France: insurance, credit, wealth.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 36 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 4 tools

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.

Available Tools

4 tools
find_brokerA
Read-onlyIdempotent
Inspect

Trouver un courtier en protection juridique / Find a licensed French insurance broker for legal protection insurance (protection juridique). Search by city and language. Returns broker name, city, regulatory status and the endpoint to quote with. Legal protection is the only product this connector covers.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoCity or zone in France (e.g. 'paris', 'lyon', 'marseille')
ticketNoProject amount in EUR (for routing large-ticket cases)
productNoInsurance product. Legal protection only: 'protection_juridique' (alias 'pj').protection_juridique
languageNoPreferred language: fr, enfr
sub_specialtyNoSub-specialty niche within the product (e.g. 'architectes', 'sci_is', 'dirigeants')

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

get_broker_infoA
Read-onlyIdempotent
Inspect

Informations et branding du courtier / Broker branding and identity. Returns: company name, logo URL, brand color (#hex), address, postal code, phone, ORIAS number, website, specialties, and DDA compliance status. ALWAYS call this before generating any document (PDF, PPTX, comparison, advisory note) to brand it with the broker's logo, color, name, address, and ORIAS number.

ParametersJSON Schema
NameRequiredDescriptionDefault
broker_codeNoBroker code returned by find_broker. Optional in broker-authenticated mode.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_productsA
Read-onlyIdempotent
Inspect

Catalogue protection juridique / List a broker's legal protection products (protection juridique) with their formulas, eligibility criteria and coverage details. Call this before get_quote to see which formulas the broker distributes.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoProduct category. Legal protection only: 'protection_juridique' (alias 'pj').
broker_codeNoBroker code returned by find_broker. Optional in broker-authenticated mode.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_quoteA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
ageYesClient age in whole years (e.g. 40). Used for rating. Do NOT send a date of birth.
budgetNoClient's monthly budget in euros (e.g. 20). Results sorted by proximity to budget.
show_allNoReturn ALL quotes instead of top 5. Use only when the client asks for more options.
broker_codeNoBroker code returned by find_broker. Optional in broker-authenticated mode.
postal_codeYesFrench postal code, 5 digits (e.g. '75011'). Used for territorial rating.
product_typeNoProduct type. Legal protection only — the sole product this connector covers.protection_juridique
formula_levelNoDesired formula level, if the client already has a preference.
coverage_areasNoDispute 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedfind_broker3 fields changed
      • addedInput schema / properties / product / default
        Added value: +"protection_juridique"
      • changedInput schema / properties / product / description
        Previous value: -"Insurance product type: auto, moto, mrh, rc_pro, protection_juridique, epargne, assurance_vie, per"New value: +"Insurance product. Legal protection only: 'protection_juridique' (alias 'pj')."
      • removedInput schema / required
        Removed value: -[
-  "product"
-]
    • Changedget_products1 field changed
      • changedInput schema / properties / category / description
        Previous value: -"Product category filter: auto, moto, mrh, rc_pro, protection_juridique, epargne, assurance_vie, per"New value: +"Product category. Legal protection only: 'protection_juridique' (alias 'pj')."
    • Changedget_quote18 fields changed
      • addedInput schema / properties / age
        Added value: +{
+  "description": "Client age in whole years (e.g. 40). Used for rating. Do NOT send a date of birth.",
+  "maximum": 100,
+  "minimum": 18,
+  "type": "integer"
+}
      • removedInput schema / properties / birth_date
        Removed value: -{
-  "description": "Client birth date in YYYY-MM-DD format (e.g. '1988-05-15')",
-  "type": "string"
-}
      • changedInput schema / properties / budget / description
        Previous value: -"Client's monthly budget in euros (e.g. 80). Results sorted by proximity to budget."New value: +"Client's monthly budget in euros (e.g. 20). Results sorted by proximity to budget."
      • removedInput schema / properties / children
        Removed value: -{
-  "description": "Children details for family coverage",
-  "items": {
-    "properties": {
-      "birth_date": {
-        "description": "Child birth date YYYY-MM-DD",
-        "type": "string"
-      },
-      "gender": {
-        "description": "Child gender: M or F",
-        "type": "string"
-      }
-    },
-    "required": [
-      "birth_date"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}
      • addedInput schema / properties / coverage_areas
        Added value: +{
+  "description": "Dispute areas the client wants covered: consumer, housing, employment, neighbourhood, automotive, digital, tax, administrative.",
+  "items": {
+    "enum": [
+      "consumer",
+      "housing",
+      "employment",
+      "neighbourhood",
+      "automotive",
+      "digital",
+      "tax",
+      "administrative"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / formula_level
        Added value: +{
+  "description": "Desired formula level, if the client already has a preference.",
+  "enum": [
+    "essentielle",
+    "etendue",
+    "complete"
+  ],
+  "type": "string"
+}
      • removedInput schema / properties / gender
        Removed value: -{
-  "description": "Gender: M or F",
-  "type": "string"
-}
      • removedInput schema / properties / has_spouse
        Removed value: -{
-  "description": "Whether the client has a spouse/partner to cover",
-  "type": "boolean"
-}
      • removedInput schema / properties / number_of_children
        Removed value: -{
-  "description": "Number of children to cover",
-  "type": "number"
-}
      • changedInput schema / properties / postal_code / description
        Previous value: -"French postal code (e.g. '75008', '92150'). Required for all products."New value: +"French postal code, 5 digits (e.g. '75011'). Used for territorial rating."
      • addedInput schema / properties / postal_code / pattern
        Added value: +"^\\d{5}$"
      • removedInput schema / properties / product_data
        Removed value: -{
-  "additionalProperties": {},
-  "description": "Product-specific data object. Fields depend on product_type — see description above for examples per product. Call get_products first to see quoteRequirements.guidance for the exact fields to collect.",
-  "propertyNames": {
-    "type": "string"
-  },
-  "type": "object"
-}
      • addedInput schema / properties / product_type / default
        Added value: +"protection_juridique"
      • changedInput schema / properties / product_type / description
        Previous value: -"Product type: auto, moto, mrh, rc_pro, protection_juridique (pj), epargne, assurance_vie, per"New value: +"Product type. Legal protection only — the sole product this connector covers."
      • addedInput schema / properties / product_type / enum
        Added value: +[
+  "protection_juridique",
+  "pj"
+]
      • changedInput schema / properties / show_all / description
        Previous value: -"Return ALL quotes instead of top 5. Use only when client asks for more options."New value: +"Return ALL quotes instead of top 5. Use only when the client asks for more options."
      • removedInput schema / properties / spouse_birth_date
        Removed value: -{
-  "description": "Spouse birth date in YYYY-MM-DD format",
-  "type": "string"
-}
      • changedInput schema / required
        Previous value: -[
-  "product_type",
-  "birth_date"
-]New value: +[
+  "age",
+  "postal_code"
+]
  2. 16 tool updates
    • Removedbook_appointment
    • Removedbulk_quote
    • Removedcheck_coverage
    • Removeddownload_quote_pdf
    • Changedfind_broker1 field changed
      • changedInput schema / properties / product / description
        Previous value: -"Insurance product type: mrh, rc_pro, sante, sante_internationale (international health/expat/WHV), prevoyance, auto, epargne"New value: +"Insurance product type: auto, moto, mrh, rc_pro, protection_juridique, epargne, assurance_vie, per"
    • Removedget_client_360
    • Removedget_hot_leads
    • Removedget_product_details
    • Removedget_product_template
    • Changedget_products1 field changed
      • changedInput schema / properties / category / description
        Previous value: -"Product category filter: mrh, rc_pro, sante, sante_internationale, prevoyance, auto, epargne"New value: +"Product category filter: auto, moto, mrh, rc_pro, protection_juridique, epargne, assurance_vie, per"
    • Changedget_quote8 fields changed
      • removedInput schema / properties / coverage_zone
        Removed value: -{
-  "description": "Coverage zone for sante_internationale: monde_usa, monde_hors_usa, europe, asie_oceanie, ameriques.",
-  "type": "string"
-}
      • removedInput schema / properties / departure_date
        Removed value: -{
-  "description": "Coverage start date YYYY-MM-DD for sante_internationale. Defaults to 30 days from now.",
-  "type": "string"
-}
      • removedInput schema / properties / destination_country
        Removed value: -{
-  "description": "Destination country (e.g. 'Canada', 'Australie', 'Thailand'). REQUIRED for sante_internationale.",
-  "type": "string"
-}
      • removedInput schema / properties / insurance_regime
        Removed value: -{
-  "description": "Insurance regime for sante_internationale: premier_euro, complement_cfe, complement_secu, etudiant. Do NOT confuse with 'regime' (French social security).",
-  "type": "string"
-}
      • removedInput schema / properties / nationality
        Removed value: -{
-  "description": "Client nationality for sante_internationale (e.g. 'France'). Defaults to France.",
-  "type": "string"
-}
      • changedInput schema / properties / postal_code / description
        Previous value: -"French postal code (e.g. '75008', '92150'). Required for French products, not needed for sante_internationale."New value: +"French postal code (e.g. '75008', '92150'). Required for all products."
      • changedInput schema / properties / product_type / description
        Previous value: -"Product type: sante, sante_tns, sante_internationale, auto, mrh, emprunteur, rc_pro, gav, prevoyance, pj, ij, per, assurance_vie, scolaire, epargne"New value: +"Product type: auto, moto, mrh, rc_pro, protection_juridique (pj), epargne, assurance_vie, per"
      • removedInput schema / properties / regime
        Removed value: -{
-  "description": "French social security regime: general, tns, alsace_moselle. For sante/sante_tns only.",
-  "type": "string"
-}
    • Removedlog_interaction
    • Removedsave_custom_quote
    • Removedsave_document
    • Removedsave_lead
    • Removedsend_document
  3. 3 tool updates
    • Changedget_product_template1 field changed
      • changedInput schema / properties / product_family / description
        Previous value: -"Product family code (e.g. 'sante', 'auto', 'mrh'). See supported values in description."New value: +"Product family code. ⚠️ HEALTH: pick the SPECIFIC sub-family, NOT the generic 'sante': use 'sante_internationale' for expats/abroad (Malaisie, Canada, Thaïlande…), 'sante_tns' for self-employed/indépendants in France, 'sante_surcomplementaire' for top-up on existing mutuelle, and 'sante' ONLY for standard individual/family health in France (salariés/retraités). Other values: auto, moto, mrh, gav, rc_pro, ij, emprunteur, assurance_vie, per, temporaire_deces, scolaire, protection_juridique, embedded_insurance."
    • Changedsave_lead1 field changed
      • changedInput schema / properties / product_family / description
        Previous value: -"Product family code (same as used in get_product_template): sante, sante_tns, auto, mrh, gav, rc_pro, emprunteur, etc. Required if you pass filled_data."New value: +"Product family code — MUST BE THE SAME VALUE YOU USED IN THE PREVIOUS get_quote OR get_product_template CALL. Required if you pass filled_data. ⚠️ HEALTH INSURANCE DISAMBIGUATION — pick the SPECIFIC sub-family, NEVER use the generic 'sante' as a catch-all: • 'sante_internationale' → expatriates, WHV, digital nomads, anyone living/moving ABROAD (e.g. Malaisie, Canada, Thaïlande, Dubai, expat). • 'sante_tns' → self-employed / TNS / indépendants / freelance / auto-entrepreneurs in France. • 'sante_surcomplementaire' → top-up coverage on an existing mutuelle. • 'sante' → ONLY for a standard individual/family health insurance in France (salariés, retraités), NOT international, NOT TNS. Other families: auto, moto, mrh, gav, rc_pro, ij, emprunteur, assurance_vie, per, temporaire_deces, scolaire, protection_juridique, embedded_insurance. If the client is an expat or lives abroad, ALWAYS use 'sante_internationale'. Using 'sante' in that case creates a WRONG project in CRM."
    • Changedsend_document2 fields changed
      • changedInput schema / properties / caption / description
        Previous value: -"Message to accompany the document on WhatsApp (e.g. 'Voici votre comparatif santé internationale')"New value: +"Custom message body for the email (will be inserted in the email body). Example: 'Suite à notre échange, voici le comparatif des 3 offres santé internationale...'. If omitted, a default generic message referencing the cabinet is used."
      • changedInput schema / properties / client_phone / description
        Previous value: -"Client phone number with country code (WhatsApp recipient)"New value: +"Client phone number with country code — used to locate the prospect in CRM"
  4. 2 tool updates
    • Addedget_product_template
    • Changedsave_lead4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Brief summary of client's needs, budget, preferences (e.g. 'Health insurance, budget 80€/month, needs good dental coverage')"New value: +"Free-text summary of client's situation/preferences (appended to prospect notes)."
      • addedInput schema / properties / filled_data
        Added value: +{
+  "additionalProperties": {},
+  "description": "Structured product data keyed by field ID from the product template. Example (sante): {couverture_type: 'famille', niveau_hospitalisation: 4, enfants: [{prenom: 'Leo', dateNaissance: '2018-06-01'}], budget_max: 120, date_effet: '2026-05-01'}. Call get_product_template first to discover valid field IDs/enums.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • addedInput schema / properties / product_family
        Added value: +{
+  "description": "Product family code (same as used in get_product_template): sante, sante_tns, auto, mrh, gav, rc_pro, emprunteur, etc. Required if you pass filled_data.",
+  "type": "string"
+}
      • changedInput schema / properties / product_type / description
        Previous value: -"Insurance product type: sante, sante_tns, rc_pro, mrh, prevoyance, gav, pj"New value: +"Legacy alias for product_family. Prefer product_family for new integrations. If both are passed, product_family wins."
  5. 4 tool updates
    • Addedbulk_quote
    • Addedget_client_360
    • Addedget_hot_leads
    • Addedlog_interaction
  6. 1 tool update
    • Changedget_broker_info2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • removedInput schema / required
        Removed value: -[
-  "broker_code"
-]
  7. 8 tool updates
    • Changedbook_appointment2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "client_phone"
-]New value: +[
+  "client_phone"
+]
    • Changedcheck_coverage2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "need"
-]New value: +[
+  "need"
+]
    • Changedget_product_details2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "product_name"
-]New value: +[
+  "product_name"
+]
    • Changedget_products2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • removedInput schema / required
        Removed value: -[
-  "broker_code"
-]
    • Changedget_quote2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "product_type",
-  "birth_date"
-]New value: +[
+  "product_type",
+  "birth_date"
+]
    • Changedsave_document2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "client_phone",
-  "file_name",
-  "content_base64"
-]New value: +[
+  "client_phone",
+  "file_name",
+  "content_base64"
+]
    • Changedsave_lead2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "client_phone",
-  "first_name",
-  "last_name"
-]New value: +[
+  "client_phone",
+  "first_name",
+  "last_name"
+]
    • Changedsend_document2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code returned by find_broker"New value: +"Broker code returned by find_broker. Optional in broker-authenticated mode."
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "client_phone",
-  "file_name",
-  "content_base64"
-]New value: +[
+  "client_phone",
+  "file_name",
+  "content_base64"
+]
  8. 2 tool updates
    • Addeddownload_quote_pdf
    • Addedsave_custom_quote
  9. 4 tool updates
    • Changedbook_appointment3 fields changed
      • addedInput schema / properties / broker_code
        Added value: +{
+  "description": "Broker code returned by find_broker",
+  "type": "string"
+}
      • changedInput schema / properties / quote_ref / description
        Previous value: -"Reference from a previous get_quote call (e.g. 'MCP-20260326-A1B2C3D4')"New value: +"Reference from a previous get_quote call"
      • changedInput schema / required
        Previous value: -[
-  "client_phone"
-]New value: +[
+  "broker_code",
+  "client_phone"
+]
    • Changedget_broker_info1 field changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code from find_broker (e.g. 'jmassure', 'protecsia')"New value: +"Broker code returned by find_broker"
    • Addedsave_document
    • Addedsend_document
  10. 5 tool updates
    • Changedcheck_coverage2 fields changed
      • addedInput schema / properties / broker_code
        Added value: +{
+  "description": "Broker code returned by find_broker",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "need"
-]New value: +[
+  "broker_code",
+  "need"
+]
    • Changedget_product_details2 fields changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code from find_broker (e.g. 'jmassure', 'protecsia')"New value: +"Broker code returned by find_broker"
      • changedInput schema / properties / product_name / description
        Previous value: -"Product name from get_quote results (e.g. 'Neoliane Energik', 'SPVIE Santé Génius')"New value: +"Product name as returned by get_products or get_quote"
    • Changedget_products2 fields changed
      • addedInput schema / properties / broker_code
        Added value: +{
+  "description": "Broker code returned by find_broker",
+  "type": "string"
+}
      • addedInput schema / required
        Added value: +[
+  "broker_code"
+]
    • Changedget_quote1 field changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code from find_broker (e.g. 'jmassure', 'protecsia')"New value: +"Broker code returned by find_broker"
    • Changedsave_lead1 field changed
      • changedInput schema / properties / broker_code / description
        Previous value: -"Broker code from find_broker (e.g. 'jmassure', 'protecsia')"New value: +"Broker code returned by find_broker"
  11. 4 tool updates
    • Changedbook_appointment11 fields changed
      • addedInput schema / properties / birth_date
        Added value: +{
+  "description": "Client's date of birth in YYYY-MM-DD format",
+  "type": "string"
+}
      • removedInput schema / properties / broker_code
        Removed value: -{
-  "description": "Broker code from find_broker (e.g. 'jmassure', 'protecsia')",
-  "type": "string"
-}
      • changedInput schema / properties / context / description
        Previous value: -"Brief context about the client's need"New value: +"Brief context about the client's need (e.g. 'RC Pro quote for architect')"
      • addedInput schema / properties / email
        Added value: +{
+  "description": "Client's email address",
+  "type": "string"
+}
      • addedInput schema / properties / first_name
        Added value: +{
+  "description": "Client's first name",
+  "type": "string"
+}
      • addedInput schema / properties / gender
        Added value: +{
+  "description": "Client's gender: 'M' or 'F'",
+  "type": "string"
+}
      • addedInput schema / properties / last_name
        Added value: +{
+  "description": "Client's last name",
+  "type": "string"
+}
      • addedInput schema / properties / postal_code
        Added value: +{
+  "description": "Client's postal code (e.g. '75001')",
+  "type": "string"
+}
      • changedInput schema / properties / preferred_slot / description
        Previous value: -"Preferred appointment time in ISO 8601"New value: +"Preferred appointment time in ISO 8601 (e.g. '2026-03-26T10:00')"
      • changedInput schema / properties / quote_ref / description
        Previous value: -"Reference from a previous get_quote call"New value: +"Reference from a previous get_quote call (e.g. 'MCP-20260326-A1B2C3D4')"
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "client_phone"
-]New value: +[
+  "client_phone"
+]
    • Changedcheck_coverage4 fields changed
      • removedInput schema / properties / broker_code
        Removed value: -{
-  "description": "Broker code from find_broker (e.g. 'jmassure', 'protecsia')",
-  "type": "string"
-}
      • changedInput schema / properties / current_coverage / description
        Previous value: -"Description of current coverage if any"New value: +"Description of current coverage if any, to identify gaps"
      • changedInput schema / properties / need / description
        Previous value: -"Description of the insurance need"New value: +"Description of the insurance need (e.g. 'professional liability for architect firm with 3 employees')"
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "need"
-]New value: +[
+  "need"
+]
    • Changedget_products3 fields changed
      • removedInput schema / properties / broker_code
        Removed value: -{
-  "description": "Broker code from find_broker (e.g. 'jmassure', 'protecsia')",
-  "type": "string"
-}
      • changedInput schema / properties / category / description
        Previous value: -"Product category filter: mrh, rc_pro, sante, prevoyance, auto, epargne"New value: +"Product category filter: mrh, rc_pro, sante, sante_internationale, prevoyance, auto, epargne"
      • removedInput schema / required
        Removed value: -[
-  "broker_code"
-]
    • Changedget_quote16 fields changed
      • changedInput schema / properties / birth_date / description
        Previous value: -"Client birth date YYYY-MM-DD (e.g. '1988-05-15')"New value: +"Client birth date in YYYY-MM-DD format (e.g. '1988-05-15')"
      • addedInput schema / properties / budget
        Added value: +{
+  "description": "Client's monthly budget in euros (e.g. 80). Results sorted by proximity to budget.",
+  "type": "number"
+}
      • addedInput schema / properties / children
        Added value: +{
+  "description": "Children details for family coverage",
+  "items": {
+    "properties": {
+      "birth_date": {
+        "description": "Child birth date YYYY-MM-DD",
+        "type": "string"
+      },
+      "gender": {
+        "description": "Child gender: M or F",
+        "type": "string"
+      }
+    },
+    "required": [
+      "birth_date"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
      • addedInput schema / properties / coverage_zone
        Added value: +{
+  "description": "Coverage zone for sante_internationale: monde_usa, monde_hors_usa, europe, asie_oceanie, ameriques.",
+  "type": "string"
+}
      • addedInput schema / properties / departure_date
        Added value: +{
+  "description": "Coverage start date YYYY-MM-DD for sante_internationale. Defaults to 30 days from now.",
+  "type": "string"
+}
      • addedInput schema / properties / destination_country
        Added value: +{
+  "description": "Destination country (e.g. 'Canada', 'Australie', 'Thailand'). REQUIRED for sante_internationale.",
+  "type": "string"
+}
      • changedInput schema / properties / has_spouse / description
        Previous value: -"Whether client has a spouse to cover"New value: +"Whether the client has a spouse/partner to cover"
      • addedInput schema / properties / insurance_regime
        Added value: +{
+  "description": "Insurance regime for sante_internationale: premier_euro, complement_cfe, complement_secu, etudiant. Do NOT confuse with 'regime' (French social security).",
+  "type": "string"
+}
      • addedInput schema / properties / nationality
        Added value: +{
+  "description": "Client nationality for sante_internationale (e.g. 'France'). Defaults to France.",
+  "type": "string"
+}
      • changedInput schema / properties / postal_code / description
        Previous value: -"French postal code (e.g. '75008', '92150')"New value: +"French postal code (e.g. '75008', '92150'). Required for French products, not needed for sante_internationale."
      • addedInput schema / properties / product_data
        Added value: +{
+  "additionalProperties": {},
+  "description": "Product-specific data object. Fields depend on product_type — see description above for examples per product. Call get_products first to see quoteRequirements.guidance for the exact fields to collect.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
      • changedInput schema / properties / product_type / description
        Previous value: -"Product type: sante, sante_tns, rc_pro, mrh, prevoyance, gav, pj"New value: +"Product type: sante, sante_tns, sante_internationale, auto, mrh, emprunteur, rc_pro, gav, prevoyance, pj, ij, per, assurance_vie, scolaire, epargne"
      • changedInput schema / properties / regime / description
        Previous value: -"Social security regime: general, tns, alsace_moselle"New value: +"French social security regime: general, tns, alsace_moselle. For sante/sante_tns only."
      • addedInput schema / properties / show_all
        Added value: +{
+  "description": "Return ALL quotes instead of top 5. Use only when client asks for more options.",
+  "type": "boolean"
+}
      • changedInput schema / properties / spouse_birth_date / description
        Previous value: -"Spouse birth date YYYY-MM-DD"New value: +"Spouse birth date in YYYY-MM-DD format"
      • changedInput schema / required
        Previous value: -[
-  "broker_code",
-  "product_type",
-  "birth_date",
-  "postal_code"
-]New value: +[
+  "broker_code",
+  "product_type",
+  "birth_date"
+]
  12. 1 tool update
    • Changedfind_broker1 field changed
      • changedInput schema / properties / product / description
        Previous value: -"Insurance product type: mrh, rc_pro, sante, prevoyance, auto, epargne, expatrie"New value: +"Insurance product type: mrh, rc_pro, sante, sante_internationale (international health/expat/WHV), prevoyance, auto, epargne"
  13. 1 tool update
    • Changedfind_broker2 fields changed
      • addedInput schema / properties / sub_specialty
        Added value: +{
+  "description": "Sub-specialty niche within the product (e.g. 'architectes', 'sci_is', 'dirigeants')",
+  "type": "string"
+}
      • addedInput schema / properties / ticket
        Added value: +{
+  "description": "Project amount in EUR (for routing large-ticket cases)",
+  "type": "number"
+}
  14. 1 tool update
    • Addedget_product_details
  15. 1 tool update
    • Addedsave_lead

Related MCP Connectors

Related MCP Servers

  • Quotor

    quotor
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to get real home & auto insurance quotes and start binding through a network of licensed independent agencies.
    Apache 2.0

  • BankSync MCP Server

    banksynchq
    A
    license
    Not graded
    quality
    C
    maintenance
    Connect AI agents to real bank accounts across 15,000+ financial institutions for transactions, balances, investments, and loans.
    2
    MIT

  • hive-mcp-credit-broker

    srotzin
    A
    license
    Not graded
    quality
    C
    maintenance
    Broker-only credit/lending discovery shim for AI agents, surfacing real lending markets from licensed/established third-party protocols and routing applications.
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources