MCP overview
The Model Context Protocol server at /api/mcp. Authentication, transport, and tools.
The Graniite MCP server is what Claude Desktop, Cursor, ChatGPT, n8n's MCP node, and other MCP-aware AI clients connect to. It exposes your library to the agent so it can search, read, and add content inside a conversation.
Endpoint
https://graniite.co/api/mcpTransport
HTTP, JSON-RPC 2.0. Recent versions of Claude Desktop, Cursor, ChatGPT, and claude.ai speak this natively. Paste the URL into the client's MCP or integrations settings and the client handles the OAuth handshake.
For older clients that only speak stdio MCP, use mcp-remote as a stdio-to-HTTP bridge.
Authentication
The server uses OAuth 2.1 with Dynamic Client Registration when added from a client UI. The client handles the flow on your behalf. You only see the /oauth/authorize consent screen in your browser.
For programmatic use, mint a bearer token at /settings/integrations and pass it as Authorization: Bearer lev_…. See Authentication for the full token and scope model.
Tools
There are four tools: three read and one write.
| Tool | Capability | Purpose |
|---|---|---|
search_knowledge_base | read | Semantic, keyword, and hybrid search over chunks |
get_item | read | Full content and outputs for one item by id |
list_recent | read | Recent items across scope |
add_to_knowledge | write | Add a URL or text snippet to the library |
Update, delete, and organize operations are not exposed via MCP. These operations do not fit agent tool-use loops. Use the REST API for those. See MCP vs REST.
How clients discover the server
The server publishes standard OAuth resource-server metadata at:
https://graniite.co/.well-known/oauth-protected-resource
https://graniite.co/.well-known/oauth-authorization-serverCompliant MCP clients hit these on first connect, register a public OAuth client via DCR (POST /oauth/register), and bounce the user through /oauth/authorize for consent. Every issued token is bound to a folder scope and capability set chosen at consent time.
Scope model
Each token carries:
- Capabilities:
read(mandatory) and optionallywrite. - Folder scope: either whole-library or a specific list of folders. The
add_to_knowledgetool auto-files new items into the token's folder only when the scope is exactly one folder. Multi-folder and whole-library tokens leave new items unfiled. Use RESTPOST /api/v1/items/:id/foldersto file them after. kb_onlyflag: when set,list_recentandget_itemskip items flagged as not-in-KB. Search is always KB-only.
See Authentication for how to mint these.
Rate limits
| Tool | Per-token cap |
|---|---|
search_knowledge_base | 1000 / hr |
get_item | 1000 / hr |
list_recent | 1000 / hr |
add_to_knowledge | 60 / hr |
A 429 response includes retry_after_sec. Agents should back off and retry. Clients that ignore the header risk a longer cooldown.
Step 3 (PDF/image): finalize a document upload and extract text synchronously. POST
Call after PUT-ing the PDF or image to the signed URL. Server downloads the bytes, runs magic-byte verification, extracts text (unpdf for PDFs, Claude vision OCR for images), generates a thumbnail, creates the user_items row, and DELETES the original file from Storage (the contents row only carries the transcript + thumbnail path — PDFs and images are ephemeral in document-uploads by design). Returns status='ready' — no async polling needed. Image OCR counts against the user's transform quota; PDFs are free. Rate limit: 30/hr per token.
search_knowledge_base
Semantic, keyword, or hybrid search over the user's library. Returns the top-K matching chunks.