Example MCP Server

by Joseph19820124

Overview Schema Related Servers Score Discussions

Python

Local

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 purpose: add, subtract, multiply, and divide are basic arithmetic operations with no overlap, while magic_word is completely different, returning a random word. There is no ambiguity between tools.
Naming Consistency4/5
Four tools (add, divide, multiply, subtract) follow a consistent verb pattern for arithmetic operations, but magic_word deviates with a noun-based name. The naming is mostly consistent with one minor deviation.
Tool Count5/5
With 5 tools, this server is well-scoped for basic arithmetic and a simple word function. Each tool earns its place, and the count is appropriate for the apparent purpose.
Completeness4/5
For arithmetic, the surface is complete with add, subtract, multiply, and divide covering core operations. The magic_word tool adds a random function, but there is a minor gap in not including more advanced math operations like exponentiation or modulo.
Average 2.8/5 across 5 of 5 tools scored.
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

Behavior1/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 of behavioral disclosure. 'Divide two numbers' fails to mention critical behaviors: it doesn't warn about division by zero errors, specify integer division behavior (e.g., truncation), or describe the output format. For a mutation tool with zero annotation coverage, this is a significant gap.
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 with just three words, front-loading the core action without any waste. Every word ('Divide', 'two', 'numbers') earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple arithmetic), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling or output format, and with 0% schema coverage, it fails to provide adequate context for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. 'Divide two numbers' implies two parameters (dividend and divisor) but adds no meaning beyond the schema's property names 'a' and 'b'. It doesn't explain parameter roles, constraints (e.g., 'b' cannot be zero), or examples, leaving semantics unclear.
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 'Divide two numbers' clearly states the verb (divide) and resource (numbers), making the purpose immediately understandable. It distinguishes from siblings like 'add', 'multiply', and 'subtract' by specifying division. However, it doesn't specify that these are integers (though the schema does), keeping it at 4 rather than 5.
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. It doesn't mention mathematical contexts, error handling for division by zero, or comparisons to other arithmetic operations like 'multiply' or 'subtract'. Without any usage context, it's minimally helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. The description only states the basic operation ('subtract two numbers') without any information about side effects, error handling, performance, or output format. For a tool with no annotations, this is a significant gap in transparency, as it fails to describe how the tool behaves beyond its minimal function.
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 with a single sentence ('Subtract two numbers') that directly conveys the core function without any waste. It is front-loaded and appropriately sized for such a simple tool, making it easy for an agent to parse quickly. Every word earns its place by defining the essential operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, no output schema), the description is incomplete. It lacks information about the result (e.g., returns the difference), error cases (e.g., non-numeric inputs), or behavioral context. While the operation is basic, the description does not provide enough detail for an agent to fully understand the tool's behavior and output, especially with no annotations or output schema to supplement it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds no parameter semantics beyond what is implied by the tool name. It mentions 'two numbers' which aligns with the two parameters (a and b), but provides no details about their roles, constraints, or examples. With low schema coverage, the description does not compensate adequately, resulting in a baseline score due to the straightforward nature of the parameters.
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 the verb ('subtract') and resource ('two numbers'), making the purpose immediately understandable. It distinguishes from siblings like 'add', 'divide', and 'multiply' by specifying subtraction, though it doesn't explicitly contrast them. The description is specific but lacks explicit sibling differentiation beyond the inherent meaning of 'subtract'.
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' or 'divide'. It states what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions. This leaves the agent to infer usage based on the tool name alone, which is insufficient for optimal selection.
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 full burden for behavioral disclosure but only states the basic operation. It doesn't mention error handling (e.g., overflow, non-integer inputs), performance characteristics, side effects, or return format. For a mathematical tool with zero annotation coverage, this leaves significant behavioral gaps.
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 concise at three words, front-loading the core functionality with zero wasted language. Every word earns its place, making it immediately scannable and efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature and lack of annotations/output schema, the description is incomplete. It doesn't address return values, error conditions, or how this tool fits within the broader mathematical operation context provided by sibling tools. For even a simple tool, more contextual information would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'two numbers' which aligns with the two parameters (a and b) in the schema, but adds no semantic meaning beyond what's evident from parameter names. With 0% schema description coverage, the description doesn't compensate by explaining parameter roles, constraints, or examples. The baseline is appropriate given the simple nature.
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 the tool's purpose ('Add two numbers') with a specific verb ('Add') and resource ('two numbers'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'add' vs 'sum' or explain why this specific addition tool exists among mathematical operations, which prevents a perfect score.
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 'multiply', 'subtract', or 'divide' from the sibling list. There's no mention of use cases, prerequisites, or comparisons to other mathematical operations, leaving the agent with minimal context for tool selection.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Multiply two numbers' indicates a computational operation but doesn't describe traits like error handling (e.g., overflow), performance, or output format. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
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 with 'Multiply two numbers'—a single, front-loaded sentence that wastes no words. Every part earns its place by directly stating the tool's function, making it efficient and easy to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two integer parameters, no annotations, no output schema), the description is incomplete. It lacks information on output (e.g., returns the product as an integer), error cases, or usage context relative to siblings. For a basic computational tool, more detail would help the agent understand the full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description 'Multiply two numbers' implies two parameters (the numbers to multiply) but doesn't add meaning beyond what the schema's property names ('a' and 'b') suggest. It compensates minimally by indicating the operation, but doesn't detail parameter types or constraints, aligning with the baseline when schema coverage is low.
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 'Multiply two numbers' clearly states the verb (multiply) and resource (numbers), making the purpose immediately understandable. It distinguishes from siblings like 'add' or 'divide' by specifying the mathematical operation, though it doesn't explicitly contrast with them. The description is specific but lacks explicit sibling differentiation, which would require a 5.
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 'subtract'. It implies usage for multiplication scenarios but offers no explicit context, exclusions, or prerequisites. This leaves the agent to infer usage based on the tool name alone, which is minimal guidance.
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?
No annotations are provided, so the description carries the full burden. It states the tool returns a random word, implying a read-only operation, but doesn't disclose behavioral traits like whether the word list is fixed, how randomness is seeded, or if there are any rate limits or permissions needed. This leaves significant gaps in understanding the tool's behavior.
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 a single, clear sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence contributes directly to explaining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0 parameters, the description is minimal. It states what the tool does but lacks context about the word list source, randomness behavior, or expected output format, making it incomplete for effective use without additional assumptions.
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 input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 as it doesn't need to compensate for any schema gaps.
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 the action ('Return') and resource ('a random word from the list'), making the purpose understandable. However, it doesn't distinguish this tool from its mathematical siblings (add, divide, multiply, subtract), which suggests a different domain, so it lacks explicit sibling differentiation.
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 or in what context it's appropriate. Given the sibling tools are mathematical operations, there's an implied contrast, but no explicit usage instructions are 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:

[![joseph_mcp_server MCP server](https://glama.ai/mcp/servers/Joseph19820124/joseph_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/Joseph19820124/joseph_mcp_server)

Score Badge

Copy to your README.md:

[![joseph_mcp_server MCP server](https://glama.ai/mcp/servers/Joseph19820124/joseph_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/Joseph19820124/joseph_mcp_server)

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/Joseph19820124/joseph_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server