FIRMSapi

Get a CBP port and its facilities

get_cbp_port

Read-onlyIdempotent

One CBP port with a page of its FIRMS facilities, ordered by code. Placeholders are left out; active codes only unless include_deleted is true. For the next page pass cursor = meta.next_cursor (null on the last page); each page is one call. Wraps GET /v1/ports/{port}. Live keys (fapi_live_...): one counted call. Test keys (fapi_test_...): fixture sample data, not counted.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "port": "<port>"
    },
    "name": "get_cbp_port"
  }
}

Input Schema

Name	Required	Description
`port`	Yes	4-digit CBP port code, e.g. 4601.
`limit`	No	Facilities per page.
`types`	No	Only these facility types: 01 Container freight station (CFS), 02 Foreign trade zone (FTZ), 03 Pier or terminal, 04 Bonded warehouse, 05 Inspection facility, 06 Importer premises, 07 DP site, 08 CBP administrative, 09 Centralized examination station (CES), 10 Rail or air terminal (inferred), 11 CBP test.
`cursor`	No	meta.next_cursor from the previous page.
`include_deleted`	No	Include deleted codes (ranked after active ones).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026
- changedInput schema / properties / cursor / description
```
Previous value: -"meta.next_cursor."New value: +"meta.next_cursor from the previous page."
```
- addedInput schema / properties / limit / description
```
Added value: +"Facilities per page."
```
First observedOct 26, 2026

TDQS

A4/5.0

Behavior5/5

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), and the description adds genuinely new behavior: placeholder codes are omitted, only active codes by default unless include_deleted is true, cursor is null on the last page, and live keys count one call while test keys return fixture data uncounted. This is exactly the kind of cost/auth/default-filter disclosure annotations cannot carry.

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?

Four short sentences, all front-loaded and each carrying distinct information (scope, filtering defaults, pagination, API key/count semantics). No filler and nothing repeated from the title.

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?

With no output schema, the description correctly explains the return shape (one port plus an ordered facility page) and the meta.next_cursor field, so the agent can paginate without guessing. It does not describe the port object's fields, which is a minor remaining gap for a detail-fetch tool.

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%, so the schema already documents all five parameters in detail. The description adds marginal value only: it restates cursor sourcing from meta.next_cursor (already in the schema) and adds the useful 'null on the last page' detail plus the active-vs-deleted ordering default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: retrieve one CBP port plus a paginated page of its FIRMS facilities, ordered by code. Singular-vs-plural phrasing implicitly separates it from list_cbp_ports, but no sibling is named explicitly and the boundary with search_firms_facilities is left to inference.

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

Usage Guidelines3/5

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

Pagination usage is well specified ('pass cursor = meta.next_cursor', 'each page is one call'), which tells the agent how to continue. However, there is no guidance on when to choose this over list_cbp_ports or search_firms_facilities — usage is only implied by the singular-port scope.

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

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