Provides a tool to fetch Python package project information from PyPI, such as package metadata and release details, while safely excluding user-controlled content like project summaries.
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., "@mcp-server-template get info on the requests package"
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.
Opinionated template for building read-only MCP servers that coding agents can actually use well: I/O seams with timeouts, offline tests, compact text outputs, least-privilege docs.
Start here → BUILDING.md — the full workflow from idea to published server (~half a day).
What's inside: a working example server (pypi_project fixed-origin HTTP tool behind a stubbed seam + word_stats pure tool), offline test suite, CI workflow, CLAUDE.md conventions, and a README skeleton below.
The network example deliberately does not accept arbitrary URLs. "Read-only" does not make a URL fetcher safe: unrestricted destinations and followed redirects can expose loopback, private-network, or cloud-metadata services. pypi_project constructs only https://pypi.org/... requests, rejects URL/path-shaped input, never follows redirects, caps the decoded response at 2 MiB, and applies a 15-second whole-operation deadline.
# mcp-<name> + one-line value prop in bold
4-line usage transcript (You: … / Agent: → tool calls / Agent: answer)
Tools table (tool → what it returns)
Install: claude mcp add <name> -- python -m mcp_<name> with any token preloaded into the launching environment from your shell or OS secret manager — never a -e TOKEN=... literal (command arguments can enter shell history and process listings) — plus a .mcp.json block using an env reference ("env": { "TOKEN": "${TOKEN}" })
Token scope / security (least privilege, read-only statement)
Design notes (why read-only, why compact text, why timeouts)
License + contact line
Use the structure above directly; replace every template name and example before publishing a derived server.
Related MCP server: MCP Server Template
The example sends only the supplied package name to PyPI. Do not put secrets or private identifiers in tool arguments.
PyPI project summaries are uploader-controlled prose, so the example deliberately omits them from agent-visible output. Treat all external text as untrusted data.
Never log credentials, authorization headers, raw private responses, or user prompts.
Document which external service receives each argument. Private CI logs and internal URLs are sensitive even when a tool only reads them.
Keep arbitrary URL fetching out of derived servers unless you implement a destination allowlist and a transport that cannot be bypassed by redirects or DNS rebinding.
python -m pip install -e ".[dev]"
ruff check . && ruff format --check .
pytest
python -m buildMIT — see LICENSE.
Look up one PyPI project: returns its current version, Python requirement, and request latency. Use before checking a Python dependency's compatibility. Only the fixed https://pypi.org API is contacted; URLs are rejected. Uploader prose such as the project summary is deliberately omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose non-obvious behavior: only the fixed https://pypi.org API is contacted, arbitrary URLs are rejected, and uploader prose is omitted (so the agent should not expect a summary field). It stops short of stating rate limits or auth requirements, but the security/scope posture is well covered.
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?
Four short sentences, front-loaded with the operation and its outputs before the usage hint and constraints. Nothing is redundant, though the 'request latency' return detail is slightly peripheral to the tool's purpose.
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?
An output schema exists, so return values need not be spelled out, yet the description still names the key fields. Combined with the security constraints and usage framing, an agent has enough to call this correctly; only parameter format guidance is missing.
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 coverage is 0% and the single 'project' string parameter has no description, so the description must compensate. It partially does by implying a PyPI project identifier and explicitly stating that URLs are rejected, which steers the agent away from passing a URL, but it never states the expected name format or normalization.
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?
States a specific verb and resource ('Look up one PyPI project') and immediately enumerates the core return fields (current version, Python requirement, request latency). The scope word 'one' distinguishes it from any bulk lookup, and the sibling word_stats is clearly unrelated.
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?
Gives a concrete usage context: 'Use before checking a Python dependency's compatibility.' There are no real alternatives to weigh (the only sibling is word_stats), so the absence of explicit exclusions costs little, but there is no guidance on failure/no-match handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Word count plus the most frequent words of a text. Example of a pure, no-I/O tool: instant, deterministic, safe.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose real behavioral traits - pure, no I/O, instant, deterministic, safe - which is useful. However, it omits edge-case behavior (empty input, tokenization/case rules) and any note on how results are ordered or bounded.
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?
Two short sentences, front-loaded with the core capability. The second sentence earns partial credit by conveying the no-I/O/deterministic profile, though it reads as documentation boilerplate rather than agent-facing guidance.
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?
An output schema exists, so return formatting need not be described. But with 0% parameter coverage and no annotations, the description leaves the 'top' parameter and input expectations entirely undocumented - the agent must guess from the schema defaults alone.
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% and neither parameter is named in the description. 'Most frequent words' implicitly suggests a top-N limit but never states that the 'top' parameter controls it, its default of 5, or what 'text' must look like.
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 names a specific verb+resource: word count plus most-frequent-word extraction from a text. It is unambiguous what the tool computes. It does not differentiate from siblings, but the only sibling (pypi_project) is unrelated, so no meaningful confusion exists.
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 offers no when-to-use guidance, no alternatives, and no conditions or exclusions. 'Example of a pure, no-I/O tool' is meta-commentary about the tool's character, not routing guidance for an agent choosing between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0pypi_projectword_statsScored across 2 tools
The two tools target completely different domains (PyPI project lookup vs. text word statistics) with no overlap in function or purpose. An agent can easily select the correct tool without confusion.
Both tool names use consistent snake_case noun phrases (pypi_project, word_stats), adhering to a predictable naming pattern. Although not verb_noun, the convention is applied uniformly across the set.
Two tools is very thin for a functional MCP server and falls into the borderline '1-2 tools feels thin' category. However, as a template server, the small count may be intentional to demonstrate different tool types.
There is no coherent domain or lifecycle; the tools are isolated utilities with no way to list, search, update, or otherwise extend the surface. This leaves significant gaps for any real workflow an agent might attempt.
Primarily to be used as a template repository for developing MCP servers with FastMCP in Python, P…
Public read-only MCP server for Genvernium product and developer resources.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
