FreightUtils MCP Server

Airport Code Lookup

airport_lookup

Read-onlyIdempotent

Look up an airport by IATA code (3 letters, e.g. "LHR"), ICAO code (4 chars, e.g. "EGLL"), or free-text name/city search (e.g. "heathrow"). Covers 85,555 airports worldwide (OurAirports, public domain, cross-checked vs OpenFlights + Wikidata).

Provide ONE of iata, icao, or query; the optional type filter narrows results. Behavior: read-only; exact code hits return one record; ambiguous name searches return ranked candidates (exact codes first, then larger airports) with match quality reported via the envelope's confidence (basis match_quality); an unknown code errors with a not-found message. Rate-limited (anonymous use: 25 requests/day per IP): a 429 error body carries retry_after_seconds and a Retry-After header — back off and retry, or call get_subscribe_link for higher limits.

Returns: count and results[] — per airport: IATA + ICAO/ident, name, type (large/medium/small/heliport/closed/seaplane), municipality, region, country, latitude/longitude and elevation_ft — under result, plus confidence, _source and citation (the FreightUtils v1 response envelope).

Limitations: reference data only — not for navigation; verify operationally critical codes with IATA / ICAO.

Related: nearest_airport (find airports FROM a coordinate), airline_lookup (searches CARRIERS / AWB prefixes, not airports), unlocode_lookup (general transport locations, of which airports are one function).

Input Schema

TableJSON Schema

Name	Required	Description
`iata`	No	Exact IATA code (3 letters)
`icao`	No	Exact ICAO / ident (4 chars)
`type`	No	Optional filter by airport type
`query`	No	Name / city / municipality search (min 2 chars)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`result`	Yes
`_source`	Yes
`citation`	Yes
`validity`	No
`warnings`	No
`confidence`	Yes
`blocking_errors`	No
`envelope_version`	Yes
`normalized_input`	No

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses far more than annotations: exact code hits vs. ranked ambiguous search results, confidence/match_quality behavior, not-found errors, rate limits with retry headers, response envelope structure, and data source caveats. It also clearly states 'read-only' aligning with annotations. This fully carries behavioral transparency beyond structured fields.

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 description is long but well-structured into purpose, usage, behavior, returns, limitations, and related tools. Each section adds value and no sentence is redundant. It could be tightened slightly, but the complexity of the tool justifies the length.

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?

Given the tool's complexity (multiple search modes, output envelope, rate limiting, error behavior), the description is remarkably complete. It covers prerequisites (one-of rule), output semantics, limitations, and related tool disambiguation. The presence of an output schema doesn't reduce the need for the caveats and ambient context provided here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While schema coverage is 100%, the description adds critical semantic meaning: the mutual exclusivity rule ('Provide ONE of iata, icao, or query'), the meaning of ambiguous query behavior (ranked candidates, exact codes first), and the type filter's narrowing effect. These are not in the schema descriptions and materially help the agent invoke the tool correctly.

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 description states a specific verb ('Look up an airport') with concrete identifier methods (IATA, ICAO, free-text name/city) and explicitly distinguishes from related tools like airline_lookup and unlocode_lookup. The scope ('85,555 airports worldwide') and examples make the purpose unmistakable.

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?

Provides explicit when-to-use guidance: 'Provide ONE of iata, icao, or query', explains the optional type filter, and names direct alternatives with differentiating details (nearest_airport for coordinate-based lookup, airline_lookup for carriers, unlocode_lookup for general transport locations). This is exemplary usage guidance.

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

All FreightUtils MCP Server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation3/5

The tools cluster into clear domains and the descriptions are detailed, but there are several overlapping pairs: consignment_calculator vs shipment_summary, cbm_calculator vs unit_converter, and validate vs resolve_reference all have fuzzy boundaries. An agent could plausibly mis-select between the composite calculators or between identifier-handling tools despite the helpful cross-references.

Naming Consistency4/5

Naming is mostly consistent: reference tools use *_lookup, calculation tools use *_calculator, and checks use *_check. Exceptions like validate, resolve_reference, nearest_airport, and shipment_summary break the dominant pattern slightly, but all names are snake_case and generally predictable.

Tool Count3/5

At 25 tools, this sits at the heavy end of the range for an MCP server. The broad freight/logistics scope justifies many of them, but several single-purpose calculators could have been consolidated or grouped, making the surface feel larger and more redundant than necessary.

Completeness4/5

The server covers ADR dangerous-goods rules, multi-modal freight calculations, equipment lookups, identifier validation, customs/trade data, and emissions estimation. Minor gaps exist—no routing/geocoding, no SCAC/BIC coverage, no customs filing—but core freight-reference and calculation workflows are well supported.

Airport Code Lookup

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources