Skip to main content
Glama

query_ports

Read-onlyIdempotent

Query commercial seaports from the NGA World Port Index (~3,800 ports worldwide). Each row carries port name, country, harbor size (Large/Medium/Small/Very Small), harbor type, shelter rating, channel depth in metres, repair facilities. Use for questions like "ports near Bab-el-Mandeb", "deepwater ports in West Africa", "all large harbors in the Mediterranean". Pass harbor_size to slice to a single tier.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoDefault 50, max 500.
lat_maxYes
lat_minYes
lon_maxYes
lon_minYes
harbor_sizeNoLarge | Medium | Small | Very Small. Filter optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds useful dataset context (NGA World Port Index, ~3,800 ports) and the fact that harbor_size slices to a single tier, but does not disclose additional behaviors such as pagination, coordinate handling, or output ordering. With annotations present, a 3 is appropriate.

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

Conciseness5/5

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

Three sentences with no filler: the first states the action and dataset, the second lists output fields, and the third gives usage examples and the filter hint. The most important information is front-loaded, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is largely complete for a read-only query tool: it names the source, data fields, filter, and typical usage questions. The main missing piece is explicit guidance on how to express the coordinate bounds, which is necessary to call the tool correctly. Otherwise, annotations handle safety and schema handles limits.

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?

The schema only documents limit and harbor_size, so coverage is 33%. The description adds sematic value by listing the exact harbor_size values and explaining its filtering purpose. However, the required lat/lon parameters are only implied via examples; their bounding-box meaning and units are not explicitly described, leaving a gap for the low-coverage schema.

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 opens with a specific verb and resource: 'Query commercial seaports from the NGA World Port Index.' It states the dataset (~3,800 ports) and the row contents, and the example questions make the function unmistakable. This clearly distinguishes it from sibling tools like query_airports or query_vessels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use for questions like...' examples, giving an agent concrete cues for when to invoke this tool. It does not state exclusions or alternatives, but the usage context is clear enough that an agent can select it over related query tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources