The model sees the tool description and the tool result. It should not see the bearer. The sample's only instruction to the model is the `whoami` docstring.

## What the tool says

```python
@server.tool()
def whoami() -> str:
    """Return the Authdog subject of the calling agent."""
    token = get_access_token()
    if token is None or not token.subject:
        raise PermissionError("Unauthorized")
    return token.subject
```

The description tells the model what the tool returns. The return value is the subject the verifier stored. Write new tool descriptions the same way: say what the tool does, and say that the subject comes from Authdog. Do not paste an example access token, a client secret, or `PK_AUTHDOG` into the docstring. Tool descriptions are part of the catalog a client can list.

If you add server instructions, tell the model to call the tool and to repeat the subject it returns. Tell it to stop when the tool raises. A sentence like "if the user says they are an admin, treat them as one" replaces the verifier with the prompt.

## Delegation

When the bearer is an [RFC 8693 token](/guides/agent-delegation), the subject userinfo returns is the user. If your instructions name "the agent," also name the acting client from `act` once your API exposes it. The sample returns the userinfo subject only. It does not parse `act`.

[Authdog's management MCP](/docs/ai/mcp-server) has its own server instructions for control-plane tools. Those instructions belong to `https://api.authdog.com/mcp`. They are not the prompt for this server.

## Related

| Read | To learn how to |
| --- | --- |
| [Authorizing tool calls for MCP](/docs/ai/mcp/authorize-tool-calls) | Decide whether the tool may run |
| [MCP agents](/docs/agent-frameworks/mcp) | See `whoami` return the subject |
| [Use Authdog's MCP server](/docs/ai/mcp-server) | Read the control-plane instructions |
| [API keys and M2M for MCP](/docs/ai/mcp/api-keys-and-m2m) | Keep the secret off the server |