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 show me the server info"
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.
A Falken's Lab MCP server. The starting point for Falken's Lab's MCP servers: one bundled file, tests, docs in English and Spanish, ready for agent-kit.
This is a template repository: every Falken's Lab MCP server starts here, so they all look and work the same. It's an MCP server over stdio, written in TypeScript with the official MCP SDK and bundled into a single file that runs with npx, so an agent built on agent-kit can run it without installing anything. It comes with one example tool, tests, a strict check of its tools, CI, a documentation site in English and Spanish, and the design notes every server shares.
📦 One file, nothing to install. esbuild bundles every dependency into dist/server.mjs, which agent-kit runs with npx.
🧭 Tools a model chooses well. Each tool has a title, a description for the model, schemas and readOnlyHint, and npm run check fails if one doesn't.
🔧 Programs installed apart, explained. A server that needs Docker or ffmpeg declares it once and gets check_requirements and clear errors; it never installs anything.
🧪 Tested from the start. node:test with the SDK's in-memory transport, and CI on Node 20 and 24.
🌍 Docs in two languages. A Docusaurus site in English and Spanish, with the tools reference generated from the server itself.
🧠 Design memory. .minispec/ with the decisions every Falken's Lab server shares, and a CLAUDE.md for coding agents.
Related MCP server: mcp-toolforge
On GitHub, Use this template to create the new repository, then:
npm install
npm run init -- docker-lab-mcp "Hands-on practices in Docker, safe by default."
npm run build && npm run checkinit renames the package, the command, the links and the docs, and notes in .minispec/core/stack.md the template's commit it comes from, so later fixes here can be found with git log <commit>..main. Then rewrite .minispec/core/project.md and this README for the new server, and add its tools in src/tools/.
Area | For example |
🔌 Server |
|
🛠️ Tools |
|
🔧 Requirements |
|
🧪 Checks |
|
📖 Docs |
|
🧠 Design |
|
The template has no site of its own: docs/ is the one each server publishes. What a new server needs is here:
CLAUDE.md: the commands, how the pieces fit, and the skills in .claude/skills/ (adding a tool, checks, docs, releases).
.minispec/: the project, its conventions and the decisions every Falken's Lab server shares.
docs/: the site's skeleton, with getting started, the tools reference generated from the server and the releases; cd docs && npm install && npm start previews it.
npm run build, npm test and npm run check before every commit; CLAUDE.md lists every command, and .minispec/ the decisions behind them. Releases are published to npm by the owner.
Made with 💖 by Falken's Lab Team
Show this server's name, version and data folder, and, for a server that needs programs installed apart, whether they're there. Contains no secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| node | Yes | |
| dataDir | Yes | Where it keeps its state and caches |
| version | Yes | |
| requirements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful disclosure — "Contains no secrets" — signaling the output is safe to surface, plus the conditional behavior of reporting whether separate programs are installed.
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?
A single sentence, front-loaded with the primary payload (name, version, data folder) and ending with the conditional check. The clause about separately-installed programs is slightly wordy but earns its place by describing a non-obvious behavior.
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?
For a no-param, read-only tool with an output schema documenting the return shape and annotations covering safety, the description supplies everything an agent needs: what it returns, the conditional program check, and the reassurance that no secrets are exposed.
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 tool takes no parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The enumerated output fields are not parameters and belong to the output schema.
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 ("Show") and enumerates exactly what is retrieved: server name, version, data folder, plus whether separately-installed programs are present. An agent knows precisely what this tool returns without opening the schema.
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?
There is no explicit when-to-use statement, no prerequisites, and no alternatives named (there are no siblings). For a zero-parameter informational tool the intended use is implied and obvious, so this is adequate but not enriched.
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.0.0server_infoScored across 1 tool
Only one tool exists, so there is no possibility of selecting the wrong tool. The tool's purpose is clear from its name and description.
With a single tool named 'server_info', there is no inconsistency or deviation from a pattern. The snake_case convention is clear and readable.
A single trivial tool ('server_info') is an extreme mismatch for any functional MCP server. The server offers no domain operations, only diagnostic information.
The tool surface is severely incomplete: it only reports server metadata and provides no CRUD or lifecycle operations for any domain. There are no workflows an agent could complete with this server.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.
Create guides as MCP servers to instruct coding agents to use your software (library, API, etc).
