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., "@xmcp-demo greet Alice"
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.
This project was created with create-xmcp-app.
First, run the development server:
npm run dev
# or
yarn dev
# or
pnpm devThis will start the MCP server with the selected transport method.
Related MCP server: xmcp Application
This project uses the structured approach where tools, prompts, and resources are automatically discovered from their respective directories:
src/tools - Tool definitions
src/prompts - Prompt templates
src/resources - Resource handlers
Each tool is defined in its own file with the following structure:
import { z } from "zod";
import { type InferSchema, type ToolMetadata } from "xmcp";
export const schema = {
name: z.string().describe("The name of the user to greet"),
};
export const metadata: ToolMetadata = {
name: "greet",
description: "Greet the user",
annotations: {
title: "Greet the user",
readOnlyHint: true,
destructiveHint: false,
idempotentHint: true,
},
};
export default function greet({ name }: InferSchema<typeof schema>) {
return `Hello, ${name}!`;
}Prompts are template definitions for AI interactions:
import { z } from "zod";
import { type InferSchema, type PromptMetadata } from "xmcp";
export const schema = {
code: z.string().describe("The code to review"),
};
export const metadata: PromptMetadata = {
name: "review-code",
title: "Review Code",
description: "Review code for best practices and potential issues",
role: "user",
};
export default function reviewCode({ code }: InferSchema<typeof schema>) {
return `Please review this code: ${code}`;
}Resources provide data or content with URI-based access:
import { z } from "zod";
import { type ResourceMetadata, type InferSchema } from "xmcp";
export const schema = {
userId: z.string().describe("The ID of the user"),
};
export const metadata: ResourceMetadata = {
name: "user-profile",
title: "User Profile",
description: "User profile information",
};
export default function handler({ userId }: InferSchema<typeof schema>) {
return `Profile data for user ${userId}`;
}To add a new tool:
Create a new .ts file in the src/tools directory
Export a schema object defining the tool parameters using Zod
Export a metadata object with tool information
Export a default function that implements the tool logic
To add a new prompt:
Create a new .ts file in the src/prompts directory
Export a schema object defining the prompt parameters using Zod
Export a metadata object with prompt information and role
Export a default function that returns the prompt text
To add a new resource:
Create a new .ts file in the src/resources directory
Use folder structure to define the URI (e.g., (users)/[userId]/profile.ts → users://{userId}/profile)
Export a schema object for dynamic parameters (optional for static resources)
Export a metadata object with resource information
Export a default function that returns the resource content
To build your project for production:
npm run build
# or
yarn build
# or
pnpm buildThis will compile your TypeScript code and output it to the dist directory.
You can run the server for the transport built with:
HTTP: node dist/http.js
STDIO: node dist/stdio.js
Given the selected transport method, you will have a custom start script added to the package.json file.
For HTTP:
npm run start-http
# or
yarn start-http
# or
pnpm start-httpFor STDIO:
npm run start-stdio
# or
yarn start-stdio
# or
pnpm start-stdioGreet the user
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the user to greet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds no extra behavioral context. It does not mention return values, side effects, or any other runtime behavior beyond the implicit greeting, offering no value beyond the structured metadata.
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?
While the description is very short, it is a verbatim repeat of the title, making it redundant. It does not earn its place because it provides zero incremental information, which is under-specification rather than effective conciseness.
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 simple tool, the description is minimal but incomplete. With no output schema, the description should clarify what the tool returns or what a greeting entails, but it does not. The annotations cover safety but not functional outcomes, so the description is insufficient.
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 input schema has 100% description coverage for the 'name' parameter, so the baseline is 3. The tool description does not add any further meaning or usage detail for the parameter, so the schema is sufficient.
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?
Tautological: description restates name/title.
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 no guidance on when to use this tool, prerequisites, or alternatives. With no sibling tools, there is no context given for appropriate usage scenarios.
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.0greetScored across 1 tool
With only one tool, there is no possibility of confusion. The purpose of 'greet' is completely distinct and unambiguous.
The single tool name 'greet' is a clear, concise verb that follows a simple convention. There is no inconsistency to evaluate with only one tool.
A single trivial tool like 'greet' is an extreme mismatch for an MCP server. It provides minimal value and does not justify a server deployment.
For the stated domain of greeting, the tool fully covers the intended action. There are no missing operations for such a trivial use case.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for generating rough-draft project plans from natural-language prompts.
