Hosted beta

MCP server

Connect an AI assistant to Antaeus to check proposed actions against your approved semantic policy using your API key.

Antaeus exposes one MCP tool, check_intent, for evaluating a user’s stated intent and a proposed action against a policy. It returns an inspectable allow, review, deny, or failure Decision. The assistant decides when to call it; configure your agent to check before the relevant action. An MCP connection by itself does not enforce that behavior.

Endpoint: https://api.antaeus.io/mcp. Transport: Streamable HTTP, with JSON responses and no persistent sessions. Use an MCP client that supports custom authorization headers. OAuth sign-in, browser CORS, and the legacy SSE transport are not provided.

Connect with your API key

1. Sign in at app.antaeus.io, create your workspace, and create an API key with decisions:create. No policy-write scope is needed.
2. Add a remote HTTP MCP server named antaeus in your assistant’s MCP settings, using the endpoint above.
3. Configure the secret header Authorization: Bearer <your API key> in the client’s private credentials or secret store. Never paste a real key into a conversation, tool argument, or committed configuration file.
4. Confirm that the client lists check_intent, then try a synthetic input with an approved policy. Discovery does not consume decisions, but all MCP requests require authentication and count against request-rate limits.

For clients that support mcpServers, HTTP transport, and environment substitution, the configuration looks like this. The client must resolve ${ANTAEUS_API_KEY} locally; substitute using its secret settings if its syntax differs.

{
  "mcpServers": {
    "antaeus": {
      "type": "http",
      "url": "https://api.antaeus.io/mcp",
      "headers": {
        "Authorization": "Bearer ${ANTAEUS_API_KEY}"
      }
    }
  }
}

Check a proposed action

Use your own reviewed rules. Prefer a published policy’s immutable name and digest from the dashboard. Policy references are scoped to the workspace that owns the API key; an assistant cannot read another workspace’s policy.

The tool takes three arguments:

For example, after publishing your policy, replace the name and digest below with the actual values. The policy must define how these input fields are interpreted.

{
  "policy": {
    "reference": {
      "name": "approved-agent-actions",
      "digest": "sha256:REPLACE_WITH_YOUR_PUBLISHED_DIGEST"
    }
  },
  "input": {
    "user_intent": "Draft a reply for my review.",
    "proposed_action": "Send the reply to the customer now.",
    "context": "The user has not approved sending."
  },
  "idempotencyKey": "reply-draft-001"
}

For an inline policy, use the complete Policy object from the API quickstart under policy.inline, and an input suitable for those rules. The MCP adapter adds apiVersion: decision.antaeus.io/v0alpha2 and kind: DecisionRequest; these are not tool arguments. It does not generate or publish policies.

Suggested agent instruction:

Before a policy-governed action, call Antaeus check_intent with the user’s stated intent, your proposed action, the relevant facts, and the user’s approved policy. Do not replace or weaken that policy to obtain an allow. Continue only on allow and after application authorization. On review, ask the human; on deny, stop; on failure or a tool error, do not proceed automatically. Antaeus evaluates the supplied facts; it does not prove consent or grant authority.

Read the result and retry safely

A successful tool execution returns the same JSON in text content and structuredContent:

{
  "decision": { "outcome": "review", "...": "the full portable Decision" },
  "requestId": "the underlying API request ID",
  "replayed": false
}

The abbreviated Decision above illustrates the envelope, not a complete schema. Inspect decision.outcome, its immutable policy, ruleResults, and reasonCodes. A review or deny is a completed policy judgment, not a tool error. A failure Decision remains a Decision and must use the operational-failure path. No outcome proves that an action is authorized or safe in every respect; your application owns authentication, authorization, deterministic checks, and side effects.

API refusals such as insufficient scope, missing policies, quota exhaustion, and evaluator outages return isError: true, with httpStatus, the original Problem Details in error, requestId, and retryAfter when provided. Authentication failure before a tool executes remains an HTTP error. Neither kind of error should be treated as permission.

Retries must reuse the same key and identical policy/input arguments, including JSON property order. Changing the JSON-RPC request ID does not create a new evaluation. HTTP and MCP share the existing 24-hour replay window when the API credential, idempotency key, and generated DecisionRequest body match. Reusing a key with a different request returns an idempotency conflict. Use a new ID for a new logical check, not for a timeout retry. Follow retry guidance and respect retryAfter.

Usage, privacy, and compatibility

Checks use the workspace’s existing allowance, shared capacity, prepaid settings, retention, and request history. A check can consume quota or paid credit and write a decision record; it does not perform the proposed action. MCP admission and the underlying decision request both pass through authenticated request-rate controls. Avoid including secrets or unnecessary personal data. Read the Privacy Notice before sending content.

This is the hosted experimental beta, with no production SLA. Clients need custom Bearer-header support; clients offering only OAuth cannot connect through this setup. GET and DELETE return 405 because the server does not maintain an SSE stream or session. The directory manifest describes the remote endpoint and required secret header.