Marble MCP Server
Integrates with Supabase to store and manage learning prompts in a database, enabling the generation of shortened, shareable URLs for interactive learning slides on the Marble platform.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Marble MCP ServerCreate slides explaining the authentication flow in this app"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Marble MCP Server
An MCP (Model Context Protocol) server that generates learning project links for the Marble platform (withmarble.io). This server enables Claude Code to analyze codebases and suggest relevant learning projects with direct links to create them on Marble.
Features
Codebase Analysis: Analyzes your current codebase to understand technologies and patterns
AI-Generated Projects: Suggests relevant learning projects based on code analysis
Interactive Slides: Generate links to interactive learning slides based on your code
Marble Platform Integration: Generates properly formatted links to create projects on withmarble.io
Customizable: Specify topics, difficulty levels, and code context for tailored suggestions
Short URLs: Stores prompts in a database for clean, shareable links (optional)
Installation
Claude Code
Run claude mcp add marble npx marble-mcp-server --scope user.
Cursor
Modify your ~/.cursor/mcp.json to be like:
{
"mcpServers": {
"marble": {
"type": "stdio",
"command": "npx",
"args": [
"marble-mcp-server"
],
"env": {
}
}
}
}Augment Code
Go to the Augment Settings.
Under "Tools", scroll down until you find "MCP". Click the "Import from JSON" button.
Paste the following JSON snippet:
{
"mcpServers": {
"marble": {
"type": "stdio",
"command": "npx",
"args": [
"marble-mcp-server"
],
"env": {
}
}
}
}Usage
1. Suggest Learning Projects
Ask Claude Code to suggest projects for learning something in your codebase:
"I want to learn more about React hooks. Can you suggest some projects?"
"What are some projects I could build to learn the authentication patterns used here?"
"Suggest beginner projects for learning the database design in this app"Claude Code will:
Use the
suggest_learning_projectstoolAnalyze your codebase for relevant code
Generate 3 project ideas
Create Marble platform links for each project
2. Generate Interactive Learning Slides
Ask Claude Code to generate interactive slides to explain concepts in your codebase:
"Create slides explaining how React hooks work in this codebase"
"Generate slides about the authentication flow in this app"
"Make slides explaining the database schema"Claude Code will:
Use the
generate_slides_linktoolRead relevant code from your codebase
Create a comprehensive prompt with code examples
Save the prompt to the database (if configured)
Return a link to interactive slides on Marble
3. Generate Individual Project Links
You can also ask Claude Code to generate a link for a specific project:
"Generate a Marble link for a project about building a REST API with Express"Configuration
Environment Variables
The generate_slides_link tool requires the following environment variables:
SUPABASE_URL: Your Supabase project URL (required)SUPABASE_KEY: Your Supabase publishable key (required, starts withsb_publishable_...)Find it in: Supabase Dashboard → Settings → API → Project API keys
Note: The SUPABASE_URL and SUPABASE_KEY environment variables are required for the generate_slides_link tool to work. The tool will error if these are not configured.
Security: Use your Supabase publishable key (sb_publishable_...), not the service role or secret key. The publishable key is:
✅ Safe to use in CLIs, MCP servers, and public code
✅ Can be rotated independently without downtime
✅ Restricted by Row Level Security policies
✅ The modern, recommended approach (replaces the legacy anon JWT key)
Important: Use the publishable key (sb_publishable_...), not secret or service role keys. Benefits:
✅ Safe to expose in CLIs, scripts, and MCP servers
✅ Easy rotation without downtime
✅ Modern best practice (replaces legacy JWT-based anon key)
The publishable key is restricted by Row Level Security (RLS) policies and can only:
✅ Insert new prompts into
slide_prompts✅ Read prompts from
slide_prompts❌ Cannot update, delete, or access any other tables
Note: If these variables are not set, the generate_slides_link tool will return an error. The suggest_learning_projects and generate_marble_link tools do not require database configuration.
Database storage provides:
Creates shorter, more shareable URLs (e.g.,
withmarble.ai/learn?prompt_id=abc123)Avoids URL length limitations with long prompts
Improves link reliability across different platforms
If not provided, the server will fall back to encoding prompts directly in URLs.
Database Setup
If using Supabase integration, you'll need to create the slide_prompts table:
CREATE TABLE slide_prompts (
prompt_id UUID PRIMARY KEY,
prompt TEXT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);Tools Provided
suggest_learning_projects
Instructs Claude Code to analyze the codebase and suggest learning projects.
Parameters:
topic(required): What to learn (e.g., "React hooks", "authentication")codeContext(optional): Specific files/directories to analyzedifficulty(optional): "Beginner", "Intermediate", or "Advanced"
Example:
{
"topic": "state management",
"codeContext": "src/store",
"difficulty": "Intermediate"
}generate_marble_link
Generates a Marble platform link from project data.
Parameters:
project(required): Project data object with:id: Unique ID (timestamp)title: Project titledescription: Detailed descriptioncategory: Primary language/frameworkdifficulty: "Beginner", "Intermediate", or "Advanced"timeEstimate: e.g., "2 hr", "90 min"technologies: Array of technologiestargetSkills: Array of skills to learn
Example:
{
"project": {
"id": 1701234567890,
"title": "Build a Task API",
"description": "Create a RESTful API for managing tasks with CRUD operations and authentication.",
"category": "Node.js",
"difficulty": "Intermediate",
"timeEstimate": "2 hr",
"technologies": ["Express", "MongoDB", "JWT"],
"targetSkills": ["REST APIs", "Authentication", "Database Design"]
}
}generate_slides_link
Generates a link to interactive learning slides on Marble.
Parameters:
query(required): A comprehensive prompt that includes:The main topic or concept to explain
Relevant code snippets from the codebase
Specific implementation details
Context about how the concept is used
Example:
{
"query": "Explain React hooks with examples from our codebase. Here's how we use useState in UserProfile.tsx: [code snippet]. Here's how we use useEffect in DataFetcher.tsx: [code snippet]. Focus on explaining the dependency array and cleanup functions."
}Returns: A markdown link like 🎓 [Learn: Explain React hooks...](https://withmarble.ai/learn?prompt_id=abc123)
Project Link Format
Generated links follow this format:
https://withmarble.io/projects/plan?projectData={urlEncodedJSON}The JSON structure includes all project metadata, which is decoded by the Marble platform to populate the project creation page.
Development
Watch Mode
npm run watchRebuild
npm run buildExample Interaction
User: "I want to learn about the React patterns used in this codebase"
Claude Code:
Uses
suggest_learning_projectswith topic "React patterns"Searches codebase for React components using Glob/Grep
Reads relevant files to understand patterns
Generates 3 project ideas:
Beginner: "Component Composition with Props"
Intermediate: "Custom Hooks for Data Fetching"
Advanced: "Compound Components Pattern"
Uses
generate_marble_linkfor each projectPresents projects with Marble links
Result: User gets 3 clickable links to create these projects on withmarble.io
How It Works
User asks for learning projects in Claude Code
MCP tool is invoked by Claude Code
Claude Code analyzes codebase using its file reading tools
Projects are generated based on code analysis
Links are created using the Marble platform URL format
User clicks link to start the project on withmarble.io
License
MIT
Available Tools
3 toolsgenerate_marble_linkB
Use this tool to generate Marble platform links for learning projects. Takes an array of 1-3 projects and returns markdown-formatted links (one per line) that can be inserted into project descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| projects | Yes | Array of 1-3 project objects to generate links for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the input constraint 'array of 1-3 projects' and output format 'markdown-formatted links', but lacks critical behavioral details: whether this is a read-only operation, if it makes external API calls, what happens with invalid inputs, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at two sentences with zero wasted words. It front-loads the core purpose, specifies input constraints, and describes the output format and use case efficiently. Every sentence earns its place by providing distinct, valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter with rich nested structure) and 100% schema coverage but no annotations or output schema, the description is adequate but incomplete. It covers the basic purpose and output format but lacks behavioral context about how the tool operates, what the generated links look like, or potential error conditions. The absence of an output schema means the description should ideally explain the return format more thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing comprehensive documentation of the single parameter 'projects' and its nested object structure. The description adds minimal value beyond the schema, only reiterating the array size constraint '1-3 projects' without explaining why this range exists or how the projects parameter relates to the generated links. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'generate Marble platform links for learning projects' and specifies the output format 'markdown-formatted links'. It distinguishes itself from siblings by focusing on link generation rather than slide creation or project suggestion. However, it doesn't explicitly contrast with generate_slides_link beyond the different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the links are 'for learning projects' and 'can be inserted into project descriptions', suggesting integration into documentation workflows. However, it provides no explicit guidance on when to use this tool versus the sibling tools generate_slides_link or suggest_learning_projects, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_slides_linkA
Use this tool to generate a Marble platform link for interactive learning slides that EXPLAIN or TEACH concepts. Trigger this for ANY mention of: 'slides', 'marble slides', 'explain', 'teach me', 'show me', 'help me understand', 'how does X work', 'how is X done', 'how are X generated', 'walkthrough', 'tutorial', 'lesson', 'presentation', 'break down', 'give me an explanation', or similar explanation/teaching phrases. IMPORTANT: The query parameter must be LIMITED TO 6 PARAGRAPHS MAXIMUM. Before calling this tool, you should: 1) Read relevant code files from the codebase, 2) Analyze the code patterns and structure, 3) Summarize the most important context into 6 paragraphs or fewer. Focus on quality over quantity - include only the most relevant details. CRITICAL: After calling this tool, you MUST include the returned markdown link in your response to the user. The tool returns a clickable link - DO NOT just summarize or describe what the slides contain. Always show the actual link so the user can click it.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | A short, concise title for the slides (e.g., 'React Hooks', 'Authentication Flow', 'Database Design'). Should be free of special characters except spaces. This will be used as the link text. | |
| query | Yes | A comprehensive but CONCISE query LIMITED TO 6 PARAGRAPHS MAXIMUM. Each paragraph should cover one key aspect: (1) The main topic or concept to explain, (2) Key code patterns or snippets (keep code examples brief), (3) Important implementation details, (4) How the concept is used in context, (5) Specific focus areas, (6) Any additional critical context. DO NOT exceed 6 paragraphs - summarize and prioritize the most important information. Example: 'Explain React hooks in our codebase. We use useState for local state management, particularly in UserProfile.tsx for form data. Our useEffect patterns handle data fetching with cleanup functions to prevent memory leaks. The dependency array is carefully managed to avoid infinite loops. Focus on explaining these patterns and best practices.' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing critical behavioral traits: it explains the 6-paragraph limit for queries, specifies pre-call steps (read code, analyze, summarize), and mandates post-call actions (include the returned link, don't just summarize). However, it doesn't mention rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and triggers, but becomes verbose with detailed instructions (pre-call steps, post-call mandates). While all information is relevant, some sentences could be more streamlined (e.g., combining related points about paragraph limits). It's comprehensive but slightly over-explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (requires pre-processing and has specific output handling), no annotations, and no output schema, the description does well by covering purpose, usage, behavioral constraints, and parameter guidance. It lacks details on the returned link format or error cases, but provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by emphasizing the 6-paragraph limit for the 'query' parameter and providing context on how to structure content (focus on quality, include only relevant details). It doesn't add syntax details beyond the schema, but reinforces constraints effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'generate a Marble platform link for interactive learning slides that EXPLAIN or TEACH concepts.' It specifies the verb ('generate'), resource ('Marble platform link'), and distinguishes from siblings by focusing on explanation/teaching slides rather than general links or project suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage triggers with a comprehensive list of phrases ('slides', 'explain', 'teach me', etc.) and clear prerequisites (reading code files, analyzing patterns, summarizing context). It also specifies when to use it versus alternatives by distinguishing it from sibling tools through its teaching focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_learning_projectsA
Use this tool when the user wants to PRACTICE or BUILD something to learn. Trigger this for ANY mention of: 'projects', 'marble projects', 'practice', 'exercises', 'build something', 'hands-on', 'try building', 'create a project', 'project ideas', 'what should I build', 'learn by doing', or similar learning-by-building phrases. This tool instructs the AI agent to: 1) Read relevant code from the codebase, 2) Analyze patterns and technologies used, 3) Generate project ideas that help learn those technologies, 4) Return formatted Marble platform links.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | What the user wants to learn (e.g., 'React hooks', 'authentication', 'database design') | |
| codeContext | No | Optional: Specific files or directories to analyze (e.g., 'src/components', 'api/auth.js') | |
| difficulty | No | Preferred difficulty level for projects |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It outlines the tool's process steps (read code, analyze patterns, generate ideas, return links), which adds useful context beyond basic functionality. However, it lacks details on potential limitations, error handling, or performance aspects like rate limits or authentication needs, leaving some behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with usage triggers and then detailing the tool's steps. Each sentence serves a purpose: the first sets context, the second lists triggers, and the third explains the process. However, it could be slightly more concise by integrating the trigger list more smoothly, but overall it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is moderately complete. It explains the tool's purpose, usage, and process, but lacks details on output format (beyond 'formatted Marble platform links'), error cases, or dependencies. Without annotations or output schema, more behavioral context would improve completeness, but it's adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents all parameters (topic, codeContext, difficulty) with descriptions and enums. The description doesn't add any additional meaning or examples beyond what the schema provides, such as clarifying how parameters interact or affect output. Thus, it meets the baseline but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to generate project ideas for learning by analyzing code patterns and technologies. It specifies the verb 'instructs the AI agent to' with steps like 'Read relevant code', 'Analyze patterns', and 'Generate project ideas'. However, it doesn't explicitly differentiate from sibling tools like generate_marble_link or generate_slides_link, which might serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines, stating 'Use this tool when the user wants to PRACTICE or BUILD something to learn' and listing specific trigger phrases such as 'projects', 'practice', 'build something', etc. This gives clear context for when to invoke the tool, though it doesn't mention when not to use it or alternatives, but the trigger list is comprehensive enough for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.28- First observed
generate_marble_link - First observed
generate_slides_link - First observed
suggest_learning_projects
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: generate_marble_link creates links for existing projects, generate_slides_link creates links for explanatory slides, and suggest_learning_projects suggests new project ideas for practice. There is no overlap in functionality, and the descriptions clearly differentiate when to use each tool.
All tool names follow a consistent verb_noun pattern with snake_case: generate_marble_link, generate_slides_link, and suggest_learning_projects. The naming is predictable and readable throughout the set.
With only 3 tools, the server feels thin for a learning platform domain. While the tools cover key functions (linking projects, slides, and project suggestions), the scope might benefit from additional tools for managing or customizing learning content, making the count borderline for the apparent purpose.
The tool set covers core learning workflows: generating links for projects and slides, and suggesting projects for practice. However, there are minor gaps such as tools for updating or deleting links, tracking progress, or integrating with other learning resources, which agents might need to work around.
Related MCP Connectors
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.