Click on "Install 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: Python MCP Server 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?
No annotations are provided, so the description carries full burden. It states what the tool does (addition) and the return value, but doesn't disclose any behavioral traits like error handling, precision limits, overflow behavior, or performance characteristics that would be important for an arithmetic 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 appropriately sized with clear sections (Args, Returns). The main purpose is stated upfront, and each sentence serves a clear purpose. The structure could be slightly improved by integrating the parameter descriptions more naturally rather than as separate labeled sections.
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 simplicity (2 integer parameters, no annotations, but has output schema), the description is reasonably complete. It explains what the tool does, what parameters mean, and what it returns. The output schema existence means the description doesn't need to detail return format, making this adequate for this simple arithmetic function.
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?
With 0% schema description coverage, the description compensates by clearly explaining both parameters ('First number' and 'Second number'). While it doesn't provide format details beyond what the schema already shows (integers), it adds meaningful semantic context for each parameter.
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 from the sibling tool 'random_number' by focusing on arithmetic addition rather than random generation.
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 implies usage for arithmetic addition but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about when not to use it or what other tools might be appropriate for different mathematical operations.
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. Dates show when Glama detected each change.
v0.1.0addrandom_numberThe 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ParthSharma1197/remote-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
