Fitralo

Send transport request

send_request

Destructive

Ask carriers for a price: one transport request goes to each carrier chosen from search_carriers, in the carrier's own language and in the name of the user's Fitralo account; the carriers answer the user directly by e-mail. It needs the user to link a free Fitralo account once (OAuth). It sends e-mail to companies: first show the user the request and the carriers, and call it only when the user agrees. Fitralo checks and translates the request, then it goes to each carrier in its office hours, usually within minutes, and the user gets an e-mail when it went. The account's monthly limits apply. Returns the request's number and page; carriers that take no requests are listed with the reason. A missing route, loading day, cargo or contact name returns an error that says what to add. Each call sends a new request: do not repeat one that succeeded. At most 300 calls an hour from one address, for all tools together.

Input Schema

Name	Required	Description	Default
`unit`	No
`cargo`	Yes	What is transported, e.g. "22 pallets of chilled food".
`phone`	No	Phone number for the carriers. By default the one of the account's last request.
`amount`	No	How much, in unit.
`regular`	No	A regular transport from load_date on, rather than one load.
`carriers`	Yes	The profile_url of each carrier to ask, from search_carriers, or only its last part.
`language`	No	The language the user writes the request in, as a two-letter code: its page and the e-mails to the user are in it, and each carrier reads it translated.	en
`quote_by`	No	Day by which the user wants the prices (YYYY-MM-DD).
`to_place`	Yes	Town or postcode of delivery.
`load_date`	No	Day of loading (YYYY-MM-DD). Leave it out when the day is still to be agreed.
`deliver_by`	No	Day the load must be delivered by (YYYY-MM-DD).
`from_place`	Yes	Town or postcode of loading.
`to_country`	Yes	Country of delivery, as a two-letter code, e.g. "IT".
`description`	No	Anything else the carriers should know, in the user's words; it is translated for each carrier.
`return_trip`	No	A load back as well.
`contact_name`	No	The person carriers ask for. By default the one of the account's last request; without one, ask the user.
`from_country`	Yes	Country of loading, as a two-letter code, e.g. "NL".
`requirements`	No	Equipment, services and certificates the load needs, in plain words, e.g. "tail lift, ADR". Those in Fitralo's list become the request's requirements, named in each carrier's language; put anything else in description.

Output Schema

Name	Required	Description
`next`	Yes	What happens now, to tell the user.
`carriers`	Yes	The carriers it goes to.
`not_sent`	Yes	Carriers chosen that take no requests through Fitralo, with why.
`reply_to`	Yes	The address the carriers answer to.
`request_id`	Yes
`request_url`	Yes	The request on fitralo.com, where the user follows, changes or sends it again.
`requirements`	Yes	The requirements as the carriers read them.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructive/openWorld/non-idempotent) by disclosing that real e-mails go to companies, that a one-time OAuth account link is required, that monthly account limits and a 300-calls-per-hour cap apply, that sending happens in carrier office hours, and which missing fields produce errors.

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?

Front-loaded with the core action and the consent rule, and nearly every sentence carries operational information. It is dense and long, but the length is justified by the number of distinct behaviors (limits, translation, errors, defaults) being disclosed.

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-parameter, destructive, open-world tool, the description covers consent, auth, limits, timing, error conditions and defaults; an output schema exists, so the brief mention of the returned request number and page is sufficient rather than required.

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 94%, yet the description adds real meaning: language governs the user's page and e-mails while carriers read a translation, requirements are matched against Fitralo's list with extras going to description, and phone/contact_name default to the last request. It stops short of covering every parameter, so not a 5.

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?

States a specific verb and resource ("Ask carriers for a price: one transport request goes to each carrier") and explicitly ties carrier selection to the sibling search_carriers, so it is distinguishable from get_carrier and search_carriers without opening a schema.

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?

Gives explicit preconditions and exclusions: show the user the request and carriers first, call only on agreement, and "do not repeat one that succeeded." It also names the sibling to use for picking carriers, leaving nothing to inference.

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

All Fitralo 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?