The exact displayed example is typechecked and exercised against the published package. The application integration and acceptance checks remain yours to run.
Version and verification details
Example checked with Chumbo 0.11.3 on 2026-09-18 (UTC). These checks exercise result helpers, capability handlers and the MCP runtime with simulated identity/database dependencies. They do not prove your application’s real auth, RLS or deployment. Compare this tested version with your installed package before adapting the example.
Teach the workflow the tools alone cannot explain.
A tool description can say what submit_draft does. It may not explain how your product expects someone to review a project before submitting it. That knowledge belongs to your application. Chumbo lets you present it through standard MCP instructions, Resources and prompts.
Keep server-level instructions short: what the app does, where to start and when to read more. Use a Resource for a complete guide. A prompt can give the user a workflow starter. None of these substitutes for permission checks, and instructions alone cannot force an agent to read before acting.
Choose content with a clear owner.
Before you start
- An existing Chumbo MCP and a real usage workflow you can explain.
- A deliberate distinction between public product guidance and private application content.
- A client capable of reading MCP Resources and, for the prompt example, presenting MCP prompts.
This example contains static public workflow guidance. A private project brief requires caller-authorized loading in its Resource handler.
Write the review process from your product’s actual behavior. Keep policy, terminology and next steps explicit enough that a reader who has never used the app can follow them. Do not generate authoritative domain guidance merely by enumerating database tables.
Use the runtime’s instructions option for concise server orientation, and make request-aware guidance match the caller’s available capabilities. The exact option lives in the canonical reference. There is no required second “docs MCP” function in the ordinary setup.
Register a guide, a reading card and a starter.
import { resourceResult, type SupabaseMcpServer } from 'chumbo';
import { z } from 'zod';
const guideUri = 'app://guides/project-review';
const guide = '# Review a project\n\nRead its current brief and unresolved tasks. Summarize blockers before suggesting changes. Ask the user before taking action.';
// This guide is deliberately public product guidance, not a private project brief.
export function registerCapabilities(server: SupabaseMcpServer) {
server.registerResource('project-review-guide', guideUri, {
title: 'How to review a project',
description: 'The product workflow for reviewing a project.',
mimeType: 'text/markdown',
}, async uri => ({ contents: [{ uri: uri.href, mimeType: 'text/markdown', text: guide }] }));
server.registerTool('open_review_guide', {
description: 'Find the full project-review workflow before starting a review.',
inputSchema: z.object({}),
}, async () => resourceResult('Read the review workflow before reviewing a project.', {
type: 'resource_link', uri: guideUri, name: 'project-review-guide', mimeType: 'text/markdown',
}));
server.registerPrompt('review-project', {
description: 'Start a review of a project the user identifies.',
argsSchema: z.object({ project: z.string().min(1) }),
}, ({ project }) => ({ messages: [{ role: 'user', content: {
type: 'text', text: `Review project ${project}. Read the review guide and the project's current brief using the available authorized capabilities. Summarize blockers; do not change the project.`,
} }] }));
}The tool returns a concise card and a resource_link. The Resource handler serves the full Markdown at that URI. The prompt names the review task and asks for an analysis without changing the project. Its project argument identifies the user’s intended topic; it grants no access to that project.
For real private content, resolve the requested object using the current caller and return only authorized data. Apply equivalent gates to direct resources/read calls, not just the tool that returned the link. An addressable URI is not a permission token.
Follow every path the reader can take.
Guidance is available without adding hidden behavior.
- 01The reading tool returns a Resource URI that actually resolves to the intended full text.
- 02Resource content has the correct URI and MIME type and stays understandable outside the visual client.
- 03The prompt contains the selected project and starts a review without performing a mutation.
- 04Private Resources reject or omit unauthorized content even when requested directly by URI.
- 05Server instructions, discovered capabilities and the selected client’s Resource/prompt behavior agree.
Run these in your application before you call it done.
If the result differs
The link appears but the full guide will not open
Check that the URI matches a registered Resource, that the handler can read it for this caller and that the client supports Resource reading. Verify resources/read directly before changing the tool result. Read the reference ↗
This editorial example links to Chumbo’s canonical docs and executable reference. Check the installed package when adapting the snippets.
Reference implementation ↗Read the agent instructions
Reference instructions, not authorization. Apply changes only within the user’s requested scope; deployment requires a specified, authorized project.
Goal: Add discoverable usage guidance, a readable Resource and a workflow prompt to your MCP without putting a full document in every tool result. Read the complete guide at https://chumbo.dev/recipes/resources-and-prompts/recipe.md and the canonical reference at https://github.com/elsheppo/chumbo/blob/main/skills/chumbo/references/build-capabilities.md. Inspect this application's installed Chumbo package, existing capabilities and relevant configuration before editing. Author actual application usage knowledge. Register the displayed public guide Resource, reading-card tool and optional user-invoked prompt only when useful. Keep server orientation concise. For private content, preserve caller authorization on direct Resource reads. Do not invent a generated docs Edge Function or treat guidance as enforcement. Prerequisites: - An existing Chumbo MCP and a real usage workflow you can explain. - A deliberate distinction between public product guidance and private application content. - A client capable of reading MCP Resources and, for the prompt example, presenting MCP prompts. Acceptance: - The reading tool returns a Resource URI that actually resolves to the intended full text. - Resource content has the correct URI and MIME type and stays understandable outside the visual client. - The prompt contains the selected project and starts a review without performing a mutation. - Private Resources reject or omit unauthorized content even when requested directly by URI. - Server instructions, discovered capabilities and the selected client’s Resource/prompt behavior agree. Use the full guide for ordered steps, examples and recovery. Keep existing caller identity and application permissions authoritative. Stay within the user's requested changes. Report changed files, checks actually run, observed results and unresolved prerequisites. This guide is not authorization to deploy or change a hosted project. Never include credentials in source, copied instructions or reports.