Agents

Grok Bot API tools safety checklist for OpenAPI

The dangerous version of an API connector is easy to build: turn every OpenAPI operation into a tool and let the agent choose.

The safer version starts with a checklist.

1. Classify every operation

Before Grok sees a tool list, classify each operation:

  • Read: list, retrieve, search, validate.
  • Sensitive read: users, billing, API keys, tokens, exports, audit logs, private records.
  • Write: create, update, send, invite, publish.
  • Destructive: delete, cancel, refund, revoke, rotate, transfer, purge.

Sourced puts only ordinary read tools in the default allowlist.

2. Use stable tool names

Tool names come from stable operationId values whenever the spec provides them. If the generator has to synthesize names from GET /v1/widgets/{id}, the result may work today but drift later.

Good names are boring and specific:

  • listInvoices
  • getInvoice
  • createInvoicePreview

Weak names are vague:

  • manageInvoice
  • callApi
  • handleRequest

Agents choose tools from names and descriptions. Vague naming is a real safety problem.

3. Keep auth out of tool arguments

Do not ask the model to pass API keys as tool inputs. The generated MCP server reads upstream API credentials from environment variables or a secret manager.

If the remote MCP endpoint itself is protected, use a separate MCP_SERVER_ACCESS_TOKEN. Sourced-generated connector snippets use a placeholder by default and only copy the real token when the user explicitly chooses that action.

4. Require HTTPS and public DNS

Remote MCP needs a reachable HTTPS endpoint. Block these:

  • localhost
  • private IPs
  • link-local IPs
  • reserved test domains
  • authenticated APIs over plain HTTP
  • MCP URLs with query-string secrets

The connector does not become "ready" until the host, DNS, URL shape, and MCP handshake are checked.

5. Treat empty allowlists as unsafe

For Grok, do not rely on an empty or omitted tool allowlist. The safe default is explicit:

{
  "allowed_tools": ["listWidgets", "getWidget"]
}

If there are no safe read tools, block the connector and ask the API owner to choose manually.

6. Test the generated server

The generated package includes tests that prove:

  • the HTTP endpoint starts
  • missing or wrong MCP access tokens are rejected
  • bad origins are rejected
  • unsupported protocol versions fail clearly
  • tools/list returns only default-enabled tools
  • destructive and sensitive tools are not default-enabled

These tests do not replace product review, but they catch the obvious mistakes before a connector reaches customers.

7. Keep the first launch small

The first Grok connector usually exposes fewer tools than the full API. A small, useful, read-only connector is better than a complete one that nobody trusts.

After that first launch, add write tools one by one with confirmation rules, audit logs, rate limits, and rollback behavior.

Run the safety checklist from OpenAPI.