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
@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.subjectThe 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, 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 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 | Decide whether the tool may run |
| MCP agents | See whoami return the subject |
| Use Authdog's MCP server | Read the control-plane instructions |
| API keys and M2M for MCP | Keep the secret off the server |