Fitralo

Carrier profile

get_carrier

Read-onlyIdempotent

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.

Input Schema

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

Output Schema

Name	Required	Description
`name`	Yes
`about`	Yes	The company in a few lines, in the language asked when translated.
`email`	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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 3, 2026

removedOutput schema / properties / quote_form

Removed value: -{
-  "description": "The profile page has a form to ask this carrier for a price.",
-  "type": "boolean"
-}

addedOutput schema / properties / takes_requests

Added value: +{
+  "description": "send_request can ask this carrier for a price; without it, the carrier gets no transport request through Fitralo.",
+  "type": "boolean"
+}

changedOutput schema / required

Previous 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"
+]

Changed4 schema fields changedOct 28, 2026

changedInput schema / properties / carrier / description

Previous 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."

changedInput schema / properties / language / description

Previous 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."

addedOutput schema / properties / about / description

Added value: +"The company in a few lines, in the language asked when translated."

addedOutput schema / properties / serves / description

Added value: +"Countries it serves, with the regions where it serves only part of one."

First observedOct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

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 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?