For coding agents
Give your coding agent the documentation URL and the feature you want to build. Start with a small index, then let it read the product-specific guides and reference it needs.
Point your agent at the docs
Copy this prompt into Codex, Claude or your preferred coding agent, then fill in the project details. The prompt includes the documentation entry point and the context the agent needs.
Use https://docs.deads.io/llms.txt as the documentation entry point.
I want to build: [describe the feature].
My framework/runtime: [React, Next.js, Node, or other].
Product and target chain: [GraveMint or GraveMarket; chain].
Installed SDK version: [version, or ask me to confirm].
Target API environment: [base URL and deployed release, if known].
Read the relevant Markdown quickstart, SDK guide, method reference, concepts and errors before coding. Use the published SDK methods and response types for my installed version. Verify target API support before relying on a new SDK contract; package publication does not prove the server has been deployed. Read the version and deployment compatibility section in the integration guide. Cite the exact docs pages you rely on and call out any version mismatch or missing detail.
Preserve chain and currency information, nullable prices, pagination and loading/empty/error states. For GraveMint, respect key/origin scope, resolved priceDisplay, capabilities, batch signing and session expiry; the wallet signs and the server broadcasts. Never put a private server key in browser code. Do not invent an endpoint or assume an unsupported trading/mint flow.
Explain your integration plan, implement it in my project, and validate the SDK calls and failure states. Ask for missing access or product decisions instead of guessing.If your agent cannot fetch URLs, download the full text and attach it, or provide the relevant Markdown pages directly. Fetching behavior depends on the agent and its permissions; a docs file alone does not grant it network or tool access.
Give it the right context
| Your task | Start with | Then provide |
|---|---|---|
| Mint UI | GraveMint quickstart | Read model, signing, methods, errors |
| Collection or activity view | GraveMarket SDK | Marketplace model, methods, collection recipe |
| Direct HTTP integration | GraveMint API or GraveMarket API | Request parameters, generated SDK snippets and recorded examples |
| Debug an integration | Troubleshooting | The installed package version, relevant error code and a sanitized request/response |
The SDK guides and method references identify their package versions. Ask the agent to compare those with your lockfile before using a newer method or parameter. A generated reference is evidence of the public contract for that version, not a promise that your installed version already supports it.
Ask the agent to verify the target API environment as well as the installed package. A package can be published before its server changes are deployed. Read version and deployment compatibility before relying on a new response field or behavior. The MCP setup guide covers the hosted server at https://mcp.deads.io/mcp and the local stdio package.
Every guide is available as Markdown
Use View Markdown above a documentation page, or append .md to its clean URL. These files are generated from the same documentation source as the website. Interactive API consoles become parameter tables and JavaScript, TypeScript and cURL examples that can be read without JavaScript.
- GraveMint method reference as Markdown
- GraveMarket method reference as Markdown
- Documentation index
- Complete documentation bundle
Add MCP when you need tools
Reading documentation and connecting tools are separate steps. The MCP server guide describes the published tools and configuration for supported clients. Follow your coding agent's MCP configuration process to connect it.
MCP does not replace the SDK in the application you build. GraveMint tools require a server-side key; keep it out of browser code and prompts. See MCP key requirements and keys and origins.
What a useful result should include
- SDK calls and parameters that exist in the version your application installs.
- Links to the documentation used, plus any unresolved assumptions.
- Correct chain, currency, nullable-price and pagination behavior.
- Loading, empty and failure states appropriate to your feature.
- For mint flows: origin/key scope, signer integration, server submission, batching and session-expiry handling.
- Validation against your project, rather than a claim that an unrun snippet is production-ready.