MCP resources & prompts
Attach documents and workflows to an agent, not just tools.
Besides tools, MCP has two other features that Graft uses:
- Resources are documents an agent's client can attach to the conversation directly, like attaching a file to an email. You pick a page, and the agent sees it, without the agent spending a step fetching it.
- Prompts are ready-made workflows you pick from a menu in your client, such as "write a new document" or "fix this error". Graft fills each one in with real details from your project.
Most clients show resources as attachable items and prompts as slash commands or a menu.
Attach a document
Every document has an address:
graft://<branch>/<collection>/<slug>For example, graft://main/pages/pricing. Your client lists these, so you can
attach a page to the conversation and ask the agent to revise it.
Resources are read from your files, not from the index. So an attached document shows your latest edit even before you compile, and resources work on a static project with no database. The text is exactly what is in the file.
When an agent lists, reads, searches, or writes content with a tool, each result also carries a link to the document's resource, so the agent can open it in one step.
Attach your whole schema
graft://<branch>/schemaThis attaches every collection and its fields, the same as the
describe_schema tool. Attach it once at the start of a session instead of
having the agent call the tool each time.
Start a workflow from a prompt
| Prompt | You provide | The agent gets |
|---|---|---|
author-document | A collection and a topic | That collection's real fields, with required ones marked |
revise-document | A collection, a document, and a goal | The document's address and the collection's fields |
fix-error | An error code | What that code means in this version of Graft, its usual causes, and how to recover |
plan-migration | A collection and the change you want | The current fields, and the steps to migrate safely |
Some prompts also carry this project's working rules, where they apply:
author-documentandrevise-documentgive the agent the collection's real fields before it writes.author-documentalso tells it to read a schema failure'sfixand correct the data, not retry unchanged.plan-migrationtells it to propose the migration as a reviewable commit, not a live edit, and never to rungraft migrate --applywithout asking. Applying is your decision.
No prompt covers approvals, and none needs to: the server enforces them,
whatever the agent was told. Over MCP, a destructive call from an identified
caller files an approval request and stops until a person decides. An anonymous
caller is refused with UNAUTHORIZED before anything is filed. The
"unattended" approval policy, which removes the wait, applies to HTTP
function calls only, never to MCP.
fix-error with a code Graft does not know says so, and points the agent at
explain_error to list the codes it does know. When the general explanation
and the failing call's own fix disagree, the prompt tells the agent to follow
the fix, because it is specific to that failure.
Autocomplete
When you fill in a prompt or a resource address, your client can suggest values from your project:
| Argument | Suggests |
|---|---|
collection | Your content collections. Operational data collections are left out, because they have no documents to write. |
slug | Documents in the collection you chose, or all documents if you have not chosen one |
code | Error codes, ignoring case |
Where they are available
Resources and prompts work the same over stdio and HTTP. The public docs endpoint serves document resources but not the schema resource, which would reveal your functions, and no prompts, because they are instructions for writing to your project.
Next steps
- MCP tools lists every tool.
- Connecting agents gets an agent connected.
- Public docs MCP covers the read-only endpoint.
