Connect an AI assistant to the API docs

Assistants and agents read this documentation alongside your developers, and we build for that. Every page is machine-readable, and the contracts behind them are meant to be used from the spec alone.

Four ways in

MCP

A live connection from your editor to this documentation. The assistant reads real endpoints, schemas and examples instead of guessing at them.

llms.txt

A single index of the whole site, for assistants that want breadth instead of a live connection.

Copy page

Every page yields its clean Markdown source, ready to paste into a prompt.

OpenAPI

The contracts themselves, fetchable and machine-readable, for codegen and agent tooling.

Connecting an assistant over MCP

This is the option worth setting up first. It works with Cursor, Claude Code, Cline, VS Code and anything else that speaks MCP.

Add the server to your MCP configuration

{
  "mcpServers": {
    "polestar-api": {
      "command": "npx",
      "args": ["-y", "apidog-mcp-server@latest", "--site-id=773590"]
    }
  }
}

Node 18 or newer is the only prerequisite.

Reload your editor

The server reads the published documentation. It needs no API key and has no access to your account or your data.

Ask for something concrete

"Using the Pole Star API, write a function that takes an IMO and returns the vessel's last ten port calls." The assistant reads the real endpoint, parameters and response shape instead of inventing them.

Reading the docs is not calling the API

The MCP server gives an assistant the specification, not access. Your key stays yours, and the assistant's generated code still has to authenticate like any other client.

What makes these APIs agent-usable

The target is that an agent can use any endpoint from the contract alone, with no human prose in between.

Property	Why it matters to an agent
OpenAPI 3.1 contracts, generated from running code	The spec describes what the service does today, not what someone wrote down once
One response envelope across Insights	A single parsing strategy works everywhere
One error shape across Insights	Failure handling is written once, not per endpoint
`snake_case` fields, ISO 8601 timestamps in UTC	No per-endpoint convention to infer
Versions in the path, additive change within a version	Generated clients keep working between releases

Rich description, summary and example fields are part of that contract. Where they are thin, we log it as a defect.

Writing prompts that work

Name the category. "Using Port & Trade" narrows the search before it starts.

Give a real identifier. An IMO or a port identifier gets you working code; a placeholder gets you a placeholder.

Say which shape you want back. Events and aggregates come from different endpoints, and an assistant cannot guess which you mean.

Ask it to cite the endpoint. If it cannot name the path it used, it may have invented one.

Give agents the rule for addressing an area

The zone and port reads under /zone-port-insights/v1/ take an {id_type}/{id} pair. A zone is always ID with its UUID; a port takes ID or UNLOCODE. Put that in the prompt, because a wrong guess returns an error instead of data. See Zones & Ports.

SDKs & Code Generation

Generating a typed client from the contract.

Quick Start

Key to working call to generated client.

Concepts & Terminology

The vocabulary an assistant will meet in responses.

AI Assistants & Agents

Four ways in#

Connecting an assistant over MCP#

What makes these APIs agent-usable#

Writing prompts that work#

Related#

Four ways in

Connecting an assistant over MCP

What makes these APIs agent-usable

Writing prompts that work

Related