MCP Multi-Tool Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-example MCP server](https://glama.ai/mcp/servers/xiaoyuchenhot/MCP-example/badges/card.svg)](https://glama.ai/mcp/servers/xiaoyuchenhot/MCP-example)

Score Badge

Copy to your README.md:

[![MCP-example MCP server](https://glama.ai/mcp/servers/xiaoyuchenhot/MCP-example/badges/score.svg)](https://glama.ai/mcp/servers/xiaoyuchenhot/MCP-example)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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