For AI agents
MCP and A2A, built in
Simault speaks two agent protocols on the same port as its REST API: the Model Context Protocol for AI clients, and Agent2Agent for autonomous agents.
Model Context Protocol
The MCP server lets an AI client manage the vault with tools. It runs over HTTP with server-sent events at /sse and /mcp/message, and every request must carry the admin key.
| Tool | What it does |
|---|---|
listAllowedApps | Lists registered applications. Never returns tokens or keys. |
registerNewApp | Creates a pending registration and returns the one-time registration token. |
removeApp | Revokes an application, including its tokens and secret. |
checkSecretHealth | Reports a secret's age and remaining lifetime without revealing it. |
getSecret | Returns the decrypted secret of an active application. |
rotateSecret | Replaces an application's secret. Does not return the new value. |
A client that supports remote servers with custom headers connects like this. The exact format differs between clients.
{
"mcpServers": {
"simault": {
"url": "https://vault.example.com/sse",
"headers": { "X-ADMIN-KEY": "<your admin key>" }
}
}
}
MCP is an administrative channel
getSecretplaces the secret in the AI client's context, where the model and the client's logs can see it.- Anyone holding the admin key can read every active application's secret through MCP. Access policies do not apply to it.
- If you do not use MCP, turn it off with
spring.ai.mcp.server.enabled=false.
Agent2Agent (A2A v1.0)
Simault publishes two agents that follow the A2A Protocol v1.0: agent cards for discovery and a JSON-RPC endpoint for calls.
| Agent | Agent card | Endpoint | Authentication | Skills |
|---|---|---|---|---|
| Client | /.well-known/agent-card.json |
/api/client/a2a |
X-AGENT-TOKEN |
getSecret, rotateSecret |
| Admin | /api/admin/.well-known/agent-card.json |
/api/admin/a2a |
X-ADMIN-KEY |
registerNewApp, listAllowedApps, removeApp |
A call is a SendMessage request whose message carries a data part naming the skill and its arguments. Every request sends A2A-Version: 1.0.
curl -X POST https://vault.example.com/api/client/a2a \
-H "Content-Type: application/json" \
-H "A2A-Version: 1.0" \
-H "X-AGENT-TOKEN: $ACCESS_TOKEN" \
-d '{
"jsonrpc": "2.0", "id": 1, "method": "SendMessage",
"params": { "message": {
"messageId": "msg-1", "role": "ROLE_USER",
"parts": [ { "data": { "skill": "getSecret", "appId": "payment-service" } } ]
} }
}'
What the A2A support covers
- Synchronous JSON-RPC only. A request is answered directly with a message. No tasks are created.
- Not supported: streaming, push notifications, the extended agent card, and the gRPC and HTTP+JSON bindings. These return the errors the specification defines.
- Structured input. Skills take a JSON object. The agents do not interpret natural language.
- Same checks as the REST API. The client agent enforces the access token, the application's status, access policies and rate limits.
- Separation. Admin skills are neither advertised nor callable on the client agent.
The details, including error codes, are in the README.