Documentation

esc
    API reference · Using the API / AI agents

    Using the API from an AI agent

    Connect an AI app through MCP, build an agent on the SDKs, or give any agent one link, a key scoped to what it should do, and the rules that keep it from doing harm.

    An AI agent can run your infrastructure through this API the same way a script does. There are three ways in, easiest first.

    Connect an AI app with MCP

    If you use Claude, ChatGPT, Cursor, VS Code, Windsurf, Codex, Gemini CLI or Grok, connect it to Pantech's MCP server. Paste this link into the app, then approve it in the console:

    text
    https://mcp.pantechdynamics.com/mcp

    You choose the organization, the access (Read only, Manage, or Manage and delete) and when it expires. The app gets ready-made tools, and anything that costs money, opens access from the internet, or deletes asks you first. Step-by-step setup for each app: Connect your AI. To run the server on your own machine instead, use pantech-mcp stdio.

    Build your own agent on an SDK

    Writing the agent yourself? The SDKs for Go (github.com/Pantech-Dynamics/pantech-go), Python (pantech) and JavaScript (@pantechdynamics/sdk) handle idempotency keys, safe retries, pagination and waiting for operations, so your tools only describe what to do.

    Any other agent

    For an agent that can only make HTTP calls, the rest of this page is what to give it, and what to tell it.

    The agent brief is everything an agent needs in one Markdown file: the base URL, how to authenticate, the rules it must follow, common jobs step by step, and every endpoint with its scope, parameters and what it returns. It is generated from the same contract the API is tested against, so it is always current.

    text
    https://docs.pantechdynamics.com/agent-brief.md

    How to hand it over depends on the agent:

    • A chat assistant (Claude, ChatGPT): start the conversation with "Read https://docs.pantechdynamics.com/agent-brief.md, then help me with my Pantech servers." Every page of this reference also has Open in Claude and Open in ChatGPT under its title, which do this for you with that page attached.

    • A coding agent working in your repository (Claude Code, Cursor and similar): save the brief next to your code and point the agent's instructions file at it.

      Terminal
      $ curl -o docs/pantech-agent-brief.md https://docs.pantechdynamics.com/agent-brief.md

      Then add a line such as "Before calling the Pantech API, read docs/pantech-agent-brief.md" to AGENTS.md or CLAUDE.md.

    • An agent you build yourself: put the brief in its system prompt, and turn the OpenAPI contract into its tools. Each operation has an operationId (such as createInstance), typed parameters and bodies, and x-scope (read or write), which is what tool-calling frameworks need.

    For more detail, every page is available as Markdown at /md/ plus its path (this one is /md/api/ai-agents), and /llms-full.txt is the whole reference in one file. To try calls yourself before an agent does, use the Postman collection or Try it on any endpoint.

    Give it the least access that works

    • Start with a read key. An agent that only answers questions, like "what is running?" or "what did last month cost?", never needs to write. A read key cannot create, change, delete or spend.
    • Use a separate key per agent, named after it (ops-agent, cost-bot), so its calls are easy to tell apart and to cut off.
    • Give a write key a short expiry. 7 or 30 days. Make a new one when it lapses.
    • A write key spends money. Creating an instance takes its initial payment from credit or your card, with no person in the loop. Keep credit at a level you are comfortable with.
    • A write key can open a shell. POST /instances/{id}/console returns a logged-in console. Do not give an agent a write key on an organization whose servers it should not log in to.

    Every request a key makes is recorded with its time, address, endpoint and result. Revoke the key in the console and it stops within about 30 seconds. An agent can also end its own key when its job is done: DELETE /me revokes the key that sends it.

    Rules to give the agent

    The brief already contains these rules. If your agent cannot fetch a URL, paste this short version into its instructions instead:

    text
    You manage Pantech Dynamics infrastructure through its public API.
    
    - Base URL: https://api.pantechdynamics.com/public/v1. Send the header
      Authorization: Bearer $PANTECH_API_KEY on every request. Keys work on
      this base URL only.
    - Call GET /me first. Its api_key.scopes says whether you may write.
    - Every POST, PUT and DELETE needs an Idempotency-Key header. Generate a
      new UUID for each new change. If a request fails or times out, retry it
      with the SAME key; never invent a new key for a retry.
    - Writes return 202 with an operation_id. Poll GET /operations/{id} every
      3-5 seconds until status is "succeeded" or "failed" before relying on the
      result. POST /instances returns an order_id instead: poll
      GET /instance-orders/{id} until status is "provisioned".
    - Read the catalogue (GET /plans, /images, /disk-offerings) for valid slugs.
      Never guess a slug or an id.
    - Errors are JSON with a "code". Act on the code, not the wording. On 429
      wait Retry-After seconds. On 5xx retry with backoff and the same key. On
      other 4xx, fix the request; do not repeat it unchanged.
    - Lists return {"data": [...], "next_cursor": ...}. Follow next_cursor
      until it is null before concluding something does not exist.
    - Amounts are integers in minor units: amount_minor 150000 NGN is N1,500.00.
    - Ask a human before anything destructive or expensive: deleting an
      instance, network, volume or snapshot; rebuild or restore (they erase
      data); resizing; creating more than one instance; opening the console.
      Say what it will cost first: POST /pricing/estimate prices a plan.

    Patterns that work well

    • Look before you change. List or get the resource first, and confirm it is the one you mean. Names are not unique; ids are.
    • Wait for each step. A subnet must be active before an instance can go in it; an instance must be running before a volume attaches to it. Follow each operation to the end before the next step.
    • Check observed_state, not just the operation. When observed_state matches desired_state, the resource is where you asked it to be.
    • Estimate before buying. POST /pricing/estimate prices any mix of plans, storage, networks and snapshots, and creates nothing.
    • Clean up in reverse order. Delete what uses a thing before the thing: public IPs, then instances, then subnets, then the VPC.

    A worked exchange

    You: Create a small Ubuntu server for a staging site.

    Agent: Calls GET /me (write scope, so that's fine), GET /plans and GET /images. Replies with the smallest plan's size, its monthly estimate and the initial payment, all read from GET /plans: "I'll install ubuntu-24-04 on that plan with your SSH key laptop. Shall I go ahead?"

    You: Yes.

    Agent: Sends POST /instances with a new Idempotency-Key, follows the order to provisioned, reads the instance, and replies with its address and the SSH command.

    The agent asked before spending money, used only slugs it had read, and followed the order to the end before claiming success.

    Was this page helpful?

    Updated