Automation and MCP

What MCP is

MCP (Model Context Protocol) is the open standard through which AI assistants such as Claude call tools. euid.com announces its tools to the assistant with a description and input fields; the assistant picks the right one, calls it and reads the answer. You say "audit example.com with 50 pages and give me the tasks", the assistant makes the calls. Each tool corresponds to one function of the service; there is no second path around the rules.

Creating access

• The prerequisite is an account as an agency or organisation with an audit customer. Register at /registrieren, type "Agency" or "Organisation".
• The owner creates the access themselves: organisation settings → MCP access (/pruefung/zugaenge), choose a name, choose a role. The token starts with euid_mcp_ and is shown once; the service stores only its fingerprint. Lost means: create a new one, revoke the old one.
• The role follows the customer type: agency → agentur, organisation → organisation; narrower (tester, read only) can be chosen, wider never. The scope is the own audit customer and the directly supervised organisations; everything else is rejected before the call.
• Only the admin token of the operator sees all audit customers. It is issued to nobody.

The roles

• agentur: audit, measure, batches, tasks, lists within its own scope. Topping up credit, issuing seals, setting the look and creating customers remain with the operator.
• organisation: like agentur, without batches (one website).
• tester: read only. Status, tasks, catalogue, improvement plan, lists; every writing call is rejected.
• pruefer: an auditing person. Their assistant fetches the next page, reads findings and the screen-reader text aloud and records the verdict; the credit per page is the same as in the interface. The access is created under MCP access, section "My auditor access".
• betreiber: all tools. The operator grants this role only to their own scripts.

Setup in Claude Code

One command in the terminal is enough; the token goes into the Authorization header.

claude mcp add --transport http euid https://euid.com/api/mcp \
  --header "Authorization: Bearer <IHR-TOKEN>"

Setup per project (.mcp.json)

For a repository several people work in: the file .mcp.json in the project root, the token as an environment variable.

{
  "mcpServers": {
    "euid": {
      "type": "http",
      "url": "https://euid.com/api/mcp",
      "headers": { "Authorization": "Bearer ${EUID_MCP_TOKEN}" }
    }
  }
}

Setup in Claude Desktop and other assistants

• Claude Desktop: Settings → Connectors → "Custom connector" → address https://euid.com/api/mcp; the token as header Authorization: Bearer <YOUR-TOKEN>.
• Cursor, Windsurf, Continue and other tools with MCP support: server type "HTTP" (Streamable HTTP), the same address, the same header.
• Your own programs: JSON-RPC 2.0 via POST to https://euid.com/api/mcp with the methods initialize, tools/list and tools/call. Without a token, tools/list answers with the public tools (verify seal, read prices).

The usual path of an audit

• pruefservice.kunden.liste: which audit customers do I see? Returns the identifiers (UUID) for all further calls.
• pruefservice.pruefung.starten: domain, audit customer, scope (page tier) and audit areas. Costs credit as in the browser. With the queue the call returns immediately with "queued".
• pruefservice.pruefung.stand: poll until finished. Measured pages, scores per audit area, report addresses.
• pruefservice.pruefung.todos: the result as a task list per audit area and rule with severity, locations, measure and a link into the knowledge base.
• pruefservice.stapel.starten: many domains in one call (role agentur). The measurements run one after another, the status is shown per domain.

A call without an assistant

The same tool with curl. The format is JSON-RPC 2.0, the answer comes as JSON.

curl -s -X POST https://euid.com/api/mcp \
  -H "content-type: application/json" \
  -H "authorization: Bearer $EUID_MCP_TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"pruefservice.pruefung.starten",
        "arguments":{"kundeId":"<uuid>","domain":"beispiel.at","stufe":50}}}'

The /api/v1 interface

If you prefer HTTP endpoints to tools, use /api/v1 with an agency token (header Authorization: Bearer or x-api-key). The scope is the same: the agency and the organisations it directly supervises. Only an access with the right "voll" can have measurements run, because measuring moves credit.

• GET /api/v1/kunden: supervised audit customers; POST creates one (company, domain, audit areas).
• POST /api/v1/pruefungen: start an audit (kundeId, domain, seiten from the tier, bereiche); GET lists runs, GET /api/v1/pruefungen/<runId> returns the status.
• POST /api/v1/stapel: many domains; GET shows the progress.
• GET /api/v1/zertifikate: seals within the scope with their verification address.

What an access never does

• A seal never arises from a call alone: it needs the domain proof and the explicit call of pruefservice.zertifikat.ausstellen by the operator.
• Credit arises only through the checkout; an access can spend it, never create it.
• Every call is written to the activity log with access name, tool and result. Rejected calls are recorded there as well.
• A token is valid until the operator revokes it; the revocation takes effect within a minute.