WellFred — Services in Costa Rica

Submit a customer-approved quote request

wellfred_request_quotes

Destructive

Only after gathering the request, showing its summary and receiving explicit customer permission, submit that exact payload for supervised follow-up. Interest/comparison is not consent. Name and phone are required; email and budget are optional, and budget needs its explicit currency. Use returned question keys. Require one nonempty idempotencyKey: recovery preserves the same key AND payload; changed details require a new summary and permission, not a blind retry. Returns the real rfqUuid/reference/created; created=false is a saved replay. A saved request is not evidence of provider contact, a quote, availability, booking or payment. The MCP transport requires OAuth with rfq:submit; the existing inner REST request remains account-free and never links the OAuth identity to the RFQ. Submission can send configured admin notifications, including irreversible email.

Input Schema

Name	Required	Description
`budget`	No	Customer budget, only with an explicit budgetCurrency.
`locale`	No
`timing`	No	Customer timing request, not confirmed availability.
`answers`	No	Object keyed by returned canonical question keys, never a list.
`location`	No	Customer-approved service location; not inferred from IP.
`contactName`	Yes	Customer-approved contact name.
`description`	No	Customer-approved request detail.
`serviceUuid`	No	Returned taxonomy service ID, not a ProviderCustomService ID.
`categoryUuid`	No	Returned canonical category ID.
`contactEmail`	No	Optional customer-approved email; never proof of ownership.
`providerScope`	No	preferred permits supervised comparison; exclusive requires the chosen validated business.
`budgetCurrency`	No
`idempotencyKey`	Yes	Stable nonempty key for this exact approved payload; preserve both on recovery.
`subcategoryUuid`	No	Returned canonical subcategory ID.
`requestedService`	No	Customer service need, including an uncatalogued request without inventing availability.
`contactPhoneNumber`	Yes	Customer-approved contact phone; never proof of identity.
`preferredProviderUuid`	No	Returned validated business explicitly chosen by the customer.
`contactPhoneCountryCode`	Yes	Customer-approved dialing code, for example +506.

Output Schema

Name	Required	Description	Default
`success`	No
`httpStatus`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

It goes well beyond the destructive/openWorld annotations. It discloses irreversible admin email notifications, idempotent replay semantics (created=false), the OAuth rfq:submit scope, and that the OAuth identity is never linked to the RFQ. None of this contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and every sentence carries content. However, it is long and terse in style, with slash-joined fragments. Some schema-level details, such as required fields and the budget currency rule, are repeated, and the implementation note about the inner REST request adds clutter.

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 an 18-param mutating tool with consent requirements, it covers preconditions, recovery, authentication, side effects and the limits of what a result means. An output schema exists, and the description still clarifies the key return fields.

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 already high. The description adds the required/optional breakdown, the budget-currency coupling, the use of returned question keys for answers, and the idempotencyKey preservation rules. Locale and budgetCurrency remain undocumented, but they are self-explanatory enums.

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 tool clearly submits a customer-approved quote request payload for supervised follow-up. It separates itself from booking and availability siblings by stating that a saved request is not evidence of provider contact, a quote, availability, booking or payment.

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?

It sets explicit preconditions: gather the request, show its summary and get explicit permission. It also says when not to submit ("Interest/comparison is not consent") and gives retry rules, where changed details need new permission rather than a blind retry. "Use returned question keys" points to the get_quote_questions sibling, though it does not name it.

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

All WellFred — Services in Costa Rica 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?