GoodbyeMatrix CBI Pricing

Get cost breakdown request link

request_cost_breakdown_link

Read-only

Returns only the personal link (quoteRequestUrl) for one programme and family: the calculator page on goodbyematrix.com with the family already filled in, where the user requests the detailed cost breakdown with the exact amounts by e-mail from the GoodbyeMatrix team. Contact details (first name, last name, e-mail, phone) are optional; only details the user has provided and wants to pass on are used. They prefill the form on that page and are never part of the link; the link works without them. The user checks the details and sends the request personally; the privacy consent is never preselected.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`family`	Yes	Everyone who applies together. The first person is the main applicant (role "main"); only the first person has the role "main". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent.
`contact`	No	Optional. Contact details are used only as the user has provided them in this conversation and wants to pass them on to GoodbyeMatrix; the link works without them. They prefill the request form on the page; they are not part of the link and the user still checks and sends the request personally.
`program`	Yes	Programme key: sao_tome (Sao Tome and Principe), vanuatu, dominica, st_lucia (Saint Lucia), st_kitts (St. Kitts and Nevis), grenada, antigua (Antigua and Barbuda), nauru, argentina.
`language`	No	Response language: "en" (English, default) or "de" (German).	en

Output Schema

TableJSON Schema

Name	Required	Description
`program`	Yes
`language`	Yes
`programLabel`	No
`ignoredFields`	No	Only when contact was given: contact fields that were invalid and dropped.
`quoteRequestUrl`	Yes	Link to the calculator page with the family filled in, where the user requests the detailed cost breakdown by e-mail.
`contactPrefilled`	No	Only when contact was given: true if at least one contact field was accepted and will prefill the form.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 18, 2026

changedInput schema / properties / contact / description

Previous value: -"Optional. Only details the user has given in this conversation and wants to pass on to GoodbyeMatrix; never ask for them just for this and never invent them. They prefill the request form on the page; they are not part of the link and the user still checks and sends the request personally."New value: +"Optional. Contact details are used only as the user has provided them in this conversation and wants to pass them on to GoodbyeMatrix; the link works without them. They prefill the request form on the page; they are not part of the link and the user still checks and sends the request personally."

changedInput schema / properties / family / description

Previous value: -"Everyone who applies together. The first person must be the main applicant (role \"main\"); only the first person may be \"main\". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent."New value: +"Everyone who applies together. The first person is the main applicant (role \"main\"); only the first person has the role \"main\". Defaults: a partner counts as married and not same-sex unless stated; a child under 18 counts as dependent."

changedInput schema / properties / family / items / properties / birthplace / description

Previous value: -"Optional: country of birth as ISO 3166-1 alpha-2 code. Only if the user mentioned it."New value: +"Optional: country of birth as ISO 3166-1 alpha-2 code, as mentioned by the user."

changedInput schema / properties / family / items / properties / nationalities / description

Previous value: -"Optional: every citizenship of this person as ISO 3166-1 alpha-2 codes (for example [\"DE\"] or [\"RU\", \"GE\"] for dual citizens). Only if the user mentioned it."New value: +"Optional: every citizenship of this person as ISO 3166-1 alpha-2 codes (for example [\"DE\"] or [\"RU\", \"GE\"] for dual citizens), as mentioned by the user."

First observedOct 17, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses rich behavior: the link works without contact details, contact only prefills the form and is never part of the link, the user checks and sends the request personally, and privacy consent is never preselected. This is exactly the kind of non-obvious operational context an agent needs.

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 purpose is front-loaded in the first clause and every sentence carries behavioral weight (link independence, user-sends flow, consent). It is somewhat dense with stacked clauses, but little is wasted.

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 complex tool with nested family objects and an output schema, the description covers what the agent must know about behavior, contact handling and user responsibility, while return-value detail is appropriately left to the output schema.

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?

With schema coverage at 100%, the baseline is 3, but the description adds genuine meaning about the contact object: details are optional, used only as the user provided them, and passed for form prefill rather than embedded in the link. This clarifies the intent behind a parameter the schema only describes structurally.

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 gives a specific verb+resource: it "Returns only the personal link (quoteRequestUrl) for one programme and family." The word "only" implicitly distinguishes it from a fuller quote result like get_cbi_quote, but no sibling is named explicitly, so the differentiation is inferential rather than stated.

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?

It describes the end-to-end flow (the user opens the calculator page and sends the breakdown request personally), which implies when this tool applies, but it never states when to use this instead of get_cbi_quote or list_cbi_programs. Usage is implied rather than an explicit when/when-not rule.

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

All GoodbyeMatrix CBI Pricing tools Inspect

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

Need Help?