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., "@Simple Remote MCP Server say hello to 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 repository demonstrates how to create, test, and deploy a simple remote MCP server using FastMCP, uv, and GitHub.
Make sure you have the following installed:
Python 3.10+
uv (Python package manager)
Git
VS Code (recommended)
Node.js (for MCP Inspector)
Related MCP server: MCP Template
uvuv is a fast Python package manager and runtime.
pip install uvmkdir simple-mcp-server
cd simple-mcp-servercode .uv initThis creates:
pyproject.toml
Virtual environment configuration
uv add fastmcpFastMCP allows you to build MCP-compatible servers easily.
Create a file called main.py:
from fastmcp import FastMCP
mcp = FastMCP("Simple MCP Server")
@mcp.tool()
def hello(name: str) -> str:
return f"Hello, {name}! Welcome to MCP."
if __name__ == "__main__":
mcp.run()uv run main.pyYour MCP server will start locally.
Use MCP Inspector to:
Connect to the server
Verify tools are listed
Send test requests
This confirms your server is MCP-compliant.
Create a new repo on GitHub named:
simple-mcp-servergit init
git add .
git commit -m "Initial commit: Simple MCP server"git remote add origin https://github.com/yourusername/simple-mcp-server.git
git push -u origin mainCreate an account on FastMCP Cloud
Connect your GitHub repository
Deploy the project
After deployment:
Your MCP server gets a public endpoint
It can be used by MCP clients and LLM agents
simple-mcp-server/
│── main.py
│── pyproject.toml
│── README.mdAdd more MCP tools
Connect this server to LLM agents
Add authentication & logging
Happy building 🚀
Add two numbers together.
Args: a: First number b: Second number
Returns: The sum of a and b
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the operation ('Add two numbers together') and return value, but lacks details on error handling, performance, or constraints like input limits. This leaves gaps in understanding how the tool behaves beyond basic functionality.
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 the core purpose. The structured sections (Args, Returns) enhance readability without redundancy. It could be slightly more concise by integrating the parameter details into a single sentence, but overall it's efficient.
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 low complexity (simple arithmetic), no annotations, and an output schema that likely covers the return value, the description is mostly complete. It explains the operation and parameters adequately, though it could benefit from more behavioral context like error cases or usage examples.
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 0%, so the description must compensate. It explicitly defines parameters 'a' and 'b' as 'First number' and 'Second number', adding clear meaning beyond the schema's type definitions. However, it doesn't specify constraints like number ranges, leaving some semantic gaps.
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 specific action ('Add two numbers together') and identifies the resource (numbers). It distinguishes itself from siblings like 'call_tool' or 'execute_prompt_with_llm' by focusing on basic arithmetic, making the purpose unambiguous and well-defined.
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 versus alternatives. It lacks context about prerequisites, such as whether it's for simple calculations or part of a larger workflow, and doesn't mention any sibling tools as alternatives, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random number within a range.
Args: min_val: Minimum value (default: 1) max_val: Maximum value (default: 100)
Returns: A random integer between min_val and max_val
| Name | Required | Description | Default |
|---|---|---|---|
| min_val | No | ||
| max_val | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions that the tool 'generates' a random number, implying a read-only operation, but doesn't address important behavioral aspects like whether the generation is truly random, if there are any rate limits, or what happens with invalid input ranges. The description adds minimal behavioral context beyond the basic function.
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 structured and concise. It begins with a clear purpose statement, then provides parameter documentation in a clean Args/Returns format. Every sentence earns its place, and there's no wasted verbiage. The information is front-loaded with the most important details first.
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 low complexity (2 simple parameters) and the presence of an output schema (implied by 'Returns' section), the description is reasonably complete. It explains what the tool does, documents the parameters, and specifies the return value. However, it could be more complete by addressing potential edge cases or behavioral constraints.
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 0%, so the description must compensate. It does this effectively by explaining both parameters: 'min_val: Minimum value (default: 1)' and 'max_val: Maximum value (default: 100)'. This adds clear meaning beyond what the bare schema provides, though it doesn't explain edge cases like what happens if min_val > max_val.
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 random number within a range.' This is a specific verb+resource combination that tells the agent exactly what the tool does. However, it doesn't explicitly differentiate from the sibling 'add' tool, which appears to be a mathematical operation rather than a random number generator, so it doesn't fully address sibling distinction.
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 versus alternatives. There's no mention of when this tool is appropriate, what scenarios it's designed for, or how it compares to the sibling 'add' tool. The agent must infer usage from the purpose alone.
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.0addrandom_numberScored across 2 tools
The two tools have clearly distinct purposes: 'add' performs arithmetic addition on two numbers, while 'random_number' generates a random integer within a specified range. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.
The naming is mixed: 'add' is a simple verb, while 'random_number' uses a noun phrase with an underscore. This lacks a consistent pattern like verb_noun, but the names are still readable and descriptive enough to understand their functions.
With only 2 tools, the server feels thin and under-scoped for a 'Simple Remote MCP Server' that might imply broader utility. While the tools are functional, the count is too low to cover a meaningful domain, limiting the server's coherence and usefulness for agents.
Inferred as a basic utility server, the tool set is severely incomplete; it lacks common operations like subtraction, multiplication, or other random generation methods (e.g., floats). This creates significant gaps that could lead to agent failures when trying to perform basic mathematical or random tasks.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
