> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tythe.finance/llms.txt
> Use this file to discover all available pages before exploring further.
# Developers
> Connect an agent to your Tythe Principal Account.
Tythe gives agent developers, engineers, and trainers something no payment rail or wallet does: a credential whose authority is a mandate enforced on-chain at the principal's own account, not a key whose authority is everything the key can reach. A leaked credential can do exactly what its mandate allows and nothing more, and the principal or the Intelligence Layer can shrink that in real time. This page is the model. The reference pages arrive with the build.
The MCP server, SDK toolkits, REST reference, contract reference, and local-development harness are published with the V1 build. This overview describes the surface as designed; interfaces are final when the reference pages appear.
### The rule that makes it different
In every existing agent toolkit, the agent holds a key and the key is the authority. Scoping is left to you, at the key-management layer, and a leaked key is a drained wallet.
On Tythe, the agent holds a key and the **mandate** is the authority. The key can only submit actions; the principal's account checks each one against the mandate before anything executes. There is no scope you have to enforce in your code, because the chain enforces it, and there is nothing a leaked key can do that the mandate does not already permit.
### Two ways in
A remote server at `mcp.tythe.finance`, authenticated with OAuth. An agent connects and receives exactly the tools its mandate permits. Works from any MCP-capable runtime.
TypeScript and Python, from one monorepo, with the same tool set as the server. Adapters for OpenAI Agents SDK, LangChain and LangGraph, CrewAI, Vercel AI SDK, Google ADK, and Coinbase AgentKit, plus a plain function-calling interface.
Both produce identical on-chain actions for identical inputs. Choose by where your agent runs, not by capability.
### How a credential is bound
An ERC-8004 identity on Base, registered by you or linked if it already exists. It is public, and it is what Tythe publishes the agent's Conduct Rating against.
The principal's operator signs an Agent Authorization in the console; your agent's key co-signs through the SDK. The agent is now bound to that principal with zero scope.
Budget, counterparties, rails, credit share, earn authority, expiry, escalation threshold. Every numeric field has a ceiling; the Intelligence Layer sets the effective value inside it.
An OAuth grant carrying the principal, the agent, and the mandate. The MCP server exposes only the tools that mandate permits; the SDK builds only the actions it allows. Revocation on-chain invalidates the credential on the next request.
### What your agent can do
Tools are generated from the mandate's scope. An agent without the credit-draw rail never sees `draw_credit`.
| Area | Tools |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Pay | `pay` (x402, through a payment session), `open_payment_session`, `close_payment_session`, `transfer`, `quote`, `receipts` |
| Credit | `draw_credit`, `repay`, `credit_status` |
| Earn | `deposit_venue`, `withdraw_venue`, `follow_weights`, `lend`, `unlend`, `positions` |
| Authority | `mandate_status`, `request_escalation`, `spawn_subagent`, `revoke_subagent` |
| Intelligence, read only | `venue_signals`, `funding_rate_index`, `venue_list`, `model_weights`, `my_conduct_rating` |
| Account, read only | `treasury_balance`, `activity` |
Names are indicative until the reference pages are published.
### What the SDK handles for you
* **Keys.** The agent key stays in your runtime. Tythe's server never sees it; the console never holds it. KMS-backed signers are supported.
* **Operations.** Building and submitting the account operations behind each tool, with gas sponsored by Tythe's paymaster within the principal's allowance.
* **x402.** Parsing a 402, choosing the next identifier in the agent's session range, signing the payment authorisation from the principal's account, and closing sessions. The principal's account is the payer; your agent never holds the funds.
* **Instruments.** Co-signing the Agent Authorization at binding and the Delegation Instrument when your agent sub-delegates.
* **Reading before acting.** Effective values, remaining budget, allowlists, the escalation threshold, and expiry, so your agent fails fewer actions. Failed actions are recorded and lower its Conduct Rating.
### What Tythe never holds
* Your agent's key.
* The principal's key.
* The principal's funds. They leave the principal's account at the moment of payment and go to the counterparty.
Revocation, on-chain, is the kill switch. There is no server-side session to hunt down.
### What arrives with the build
| Page | Contents |
| --------------------------- | ------------------------------------------------------------------- |
| Quickstart | Identity, binding, credential, first read, first action, end to end |
| MCP server | OAuth flow, tool schemas, scope-to-tool generation |
| SDK toolkits and adapters | Installation, API reference, per-framework adapters |
| REST and webhooks | Resources, events, authentication |
| Agent identity and ERC-8004 | Registration, linking, what Tythe publishes |
| Payments and x402 | The payer model, sessions, the intent format, facilitators, inbound |
| Contract reference | Addresses, ABIs, and the invariants each contract enforces |
| Local development | The Base fork harness, mock facilitator, mock venues |
What an agent is on Tythe, and what it is not.
Every field your agent's credential is bounded by.