Skip to main content
Your coding agent can do the setup for you with this prompt:

Supported MCP SDKs

The agentcat-sdk crate tracks any ServerHandler from rmcp, whether the #[tool_router] macros or your own code write it. For a new server, we recommend stateless HTTP, because it matches the stateless MCP protocol of 2026-07-28.

Installation

The SDK needs your project ID, which you can find in the AgentCat dashboard. We recommend the AGENTCAT_PROJECT_ID environment variable, which keeps the ID out of your code. AgentCat::from_env reads it for you.

Adding AgentCat to your server

AgentCat::from_env(options) builds one handle for the whole process, and track() wraps a ServerHandler with AgentCat. In the snippets, Calculator stands for your own ServerHandler.
A stateless server builds a new handler for each request. Each track() call wraps one handler, so the call goes inside the closure that rmcp calls. The HTTP tabs wait for a stop signal and then call shutdown, because the SDK installs no signal handler and containers stop a server with SIGTERM. A stdio server needs no shutdown call.

Identifying users

We strongly recommend that you identify your users. Without identity, the dashboard cannot show who uses your server, and each session stays anonymous.
The identify hook tells AgentCat which user made each tool call. We recommend the first of these two levels that your server can give. Full identity gives each session a real user ID and name. The hook receives a ToolCall, and call.headers() holds the HTTP headers with lower-case names. This snippet takes the place of the AgentCat::from_env line of your tab:

Anonymized identity (the minimum)

If you prefer not to send user details, a stable ID works too, for example a hash of the token or API key. The same user always gets the same ID. The snippets need the sha2 crate (cargo add sha2):
If the hook returns an error or takes more than 30 seconds, the event still goes out, without identity. Without an identify hook, every user is anonymous. Options::default() turns on every feature, and we recommend that you keep them that way. Each one adds a different view of how agents use your server:
  • Intent (enable_tool_call_context): agents tell you why they call each tool, which powers session goals.
  • Agent feedback (enable_report_missing): agents can report tools that they looked for and did not find, through the get_more_tools tool.
  • Sessions (enable_tracing): AgentCat records each tool call and groups the calls of one task into one session, so you can replay it.
If you need to turn one off, the reference page explains each option.

Testing your setup

The Rust SDK always writes its log to ~/agentcat.log, so it needs no debug option.
  1. Watch the log:
  1. Start your real server with AGENTCAT_PROJECT_ID set, as you start it in production.
  2. Call one tool with an MCP client, for example the MCP Inspector CLI:
For a stdio server, you can replace the URL and --transport http with the command that starts your server, for example -e AGENTCAT_PROJECT_ID=<project ID> <path to your binary>, and leave out --header.
  1. Look for Successfully sent event ... | mcp:tools/call | ... in the log. The line ends with the user ID from identify, or anonymous. In Sessions, the new session shows the user name from identify.
A coding agent can confirm the event with the AgentCat MCP server. If no event arrives, the log shows whether a send failed.

Guidance for AI agents

  1. Keep identify in place, because without it every user is anonymous; if the developer does not want to send user details, offer the anonymized ID.
  2. Return the same ID for the same user on every call, because a random value or a timestamp splits one user into many.
  3. Keep raw tokens, API keys, and passwords out of user_id, user_name, and user_data, because AgentCat stores and shows them.
  4. Leave enable_tool_call_context, enable_report_missing, and enable_tracing at their defaults, because each one feeds a part of the dashboard.
  5. Read the project ID from AGENTCAT_PROJECT_ID, so that it stays out of committed code.
  6. Call track() inside the closure that rmcp calls on an HTTP server, because that closure makes a new handler for each request or session.
  7. Call shutdown after axum::serve returns on an HTTP server, because the SDK installs no signal handler and the queued events would be lost.
  8. Send your own logs to stderr in a stdio server, because stdout carries JSON-RPC.
  9. Run cargo search agentcat-sdk before you pin a version, because a version from memory can be old.
  10. Test through the real server start, because a separate script can skip the track() call.

Next steps

Rust reference

Options, runtimes, shutdown, and limits

Custom events

Send your own events

Tags and properties

Add data that you can filter on

Redaction

Remove sensitive data in your server