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., "@MCP Multi-Tool Server calculate 25% of 80"
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 comprehensive Model Context Protocol (MCP) server that provides calculator tools, documentation resources, and prompt templates. This server supports both stdio and SSE (Server-Sent Events) transports, making it compatible with various MCP clients including Claude Desktop.
add - Add two numbers
subtract - Subtract two numbers
multiply - Multiply two numbers
divide - Divide two numbers
power - Raise a number to a power
square_root - Calculate square root
factorial - Calculate factorial
calculate_percentage - Calculate percentage
TypeScript SDK Documentation - Access the full TypeScript SDK MCP documentation via resource URI typescript-sdk-mcp://documentation
Meeting Summary - Generate executive meeting summaries from transcripts using a customizable template
stdio (default) - Standard input/output for local integrations
SSE - Server-Sent Events for remote HTTP connections
Related MCP server: Math Calculator MCP Server
Python 3.10+ (Python 3.12 recommended)
uv - Fast Python package installer
Administrative privileges (for software installation)
Download Python from python.org/downloads
Run the installer and check "Add Python to PATH"
Verify installation:
python --version
pip --version# Using Homebrew (recommended)
brew install python@3.12
# Or download from python.orgsudo apt update
sudo apt install python3 python3-pip python3-venv -ypowershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Close and reopen PowerShell, then verify:
uv --versioncurl -LsSf https://astral.sh/uv/install.sh | shAdd to PATH if needed:
export PATH="$HOME/.cargo/bin:$PATH"Verify:
uv --version# Clone the repository
git clone <your-repo-url>
cd mcp-multi-tool-server
# Initialize project
uv init --no-readme
# Create virtual environment
uv venv
# Activate virtual environment
# Windows PowerShell:
.\.venv\Scripts\Activate.ps1
# Windows CMD:
.venv\Scripts\activate.bat
# macOS/Linux:
source .venv/bin/activate
# Install dependencies
uv add "mcp[cli]"# Activate virtual environment first
source .venv/bin/activate # or .\.venv\Scripts\Activate.ps1 on Windows
# Run the server
python server.pyThe server will start in stdio mode, ready to accept connections from MCP clients.
# Set transport to SSE
TRANSPORT=sse python server.py
# Or with custom host/port
TRANSPORT=sse HOST=0.0.0.0 PORT=8000 python server.pyThe server will start an HTTP server on the specified host and port, accessible via SSE.
Variable | Description | Default |
| Transport mode: |
|
| Host address for SSE transport |
|
| Port number for SSE transport |
|
python server.pyTRANSPORT=sse PORT=8080 python server.pyUse case: Local integrations, Claude Desktop, command-line tools
How it works:
Server communicates via standard input/output
Spawned as a subprocess by the MCP client
No network configuration needed
Configuration example:
{
"mcpServers": {
"multi-tool-server": {
"command": "uv",
"args": ["--directory", "/path/to/project", "run", "server.py"],
"env": {}
}
}
}Use case: Remote servers, web applications, HTTP-based clients
How it works:
Server runs as an HTTP server
Uses Server-Sent Events for real-time communication
Accessible via HTTP endpoints
Access URL:
http://localhost:8000/sseConfiguration example:
{
"mcpServers": {
"multi-tool-server": {
"type": "sse",
"url": "http://localhost:8000/sse"
}
}
}Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json# Windows PowerShell
Get-Location
# macOS/Linux
pwdOpen claude_desktop_config.json and add:
{
"mcpServers": {
"multi-tool-server": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/mcp-multi-tool-server",
"run",
"server.py"
],
"env": {
"TRANSPORT": "stdio"
}
}
}
}Important:
Use absolute paths (not relative)
On Windows, use forward slashes / or escaped backslashes \\
Replace /absolute/path/to/mcp-multi-tool-server with your actual project path
Close and reopen Claude Desktop completely. All tools, resources, and prompts should now be available!
add(a: float, b: float) -> floatAdd two numbers together.
Example:
add(2, 3) # Returns: 5.0subtract(a: float, b: float) -> floatSubtract the second number from the first.
Example:
subtract(10, 4) # Returns: 6.0multiply(a: float, b: float) -> floatMultiply two numbers.
Example:
multiply(5, 6) # Returns: 30.0divide(a: float, b: float) -> floatDivide the first number by the second.
Example:
divide(20, 4) # Returns: 5.0Error: Raises ValueError if divisor is zero.
power(base: float, exponent: float) -> floatRaise a number to a power.
Example:
power(2, 8) # Returns: 256.0square_root(number: float) -> floatCalculate the square root of a number.
Example:
square_root(16) # Returns: 4.0Error: Raises ValueError if number is negative.
factorial(n: int) -> intCalculate the factorial of a non-negative integer.
Example:
factorial(5) # Returns: 120 (5! = 5 Ć 4 Ć 3 Ć 2 Ć 1)Error: Raises ValueError if n is negative.
calculate_percentage(part: float, whole: float) -> floatCalculate what percentage one number is of another.
Example:
calculate_percentage(25, 100) # Returns: 25.0 (25%)Error: Raises ValueError if whole is zero.
typescript-sdk-mcp://documentationReturns the full content of the TypeScript SDK MCP documentation markdown file.
Usage: Access this resource through your MCP client to retrieve the documentation.
meeting_summary(meeting_date: str, meeting_title: str, transcript: str) -> list[dict]Generate an executive meeting summary from a transcript.
Parameters:
meeting_date: Date of the meeting (e.g., "2025-01-15")
meeting_title: Title of the meeting
transcript: Full meeting transcript text
Returns: A formatted prompt message ready to send to an LLM.
Template:
The prompt uses a template located at templates/meeting_summary/template.md with placeholders:
{{ meeting_date }}
{{ meeting_title }}
{{ transcript }}
Example Usage:
meeting_summary(
meeting_date="2025-01-15",
meeting_title="Q1 Planning Meeting",
transcript="John: Let's discuss Q1 goals..."
)mcp-multi-tool-server/
āāā .venv/ # Virtual environment
āāā templates/
ā āāā meeting_summary/
ā āāā template.md # Meeting summary prompt template
āāā __pycache__/ # Python cache
āāā server.py # Main server file
āāā pyproject.toml # Project configuration
āāā uv.lock # Dependency lock file
āāā README.md # This file
āāā Typerscript SDK MCP.md # Documentation resource
āāā claude_desktop_config.json.example # Example Claude Desktop config
āāā .gitignore # Git ignore rulesCreate a test file test_server.py:
from server import (
add, subtract, multiply, divide,
power, square_root, factorial, calculate_percentage
)
# Test all tools
assert add(2, 3) == 5.0
assert subtract(10, 4) == 6.0
assert multiply(5, 6) == 30.0
assert divide(20, 4) == 5.0
assert power(2, 8) == 256.0
assert square_root(16) == 4.0
assert factorial(5) == 120
assert calculate_percentage(25, 100) == 25.0
print("All tests passed!")Run:
python test_server.pyfrom server import get_typescript_sdk_documentation
content = get_typescript_sdk_documentation()
print(content[:100]) # Print first 100 charactersfrom server import meeting_summary
result = meeting_summary(
meeting_date="2025-01-15",
meeting_title="Test Meeting",
transcript="This is a test transcript."
)
print(result)Problem: python --version returns "command not found"
Solution:
Windows: Reinstall Python with "Add Python to PATH" checked
macOS/Linux: Use python3 instead of python
Problem: uv --version returns "command not found"
Solution:
Make sure you opened a new terminal after installation
Add ~/.cargo/bin (or %USERPROFILE%\.cargo\bin on Windows) to PATH
Restart terminal
Problem: Can't activate virtual environment
Solution:
Windows PowerShell: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Verify .venv folder exists: ls .venv (or dir .venv on Windows)
Problem: uv add "mcp[cli]" fails
Solution:
Ensure virtual environment is activated (you should see (.venv) in prompt)
Update uv: uv self update
Check Python version: python --version (should be 3.10+)
Problem: Server fails to start
Solution:
Verify virtual environment is activated
Check MCP is installed: uv pip list | grep mcp
Ensure server.py exists in current directory
Problem: Server doesn't appear in Claude Desktop
Solution:
Verify configuration file path is correct
Use absolute paths (not relative)
Check JSON syntax is valid
Ensure uv is in PATH or use full path
Restart Claude Desktop completely
Check Claude Desktop logs for errors
Problem: SSE server won't start
Solution:
Check if port is already in use: lsof -i :8000 (macOS/Linux) or netstat -ano | findstr :8000 (Windows)
Try a different port: PORT=8080 TRANSPORT=sse python server.py
Ensure firewall allows connections on the specified port
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request
This project is provided as-is for educational and personal use.
If you encounter any issues or have questions:
Check the Troubleshooting section
Search existing GitHub Issues
Create a new issue with:
Description of the problem
Steps to reproduce
Expected vs actual behavior
System information (OS, Python version, etc.)
Made with ā¤ļø using FastMCP and the Model Context Protocol
Add two numbers together.
Args:
a: The first number
b: The 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. While it mentions the basic operation, it doesn't disclose behavioral traits like error handling (e.g., for non-numeric inputs), performance characteristics, or any constraints. The description is minimal and lacks depth beyond the core 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 extremely concise and well-structured with clear sections for Args and Returns. Every sentence earns its place by directly explaining the tool's purpose, parameters, and output without any unnecessary information.
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 the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameters, and return value adequately, though it could benefit from more behavioral context.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explicitly defines 'a' as 'The first number' and 'b' as 'The second number', providing clear human-readable explanations that the schema lacks. This compensates well for the low schema coverage.
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 'Add two numbers together' which is a specific verb+resource combination. It distinguishes from siblings like subtract, multiply, and divide by specifying the addition operation, though it doesn't explicitly contrast with all siblings.
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 like subtract, multiply, or divide. It simply states what the tool does without any context about appropriate use cases or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate what percentage one number is of another number.
Args:
part: The part (the number you want to find the percentage of)
whole: The whole (the total or reference number)
Returns:
The percentage as a number (e.g., 25.0 means 25%)
Raises:
ValueError: If whole is zero
| Name | Required | Description | Default |
|---|---|---|---|
| part | Yes | ||
| whole | 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 full burden and does well by disclosing key behavioral traits: it explains the return format ('percentage as a number'), provides an example ('e.g., 25.0 means 25%'), and documents error behavior ('Raises: ValueError: If whole is zero'). It doesn't mention performance characteristics like rate limits, but covers core functionality adequately.
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: a clear purpose statement followed by well-organized sections for Args, Returns, and Raises. Every sentence earns its place, with no redundant information. The information is front-loaded with the core purpose 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 simplicity, 2 parameters, no annotations, but with output schema (implied by 'Returns' section), the description is complete enough. It explains purpose, parameters, return values, and error conditions. The output schema existence means the description doesn't need to explain return format in detail, but it still provides helpful context.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It clearly explains what 'part' and 'whole' represent ('The part (the number you want to find the percentage of)' and 'The whole (the total or reference number)'), which is essential for correct usage. This fully compensates for the schema's lack of descriptions.
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 with specific verb ('calculate') and resource ('percentage'), distinguishing it from sibling arithmetic tools like add, subtract, multiply, and divide. It precisely defines what percentage calculation means: 'what percentage one number is of another number.'
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 through the parameter explanations ('part' and 'whole'), but doesn't explicitly state when to use this tool versus alternatives like 'divide' or other mathematical operations. No explicit guidance on when-not-to-use or named alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Divide the first number by the second number.
Args:
a: The dividend (number to be divided)
b: The divisor (number to divide by)
Returns:
The quotient of a divided by b (a / b)
Raises:
ValueError: If b is zero (division by zero)
| 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 effectively describes the core behavior (division), explicitly states the error condition ('Raises: ValueError: If b is zero'), and clarifies the return value. However, it lacks details on edge cases (e.g., floating-point precision, negative numbers) or performance considerations.
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 well-structured with clear sections (Args, Returns, Raises) and front-loaded with the core purpose. Every sentence adds value: the first states the operation, and subsequent sections provide necessary details without redundancy. It's appropriately sized for a simple mathematical function.
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 (basic arithmetic), two parameters, no annotations, and the presence of an output schema (which handles return value documentation), the description is complete. It covers the operation, parameters, return value, and error conditions, leaving no significant gaps for this straightforward tool.
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 fully compensate. It provides clear semantic explanations for both parameters ('a: The dividend', 'b: The divisor'), which adds essential meaning beyond the schema's generic 'number' types. This fully addresses the parameter documentation gap.
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 mathematical operation ('divide the first number by the second number'), identifies the resource (numbers), and distinguishes this from sibling tools like 'add', 'multiply', or 'subtract' by specifying division. The purpose is unambiguous and differentiated.
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 like 'calculate_percentage' or other mathematical operations. It states what the tool does but offers no context about appropriate use cases, prerequisites, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the factorial of a non-negative integer.
The factorial of n (written as n!) is the product of all positive integers
less than or equal to n. For example: 5! = 5 Ć 4 Ć 3 Ć 2 Ć 1 = 120
Args:
n: A non-negative integer
Returns:
The factorial of n
Raises:
ValueError: If n is negative
| Name | Required | Description | Default |
|---|---|---|---|
| n | 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 and does well by disclosing key behavioral traits: it specifies the mathematical operation, input constraints (non-negative integer), return value, and error handling (raises ValueError for negative inputs). It doesn't cover performance aspects like rate limits or computational complexity, but provides sufficient context for basic use.
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 well-structured and front-loaded with the core purpose, followed by definition, example, and sections for args, returns, and raises. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 (single parameter, mathematical function) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, usage, parameters, and errors adequately. A minor gap is lack of explicit sibling tool differentiation, but overall it meets needs for this simple tool.
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 adds meaningful semantics by defining 'n' as a non-negative integer, explaining what factorial means with an example, and detailing error conditions. This goes beyond the bare schema, though it could elaborate on large integer handling or recursion limits.
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 calculates the factorial of a non-negative integer, providing a specific mathematical operation ('calculate the factorial') and distinguishing it from sibling tools like add, multiply, etc. It includes a mathematical definition and example, making the purpose unambiguous.
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 factorial calculations but doesn't explicitly state when to use this tool versus alternatives like 'power' or 'multiply' for related operations. It mentions the input constraint (non-negative integer) but lacks guidance on specific scenarios or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiply two numbers together.
Args:
a: The first number
b: The second number
Returns:
The product 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. While it states the basic operation, it doesn't mention important behavioral traits like error handling (e.g., overflow), performance characteristics, or any constraints on input values. The description is minimal and lacks context beyond the basic 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 and well-structured with clear sections for Args and Returns. Every sentence earns its place, and the information is front-loaded with the core purpose stated first. No wasted words or redundancy.
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 (basic arithmetic operation with 2 parameters) and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the purpose, parameters, and return value adequately for this straightforward tool, though it could benefit from more behavioral context.
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 ('a' as 'the first number' and 'b' as 'the second number'). It adds meaningful semantics beyond what the bare schema provides, though it doesn't specify constraints like numeric types or ranges.
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 verb ('multiply') and resource ('two numbers'), distinguishing it from siblings like 'add', 'divide', or 'subtract'. The first sentence directly explains what the tool does without being vague or tautological.
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 like 'add', 'divide', or 'power'. It doesn't mention any specific contexts, exclusions, or prerequisites for choosing multiplication over other mathematical operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raise a number to a power.
Args:
base: The base number
exponent: The exponent (power to raise the base to)
Returns:
The result of base raised to the power of exponent (base^exponent)
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| exponent | 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 describes the basic operation and return value, but lacks details on error handling (e.g., for invalid inputs like non-numeric values), performance, or other behavioral traits. It adds some context but is minimal.
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 with the purpose, followed by structured sections for arguments and returns. Every sentence earns its place by clearly explaining the tool's function and parameters without unnecessary details.
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 and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose and parameters well, but could benefit from more behavioral context (e.g., error cases) since no annotations are provided.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explicitly defines 'base' as 'The base number' and 'exponent' as 'The exponent (power to raise the base to)', providing clear semantics that the schema lacks, fully compensating for the coverage gap.
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 states the specific mathematical operation ('Raise a number to a power') with clear verb+resource, and it distinguishes this from sibling tools like 'multiply', 'square_root', or 'factorial' by specifying exponentiation rather than other arithmetic operations.
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 clearly indicates this tool is for exponentiation, which implies usage for mathematical calculations involving powers. However, it does not explicitly state when to use this versus alternatives like 'square_root' (for specific exponents) or other siblings, leaving some context for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the square root of a number.
Args:
number: The number to find the square root of
Returns:
The square root of the number
Raises:
ValueError: If number is negative
| Name | Required | Description | Default |
|---|---|---|---|
| number | 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 and does well by specifying the error condition ('Raises: ValueError: If number is negative'). This discloses important behavioral traits beyond the basic operation. However, it doesn't mention precision, handling of zero, or performance characteristics.
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 front-loaded with the core purpose, followed by organized sections for Args, Returns, and Raises. Every sentence earns its place, with no redundant information. The four-line format is highly efficient for this simple mathematical operation.
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 (single parameter, mathematical operation) and the presence of an output schema, the description is complete enough. It covers the purpose, parameter meaning, return value, and error conditions - everything needed for a basic square root calculation tool. The output schema handles return value details, so the description doesn't need to elaborate further.
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 clearly explains the single parameter ('number: The number to find the square root of'), adding meaningful context about what the parameter represents. The description fully documents the only parameter, though it doesn't specify number type constraints beyond the negative value error.
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 explicitly states 'Calculate the square root of a number' - a specific verb ('calculate') with a clear resource ('square root of a number'). It distinguishes from sibling tools like 'power', 'factorial', or 'multiply' by focusing specifically on square root calculation.
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. While the purpose is clear, there's no mention of when square root calculation is appropriate versus using 'power' with exponent 0.5, or how this relates to other mathematical operations in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subtract the second number from the first number.
Args:
a: The first number (minuend)
b: The second number (subtrahend)
Returns:
The difference of a and b (a - 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 the full burden. It describes the core behavior (subtraction) and return value, but doesn't disclose additional traits like error handling for non-numeric inputs, precision limits, or performance characteristics. It's adequate but lacks depth.
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, with a clear purpose statement followed by structured sections for args and returns. Every sentence earns its place without redundancy.
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), 2 parameters, and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, parameters, and returns, though it could benefit from more behavioral context.
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 description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'a' is the minuend and 'b' is the subtrahend, clarifying their roles in the subtraction operation, which the schema alone doesn't provide.
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 with a specific verb ('subtract') and resource ('numbers'), and it distinguishes from siblings by specifying the mathematical operation. It's not just restating the name but explaining what subtraction means in this context.
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 subtraction operations but doesn't explicitly state when to use this tool versus alternatives like 'add' or 'divide'. It provides basic context but lacks explicit guidance on when-not-to-use or named alternatives.
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.
v1.0.0add1 field changedInput schema / titleAdded value: +"addArguments"calculate_percentage1 field changedInput schema / titleAdded value: +"calculate_percentageArguments"divide1 field changedInput schema / titleAdded value: +"divideArguments"factorial1 field changedInput schema / titleAdded value: +"factorialArguments"multiply1 field changedInput schema / titleAdded value: +"multiplyArguments"power1 field changedInput schema / titleAdded value: +"powerArguments"square_root1 field changedInput schema / titleAdded value: +"square_rootArguments"subtract1 field changedInput schema / titleAdded value: +"subtractArguments"addcalculate_percentagedividefactorialmultiplypowersquare_rootsubtractEach tool has a clearly distinct mathematical operation with no overlap in purpose. The descriptions precisely define their specific functions (e.g., add vs. subtract vs. multiply), making misselection unlikely.
Most tools use clear verb-based names (add, subtract, multiply, divide, power, factorial) with one deviation (calculate_percentage uses a verb_noun pattern). All names are descriptive and follow a readable convention, though not perfectly uniform.
With 8 tools, this is well-scoped for a basic mathematical operations server. Each tool earns its place by covering fundamental arithmetic and common functions without being excessive or too sparse.
The set covers core arithmetic (add, subtract, multiply, divide) and key functions (power, square_root, factorial, percentage), but lacks operations like modulus, logarithms, or trigonometric functions that might be expected in a comprehensive math toolkit.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
16 AI-native tools with dual SSE + streamable-http transport. Free tier available.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
The agent-native cloud: database, functions, AI, storage, computers. 50 tools, one API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaoyuchenhot/MCP-example'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
