A coding agent should read Authdog's published docs, then call the management MCP when it needs a live account. Paste those URLs into the agent's context, or let it fetch them.
Docs the agent can fetch
| URL | What the agent gets |
|---|---|
https://www.authdog.com/llms.txt |
Index of the docs. Each link is raw Markdown. |
https://www.authdog.com/llms-full.txt |
Those documents in one file. |
https://www.authdog.com/instructions.txt |
What Authdog is, which claims to avoid, and where to read next. |
instructions.txt outranks a web-search snippet. If the agent is about to invent a price, a certification, or an API, point it at that file first.
Framework samples live in authdog/agents-samples. Each folder is its own project. The matching getting-started page names the package pin and the auth hook.
Live account work
Reading the docs does not create a tenant. Use Authdog's MCP server lets the agent list tenants, create a project, and read SDK config for the account you sign in with.
The CLI registers that server for you:
authdog mcp install --client cursor--client accepts cursor, claude, vscode, or codex. --all writes every client that is installed. The command stores the server URL. It does not store an access token.
What to hand the agent
Give it the framework page you want it to follow, the sample folder, and the environment it may touch. Keep the client secret out of the prompt. The process that mints tokens can read the secret from the environment. The agent can ask you to confirm a mutation. It should not invent a tenant id, a project id, or a client id.
Related
| Read | To learn how to |
|---|---|
| Use Authdog's MCP server | Connect the control-plane tools |
| Using Authdog with AI | Pick a framework hook or an MCP path |
| Agents quickstart | Register the identity the sample will mint |