European directory of freight carriers: find carriers by route, equipment and certificates.
Scored across 3 tools
The three tools have clearly distinct roles: search_carriers finds carriers, get_carrier retrieves one carrier's contact profile, and send_request sends a quote request. Descriptions explicitly connect the workflow and warn against using get_carrier for comparison. No overlapping purposes.
All names follow a consistent snake_case verb_noun pattern: search_carriers, get_carrier, send_request. The singular/plural noun difference reflects the operation's scope and does not confuse the convention.
Three tools are well-scoped for a narrow carrier-search-and-request workflow. Each tool earns its place without redundancy, and the set covers discovery, detail, and contacting carriers.
The core lifecycle is covered: search carriers, inspect a chosen carrier, and send a request. A minor gap is the lack of a tool to retrieve or manage sent request status, though send_request returns a request number and page and carriers reply directly by e-mail.
One carrier's full profile on Fitralo, with its phone, e-mail and website and where and how it carries. Use it after search_carriers, which gives no contact details: for a carrier the user picked, wants to contact or wants to know more about. To find or compare carriers, use search_carriers. One carrier a call; what it has not published is null. A carrier that is unknown or no longer listed returns an error asking for a profile_url from search_carriers. Read-only and without an account: it changes and books nothing. At most 300 calls an hour from one address, for all tools together.
| Name | Required | Description | Default |
|---|---|---|---|
| carrier | Yes | The carrier's profile_url from search_carriers, e.g. "https://fitralo.com/c/example-transport", or only its last part, "example-transport". A company name is not looked up: search for it with search_carriers first. | |
| language | No | The user's language as a two-letter code, when Fitralo has it: labels such as services and equipment, the profile description where it is translated, and the links to the site follow it. | en |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| about | Yes | The company in a few lines, in the language asked when translated. |
| Yes | ||
| fleet | Yes | |
| phone | Yes | |
| serves | Yes | Countries it serves, with the regions where it serves only part of one. |
| address | Yes | |
| website | Yes | |
| services | Yes | |
| equipment | Yes | |
| vat_number | Yes | |
| cross_trade | Yes | Also carries between countries other than its home country. |
| profile_url | Yes | |
| certificates | Yes | |
| last_checked | Yes | |
| takes_requests | Yes | send_request can ask this carrier for a price; without it, the carrier gets no transport request through Fitralo. |
| verified_by_company | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing the one-carrier-per-call scope, that unpublished fields are null rather than omitted, that unknown or delisted carriers return an error directing the caller to a profile_url, that no account is needed, and a concrete rate limit (300 calls/hour per address shared across all tools). These are operational facts the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the search_carriers dependency, and most sentences earn their place. It is dense to the point of packing several clauses per sentence ("Read-only and without an account: it changes and books nothing"), and the read-only restatement largely duplicates the annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description need not describe return fields, and it still covers the null-handling, the error path, auth requirements, rate limits, and call scope. An agent has everything needed to invoke it correctly on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains that profile_url or its slug is accepted and that company names are not looked up, so the description adds little parameter-level detail. Its only marginal contribution is tying the error case to the profile_url parameter type. Baseline 3 applies when the schema carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"One carrier's full profile on Fitralo, with its phone, e-mail and website and where and how it carries" states a specific verb and resource plus the concrete payload, and immediately names the sibling it is distinct from (search_carriers). An agent can route between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit sequencing rule ("Use it after search_carriers, which gives no contact details"), a trigger ("for a carrier the user picked, wants to contact or wants to know more about"), and an exclusion with the alternative named ("To find or compare carriers, use search_carriers"). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find road freight carriers in Europe that run a route and offer the equipment, services or certificates a load needs. Write the query plainly: the places of loading and delivery (town, postcode or country), then what is needed, e.g. "reefer from Venlo to Rome", "ADR tank Rotterdam to Poland", "groupage Germany to Italy, tail lift". "based in Italy" keeps carriers based there. Returns the carriers that fit, best first, with what the search understood: if that is not what the user meant, phrase the query again. It returns at most limit carriers (10 unless set, up to 25); carriers_that_fit counts all that fit, and results_url shows them all on fitralo.com. When nothing fits exactly, carriers_that_fit is 0 and the list has the carriers that come closest. A query without a route or need returns an error that says how to write it. Then call get_carrier for contact details. Read-only and without an account: it changes and books nothing. At most 300 calls an hour from one address, for all tools together.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many carriers to return. | |
| query | Yes | The route and needs in plain words, in English or the language given. | |
| language | No | The user's language as a two-letter code, when Fitralo has it: labels such as services and equipment, the profile description where it is translated, and the links to the site follow it. | en |
| specialists_only | No | Only carriers for whom this route (or area) is their own line, not one among many. |
| Name | Required | Description |
|---|---|---|
| carriers | Yes | |
| results_url | Yes | All results on fitralo.com, with filters for the user. |
| specialists | Yes | Of those that fit, how many have this route as their own line; null without a place in the query. |
| understood_as | Yes | The route and needs the search read in the query. |
| carriers_that_fit | Yes | All carriers that fit; when 0, the list has those that come closest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real context beyond them: no account needed, nothing is booked or changed, a 300-calls-per-hour-per-address limit shared across all tools, best-first ordering, and the closest-match fallback when carriers_that_fit is 0.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the query-writing instruction are front-loaded and every example earns its place, but the closing sentences about carriers_that_fit and results_url re-explain return values that the output schema already documents. Slightly long, though dense rather than padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a search tool: input guidance, error behavior, rate limits, and next-step routing are all present, and an output schema exists so return values need no explanation. The only gaps are the unaddressed specialists_only and language parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes further by teaching the syntax of the free-text query, which is the only ambiguous parameter, and restating the limit cap ('10 unless set, up to 25'). It says nothing about specialists_only or language, leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find road freight carriers in Europe') plus the discriminating scope: route, equipment, services, certificates. It also names the downstream sibling ('Then call get_carrier for contact details'), so an agent can place it in the workflow without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete query patterns ('reefer from Venlo to Rome', 'ADR tank Rotterdam to Poland', 'groupage Germany to Italy, tail lift'), explains the 'based in Italy' qualifier, tells the agent to rephrase when the parsed query is wrong, and routes contact-detail lookups to get_carrier. Failure modes (query without route or need) are also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_carrier3 fields changedOutput schema / properties / quote_formRemoved value: -{
- "description": "The profile page has a form to ask this carrier for a price.",
- "type": "boolean"
-}Output schema / properties / takes_requestsAdded value: +{
+ "description": "send_request can ask this carrier for a price; without it, the carrier gets no transport request through Fitralo.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "name",
- "profile_url",
- "address",
- "about",
- "serves",
- "cross_trade",
- "services",
- "equipment",
- "certificates",
- "fleet",
- "website",
- "phone",
- "email",
- "vat_number",
- "verified_by_company",
- "last_checked",
- "quote_form"
-]New value: +[
+ "name",
+ "profile_url",
+ "address",
+ "about",
+ "serves",
+ "cross_trade",
+ "services",
+ "equipment",
+ "certificates",
+ "fleet",
+ "website",
+ "phone",
+ "email",
+ "vat_number",
+ "verified_by_company",
+ "last_checked",
+ "takes_requests"
+]search_carriers2 fields changedOutput schema / properties / carriers / items / properties / takes_requestsAdded value: +{
+ "description": "send_request can ask this carrier for a price; without it, the carrier gets no transport request through Fitralo.",
+ "type": "boolean"
+}Output schema / properties / carriers / items / requiredPrevious value: -[
- "name",
- "profile_url",
- "location",
- "fits_exactly",
- "specialist_on_route",
- "verified_by_company",
- "last_checked",
- "services",
- "equipment",
- "certificates"
-]New value: +[
+ "name",
+ "profile_url",
+ "location",
+ "fits_exactly",
+ "specialist_on_route",
+ "verified_by_company",
+ "last_checked",
+ "services",
+ "equipment",
+ "certificates",
+ "takes_requests"
+]send_requestget_carrier4 fields changedInput schema / properties / carrier / descriptionPrevious value: -"The carrier's profile_url from search_carriers, or its last part."New value: +"The carrier's profile_url from search_carriers, e.g. \"https://fitralo.com/c/example-transport\", or only its last part, \"example-transport\". A company name is not looked up: search for it with search_carriers first."Input schema / properties / language / descriptionPrevious value: -"Language of the labels and of the links to the site: the user's language, when Fitralo has it."New value: +"The user's language as a two-letter code, when Fitralo has it: labels such as services and equipment, the profile description where it is translated, and the links to the site follow it."Output schema / properties / about / descriptionAdded value: +"The company in a few lines, in the language asked when translated."Output schema / properties / serves / descriptionAdded value: +"Countries it serves, with the regions where it serves only part of one."search_carriers1 field changedInput schema / properties / language / descriptionPrevious value: -"Language of the labels and of the links to the site: the user's language, when Fitralo has it."New value: +"The user's language as a two-letter code, when Fitralo has it: labels such as services and equipment, the profile description where it is translated, and the links to the site follow it."European road freight and moving prices: quotes, dated price index, glossary, order submission
European maps, geocoding and routing: places, routes, travel times, reachable areas and maps.
Get instant road freight prices and arrange pallet, express or full truck transport in Europe.
Open Transport Hub - transport and logistics marketplace directory for AI agents.
Add one secure layer between your agents and this server.
