demo-server
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., "@demo-serveradd 5 and 3"
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.
MCP Tutorial
A minimal Model Context Protocol (MCP) tutorial built with the
MCP Python SDK (mcp[cli]). It contains a small
FastMCP server and shows how to make Claude Code aware of it through project configuration — without
running claude mcp add.
Contents
Related MCP server: Basic MCP Server
The server
The example server lives in examples/snippets/servers/fastmcp_quickstart.py
and exposes one of each MCP primitive:
Primitive | Name | Description |
Tool |
| Adds two numbers |
Resource |
| Returns a personalized greeting |
Prompt |
| Generates a greeting prompt |
Prerequisites
uv for running the project
Dependencies are declared in
pyproject.toml(mcp[cli]>=1.28.0)
Install dependencies:
uv syncRunning the server standalone
To run the server directly over streamable HTTP (listens on http://localhost:8000/mcp):
uv run examples/snippets/servers/fastmcp_quickstart.pyThis is only required for the HTTP transport option below. With the stdio option, Claude Code launches the server for you, so you don't need to run this manually.
Registering the server with a client
Each MCP client discovers servers from its own config file. The server configuration is nearly identical across clients — the differences are which file holds it and the top-level key name:
Client | Config file | Top-level key |
Claude Code |
|
|
GitHub Copilot |
|
|
Both files are committed to the repo, so anyone who clones it gets the same server configuration.
Claude Code
Claude Code learns about project-scoped MCP servers from a .mcp.json file at the repository root.
This file is the declarative equivalent of claude mcp add — it's committed to the repo, so anyone who
clones it gets the same server configuration.
Pick one of the two transport options below.
Option A — stdio (Claude Code launches the server)
Because the server lives in this project, you can let Claude Code spawn it on demand. There's no port and nothing to keep running separately.
{
"mcpServers": {
"demo-server": {
"command": "uv",
"args": ["run", "examples/snippets/servers/fastmcp_quickstart.py"]
}
}
}Note: For stdio, the server script must use the stdio transport. FastMCP uses stdio by default when you call
mcp.run()with no arguments, so change the last line of the script tomcp.run()(or run a stdio-specific entry point).
Option B — HTTP transport
If you'd rather run the server yourself as a long-running HTTP process, point .mcp.json at its URL
instead. First start the server (see Running the server standalone),
then use:
{
"mcpServers": {
"demo-server": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}With this option the server must already be running before Claude Code connects.
Note: For HTTP, the server script must use the streamable HTTP transport. In
fastmcp_quickstart.pythe defaultmcp.run()is commented alongsidemcp.run(transport="streamable-http")— swap the active line so the script runs over HTTP:if __name__ == "__main__": mcp.run(transport="streamable-http") # mcp.run() # default transport is stdio
Reload and verify
Restart Claude Code (or run
/mcpin an interactive session).From the terminal, check status with:
claude mcp list claude mcp get demo-serverThe server should report ✔ Connected and expose the
addtool, thegreeting://{name}resource, and thegreet_userprompt.
GitHub Copilot (VS Code)
VS Code discovers workspace MCP servers from .vscode/mcp.json. Note the top-level
key is servers (not mcpServers), and each entry declares its transport with type.
Pick one of the two transport options below.
stdio
VS Code launches the server for you — no port, nothing to keep running separately:
{
"servers": {
"demo-server": {
"type": "stdio",
"command": "uv",
"args": ["run", "examples/snippets/servers/fastmcp_quickstart.py"]
}
}
}Note: As with Claude Code, the script must use the stdio transport (
mcp.run()).
HTTP transport
Run the server yourself first (see Running the server standalone), then point VS Code at its URL:
{
"servers": {
"demo-server": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}Note: For HTTP, the script must use
mcp.run(transport="streamable-http")(see the Claude Code HTTP note).
Start and verify
Open
.vscode/mcp.json— VS Code shows a Start action above each server entry. You can also run MCP: List Servers from the Command Palette to start/stop/inspect them.Open the Copilot Chat view and switch to Agent mode (tools are only available in agent mode).
Click the tools (🛠) icon to confirm
demo-serveris listed, then ask Copilot to use theaddtool.
Approving servers and auto-approving tools (Claude Code)
Claude Code has two independent safety gates for project MCP servers, both configured in
.claude/settings.json (shared, committed) or .claude/settings.local.json (personal, git-ignored):
Server approval — whether a server from
.mcp.jsonis allowed to load at all.Tool-call approval — whether Claude may run a server's tools without prompting you each time.
This section walks through both, using the lifespan-demo server (which exposes the query_db tool) as
the example.
Step 1 — Approve the server
Servers declared in .mcp.json start as ⏸ Pending approval as a safety measure — a cloned repo can't
auto-run servers without your consent. Grant approval declaratively with enabledMcpjsonServers instead
of clicking through the interactive prompt:
{
"enabledMcpjsonServers": ["demo-server", "lifespan-demo"]
}Or trust every server defined in .mcp.json at once:
{
"enableAllProjectMcpServers": true
}After this, the server loads and its tools become visible — but Claude will still ask permission each time it wants to call one.
Step 2 — Auto-approve tool calls
To stop the per-call prompts, add a permissions.allow rule. The MCP rule format is:
Rule | Matches |
| Every tool from the |
| Only the |
Note: the tool part does not support
*wildcards — use the server-only form (mcp__<server>) to cover all tools, or name a specific tool (mcp__<server>__<tool>).
Combined with Step 1, .claude/settings.json looks like:
{
"enabledMcpjsonServers": ["demo-server", "lifespan-demo"],
"permissions": {
"allow": ["mcp__lifespan-demo"]
}
}Reload Claude Code (restart or /mcp), then ask:
Use the query_db tool to run
SELECT * FROM users
It runs without a permission prompt and returns Result of 'SELECT * FROM users'.
Scope tip: keep server approval (
enabledMcpjsonServers) in the sharedsettings.jsonso teammates get the server, but consider putting auto-approval (permissions.allow) insettings.local.jsonif you don't want to silently grant tool execution to everyone who clones the repo.
Debugging with the MCP Inspector
The MCP Inspector is an interactive, browser-based tool for poking at a server directly — without wiring it into Claude Code or Copilot. It's the quickest way to call tools by hand and watch logs and progress notifications live.
Launch it against any server in this repo:
uv run mcp dev examples/snippets/servers/<server_file>.py
uv run mcp dev examples/snippets/servers/basic_tool.pyWhat this does:
uv runruns inside the project virtualenv (somcpand your deps are available).mcp devstarts the server over stdio and attaches the Inspector to it.It prints a
localhostURL — open it in a browser.
The Inspector uses two ports: 6274 (the web UI) and 6277 (the proxy). In the UI you can:
List and call tools — e.g. run
long_running_taskwith atask_nameandsteps.Browse resources and prompts.
Watch logs and progress notifications live — the best way to see
Contextcalls (ctx.info,ctx.debug,ctx.report_progress) as they happen.
Requires Node.js. The Inspector is a Node package (
@modelcontextprotocol/inspector) launched vianpx; the first run downloads it.Auth token. Recent versions print a URL that includes a session token, e.g.
http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=…— use that full link from the terminal.Port already in use?
❌ Proxy Server PORT IS IN USE at port 6277means an Inspector is already running — just open http://localhost:6274, or stop the existing one first. It's a long-running process; stop it withCtrl-C.
Configuration reference
File | Purpose | Committed? |
| Declares the project MCP server for Claude Code | Yes (shared) |
| Declares the workspace MCP server for Copilot | Yes (shared) |
| Approves servers + auto-approves tools for the team | Yes (shared) |
| Approves servers + auto-approves tools just for you | No (git-ignored) |
Available Tools
1 tooladdA
Add two numbers
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is a pure function with no side effects, and the sole behavior 'Add two numbers' is fully disclosed. With no annotations to contradict, the description provides complete behavioral transparency for this simple operation.
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 a single sentence with no unnecessary words; it is front-loaded and earns its place. It communicates everything needed in the most compact form possible.
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 simple nature and the presence of an output schema (per context signal), the description sufficiently covers the function. There are no complex behaviors, side effects, or conditional logic to document.
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 0%, yet the description only generically mentions 'two numbers' without explaining the meaning or constraints of parameters a and b. It does not compensate for the lack of schema descriptions, leaving parameter semantics under-specified.
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 uses the specific verb 'Add' and identifies the resource as 'two numbers', clearly distinguishing it from the sibling arithmetic tools subtract, multiply, and divide. It is unambiguous and precisely states the tool's function.
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 is concise but does not explicitly state when to use this tool over alternatives; however, the operation is self-evident for the sibling context. It lacks explicit exclusions or alternative guidance, but the clear context of adding numbers implicitly covers the main use case.
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.
1 tool update
v0.1.0- First observed
add
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity. The tool's purpose is clear and distinct.
The single tool name 'add' follows a simple verb pattern, and there are no other tools to create inconsistency.
A single tool for addition is extremely limited, lacking any broader functionality. This is a trivial tool count that does not justify a full server.
The server only provides addition, missing essential arithmetic operations like subtraction, multiplication, or division. The surface is severely incomplete for any practical use.
Maintenance
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
POC MCP server. Tool say_hello returns 'Welcome' (agent -> MCP -> API path).
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA minimal demonstration server showcasing MCP protocol capabilities including tools, resources, and prompts with basic examples like hello world functionality.7MIT
- AlicenseNot gradedqualityDmaintenanceA minimal template MCP server demonstrating basic tools, resources, and prompts functionality. Includes example implementations like a hello tool, history resource, and greet prompt for learning MCP development.7ISC
- FlicenseNot gradedqualityDmaintenanceA minimal Model Context Protocol server built with FastMCP that provides basic utility tools including user greetings, number addition, and file listing operations. Includes examples of exposing tools, resources, and prompts for MCP-aware clients.-
- AlicenseNot gradedqualityDmaintenanceA minimal learning-focused MCP server that demonstrates core primitives like tools and resources through simple greeting functions. It provides a foundational example for connecting AI models to external data using both Streamable HTTP and stdio transports.5MIT