Unit Converter MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific physical quantities (e.g., length, mass, temperature) or operations (batch conversion, listing units). There is no ambiguity—an agent can easily select the correct tool based on the conversion type needed.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'convert_' or 'list_' prefixes, using snake_case throughout. This predictable naming scheme makes it easy for agents to understand and navigate the toolset without confusion.
Tool Count3/5
With 16 tools, the count is borderline high for a unit conversion server, as many tools could be consolidated into a single parameterized tool. While each tool serves a distinct conversion type, the proliferation of similar tools might feel heavy and could be streamlined for better usability.
Completeness5/5
The toolset provides comprehensive coverage for unit conversion, including all common physical quantities (length, mass, temperature, etc.), batch operations, and listing supported units. There are no obvious gaps—agents can perform any conversion task within the domain without dead ends.
Average 3.2/5 across 16 of 16 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
- Last stable release on July 27, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but reveals nothing about its behavior: no information about precision, error handling, rate limits, authentication needs, or what the output looks like. For a conversion tool, details like rounding behavior or supported value ranges would be valuable but are absent.
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, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a straightforward conversion tool and gets directly to the point. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple conversion tool with 100% schema coverage and an output schema exists (though not shown in the context), the description is minimally adequate. However, with no annotations and no behavioral details, it leaves gaps about how the tool actually behaves in practice. The existence of an output schema means the description doesn't need to explain return values, but other behavioral aspects remain uncovered.
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 schema description coverage is 100%, with clear descriptions for all three parameters and enum values for units. The description adds no additional parameter semantics beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter info in the description.
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: converting angles between units. It specifies the resource (angle) and the action (convert), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like convert_area or convert_temperature, which follow the same pattern for different measurement types.
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 name suggests it's for angle conversion specifically, there's no mention of sibling tools like convert_batch (which might handle multiple conversions) or list_supported_units (which could help identify available units). The agent must infer usage from the tool name alone.
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. The description only states the basic function ('Convert area between units') without any information about error handling, precision, rate limits, authentication needs, or what the output looks like. For a tool with no annotations, this is insufficient to inform the agent about how the tool behaves beyond its core purpose.
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 ('Convert area between units.')—just four words that directly state the tool's purpose. It's front-loaded with no wasted words, making it easy for an agent to parse quickly. Every sentence (in this case, the single sentence) earns its place by clearly defining the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (implied by 'Has output schema: true'), the description doesn't need to explain return values. However, with no annotations and a simple but functional purpose (area conversion), the description is minimal but adequate for basic understanding. It covers the 'what' but lacks depth on 'how' and 'when', making it just barely sufficient for a straightforward conversion tool.
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 100% description coverage, with clear descriptions for all three parameters (value, from_unit, to_unit) and enum values for units. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'Convert area between units.' This is a specific verb ('convert') with a clear resource ('area') and distinguishes it from other conversion tools (e.g., convert_length, convert_volume). However, it doesn't explicitly differentiate from the generic 'convert_batch' sibling, which might also handle area conversions, so it's not a perfect 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 when to prefer this over 'convert_batch' for area conversions, or how it relates to 'list_supported_units'. There's no context about prerequisites, limitations, or typical use cases, leaving the agent to infer usage from the tool name alone.
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 but offers minimal information. It doesn't mention whether this is a read-only operation, potential precision issues, error conditions, or performance characteristics. The description only states what the tool does, not how it behaves.
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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a straightforward conversion tool and gets directly to the point with zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, 100% schema coverage, and presence of an output schema, the description is minimally adequate. However, for a tool with no annotations, it should provide more behavioral context about what 'convert' entails operationally. The description meets basic requirements but leaves gaps in understanding the tool's complete behavior.
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 adds no parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions and enums. The baseline score of 3 reflects adequate schema documentation, but the description doesn't provide additional context about unit conversion specifics or edge cases.
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 'convert' and the resource 'computer storage between units', making the purpose immediately understandable. It distinguishes from sibling tools by specifying 'computer storage' rather than other conversion types like angle or temperature, though it doesn't explicitly contrast with them.
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 'convert_batch' or 'list_supported_units'. It lacks context about typical use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
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. It states the tool converts force between units but doesn't describe what happens during conversion (e.g., precision, rounding, error handling for invalid inputs), the output format, or any performance considerations. This leaves significant gaps in understanding how the tool behaves.
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—a single sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (unit conversion with multiple enum options) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about behavioral traits, usage guidelines, and error handling, which are important for a conversion tool. The high schema coverage helps but doesn't fully compensate for these gaps.
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 100%, so the schema fully documents all three parameters (value, from_unit, to_unit) with descriptions and enum values. The description adds no additional parameter semantics beyond what's in the schema, such as examples, constraints, or unit compatibility notes. This meets the baseline for high 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 the tool's purpose: converting force between units. It specifies the resource (force) and the action (convert between units), which distinguishes it from siblings that convert other physical quantities. However, it doesn't explicitly mention the specific unit options available, which are detailed in the schema.
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 sibling tools like convert_batch for batch conversions or list_supported_units for checking available units. There's no context about prerequisites, error handling, or typical use cases.
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. 'Convert length between units' implies a calculation operation but reveals nothing about precision, rounding behavior, error handling for invalid inputs, performance characteristics, or what the output contains. For a tool with 3 parameters and mathematical operations, this is a significant transparency 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 a single, efficient sentence that states the core functionality without unnecessary words. It's perfectly front-loaded with the essential information. Every word earns its place, making this an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (though not shown here), the description doesn't need to explain return values. However, for a conversion tool with mathematical operations and no annotations, the description should ideally mention something about precision, supported unit types, or common use cases. The current description is minimal but functional for the basic purpose.
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 100%, with all parameters clearly documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions and enum values. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 'Convert length between units' clearly states the verb ('convert') and resource ('length'), making the purpose immediately understandable. It distinguishes this tool from siblings like convert_temperature or convert_mass by specifying the measurement type. However, it doesn't mention the specific units available or the conversion scope, which could make it slightly less specific than a perfect 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 sibling tools like convert_batch for multiple conversions or list_supported_units for discovering available units. There's no context about prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from the tool name alone.
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 but only states the basic function without mentioning error handling, precision, rate limits, or output format. It doesn't add meaningful context beyond the minimal operation, leaving gaps in understanding how the tool behaves in practice.
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, direct sentence that front-loads the core purpose without any wasted words. It efficiently communicates the essential function in a minimal format, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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, 100% schema coverage, and presence of an output schema, the description is adequate but minimal. It covers the basic purpose but lacks context on usage guidelines and behavioral traits, which could be helpful for an agent despite the structured data being comprehensive.
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 100%, with clear descriptions and enums for parameters, so the description doesn't need to add parameter details. The description mentions 'weight' and 'units', which aligns with the schema but doesn't provide additional semantic value beyond what's already documented in the structured fields.
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 with a specific verb ('convert') and resource ('weight between units'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'convert_length' or 'convert_temperature' beyond mentioning 'weight' specifically, which is why it doesn't reach 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 'convert_batch' or 'list_supported_units'. It lacks context about prerequisites, limitations, or specific scenarios where this tool is preferred over other conversion tools, leaving the agent without usage direction.
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 full burden. 'Convert power between units' implies a read-only calculation, but it doesn't disclose whether this requires authentication, has rate limits, what precision to expect, or how errors are handled. For a tool with no annotation coverage, this is insufficient behavioral disclosure.
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, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a straightforward conversion tool and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (though not shown here), the description doesn't need to explain return values. However, for a conversion tool with no annotations, the description should ideally mention something about precision, error handling, or unit compatibility to provide more complete context for the agent.
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 100%, so the schema already fully documents all three parameters with clear descriptions and comprehensive enum values. The description adds no additional parameter information beyond what's in the schema, which meets the baseline expectation when schema coverage is complete.
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 as converting power between units, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like convert_energy or convert_force, which might handle related but different physical quantities.
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 when power conversion is needed versus other conversion tools, nor does it provide any context about prerequisites or limitations.
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. It states the basic function but doesn't describe important behavioral traits: whether the conversion is precise or approximate, what happens with invalid units, if there are rounding rules, rate limits, or authentication requirements. For a conversion tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 just 4 words. It's front-loaded with the essential information and contains zero wasted words. Every element earns its place by clearly stating the tool's core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple conversion function, 100% schema coverage, and the presence of an output schema (which means return values are documented elsewhere), the description is minimally adequate. However, for a tool with no annotations and multiple sibling conversion tools, it should provide more context about when to choose this specific pressure converter and what behavioral characteristics to expect.
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 'between units' which implies the need for source and target units, but doesn't add meaningful semantics beyond what the schema already provides. With 100% schema description coverage and clear enum values for both units, the schema does the heavy lifting. The description doesn't explain unit relationships, conversion accuracy, or special considerations for specific unit pairs.
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: converting pressure between units. It specifies the verb ('convert') and resource ('pressure'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'convert_temperature' or 'convert_length' beyond mentioning 'pressure' in the description.
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 sibling tools like 'convert_batch' for multiple conversions or 'list_supported_units' for discovering available units. There's no context about prerequisites, error conditions, or typical use cases.
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 offers minimal information. It doesn't mention precision, rounding behavior, error handling for invalid conversions, or whether the conversion uses standard definitions. The agent must infer behavior from the schema alone.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded with the essential information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple conversion function, 100% schema coverage, and presence of an output schema, the description is minimally adequate. However, for a tool with no annotations, it should ideally provide more behavioral context about conversion precision, supported unit relationships, or error conditions to help the agent use it correctly.
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 100%, so the schema fully documents all three parameters with clear descriptions and comprehensive enum values. The description adds no additional parameter semantics beyond what's already in the structured schema, meeting the baseline expectation when schema coverage is complete.
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 'Convert time between units' clearly states the verb ('convert') and resource ('time'), making the purpose immediately understandable. It distinguishes this tool from siblings like convert_angle or convert_length by specifying the time domain, though it doesn't explicitly contrast with convert_batch which might handle multiple conversions.
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 when to choose convert_time over convert_batch for batch operations, or how it relates to list_supported_units for discovering available units. Usage context is entirely implied rather than stated.
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. It states the tool performs a conversion but doesn't describe what happens on success (e.g., returns a numeric result), error conditions (e.g., invalid inputs), or performance aspects (e.g., precision, speed). For a tool with no annotations, this leaves significant gaps in understanding its 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 extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose and avoids unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 conversion with three parameters), 100% schema coverage, and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about sibling tools and behavioral details, which could help an agent use it more effectively in a broader toolset.
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 100%, with clear parameter descriptions and comprehensive enum lists for units. The description adds no additional parameter semantics beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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: converting volume between units. It specifies the verb 'convert' and the resource 'volume', making it understandable. However, it doesn't explicitly differentiate from sibling tools like convert_length or convert_mass, which follow the same pattern but for different measurement types.
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 sibling tools like convert_batch for batch conversions or list_supported_units for discovering available units. There's no context about prerequisites, such as needing valid unit names from the enum lists.
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. 'Convert density between units' implies a pure calculation/transformation, but doesn't specify whether this is a read-only operation, whether it has side effects, error conditions, or performance characteristics. The description is minimal and lacks 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 - a single sentence that directly states the tool's function. There's zero waste or redundancy. It's appropriately sized for a straightforward conversion tool with comprehensive schema documentation.
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 this is a simple conversion tool with 100% schema coverage and an output schema (implied by context signals), the description is reasonably complete. The combination of clear purpose, comprehensive parameter documentation in schema, and expected output schema reduces the burden on the description. However, it could benefit from minimal context about unit relationships.
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 100%, with all parameters clearly documented in the schema. The description doesn't add any parameter semantics beyond what's already in the structured fields - it doesn't explain unit relationships, conversion precision, or special cases. Baseline 3 is appropriate when schema does the heavy lifting.
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: converting density between units. It specifies both the resource (density) and the action (convert between units). However, it doesn't differentiate from sibling tools beyond the 'density' specification - all other convert_* tools have similar descriptions.
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. There's no mention of when density conversion is appropriate versus other conversion types, nor any prerequisites or constraints. The agent must infer usage from the tool name alone.
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. It only states the basic function without mentioning important behavioral aspects: whether it's read-only or has side effects, precision/rounding behavior, error handling for invalid units, rate limits, or authentication requirements. For a conversion tool with no annotation coverage, this is insufficient.
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 ('Convert energy between units') - a single sentence that efficiently communicates the core purpose without any wasted words. It's appropriately sized for this straightforward conversion tool and gets directly to the point.
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 that this is a simple conversion tool with complete input schema (100% coverage, clear enums) and an output schema exists (per context signals), the description is reasonably complete. The output schema will handle return value documentation, so the description doesn't need to explain return values. However, it could better address behavioral aspects given the lack of annotations.
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 100%, so the schema already fully documents all three parameters with clear descriptions and complete enum lists. The description adds no additional parameter semantics beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('Convert energy between units'), specifying both the verb ('convert') and resource ('energy'). It distinguishes from siblings by focusing on energy conversion rather than other measurement types like angle, area, etc. However, it doesn't explicitly differentiate from 'convert_batch' which might handle multiple conversions.
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 when to choose this over 'convert_batch' for single vs. multiple conversions, or when to use 'list_supported_units' first. There's no context about prerequisites, limitations, or comparison with 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. It states the tool performs a conversion but doesn't mention error handling (e.g., invalid units), precision, rounding behavior, or whether it's a pure function. For a tool with 3 parameters and no annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's function without any unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or redundancy are present.
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 straightforward nature (unit conversion), high schema coverage (100%), and the presence of an output schema (which handles return values), the description is reasonably complete. However, it lacks context about error cases or behavioral nuances that would be helpful for an AI agent, especially with no annotations provided.
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 schema description coverage is 100%, with clear descriptions for all parameters and comprehensive enum values for units. The description adds no additional parameter semantics beyond what's already in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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: converting speed between units. It specifies the verb ('convert') and resource ('speed'), making it immediately understandable. However, it doesn't differentiate from sibling tools like convert_length or convert_temperature, which follow the same pattern but for different measurement types.
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 sibling tools like convert_batch (for batch conversions) or list_supported_units (for discovering available units), nor does it specify any prerequisites or constraints for usage.
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 but provides minimal information. It doesn't mention whether this is a read-only operation, what happens with invalid inputs, whether there are precision limitations, or what the output format will be. While the existence of an output schema helps, the description itself offers almost no behavioral context beyond the basic conversion 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 - a single sentence that directly states the tool's purpose without any wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration. This is an excellent example of efficient communication for a straightforward tool.
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 that this is a simple conversion tool with complete schema coverage and an output schema, the minimal description is reasonably complete. The agent can understand what the tool does and has full parameter documentation. However, the lack of any behavioral context (error handling, precision, limitations) prevents a perfect score, especially since no annotations are provided to fill those gaps.
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 schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema - it doesn't explain unit conventions, precision considerations, or special cases. With complete schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
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 as converting temperature between units, which is a specific verb+resource combination. It distinguishes itself from sibling tools by focusing on temperature conversion rather than other measurement types like angle, area, or length. However, it doesn't explicitly differentiate from the generic 'convert_batch' tool which might also handle temperature conversions.
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 when to use 'convert_temperature' versus 'convert_batch' (which might handle batch conversions of multiple units), nor does it provide any context about prerequisites, limitations, or typical use cases. The agent receives no usage direction beyond the basic purpose statement.
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 full burden. It states the tool lists units but doesn't disclose behavioral traits like whether it's read-only (implied but not stated), response format, pagination, rate limits, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
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 (one optional parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the basic purpose and parameter intent. However, with no annotations, it could benefit from more behavioral context, but the output schema mitigates this gap.
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 100%, with the parameter 'unit_type' well-documented in the schema. The description adds minimal value beyond the schema, only implying that omitting the parameter returns all units. Since the schema already covers this thoroughly, the baseline score of 3 is appropriate.
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 with a specific verb ('List') and resource ('supported units'), and specifies scope ('for each conversion type or for a specific type'). However, it doesn't explicitly differentiate from sibling tools like the various 'convert_' tools, which perform actual conversions rather than listing units.
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 sibling tools, prerequisites, or specific scenarios where listing units is appropriate versus performing conversions. The only implied usage is when unit information is needed, but this is too vague.
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 key behaviors: it's a batch operation (multiple conversions at once), returns structured responses with success/failure status and error messages, and handles optional request_id for tracking. However, it doesn't mention potential limitations like rate limits, maximum batch size, or authentication needs.
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 front-loaded with the core purpose in the first sentence, followed by a bulleted list of request components and a clear statement about the return format. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.
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 moderate complexity (batch processing with multiple parameters), no annotations, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage, parameters, and behavioral outcomes, leaving no critical gaps for an AI agent to understand and invoke the tool correctly.
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 significant meaning beyond the input schema's 100% coverage. While the schema generically describes 'requests' as an array of objects, the description details each request's components (value, from_unit, to_unit, conversion_type, request_id), explains their purposes, and clarifies that request_id is optional. This compensates for the schema's lack of nested property 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 specific verb ('Perform multiple unit conversions') and resource ('in a single batch request'), distinguishing it from sibling tools that handle single conversions of specific types. It explicitly mentions batch processing, which sets it apart from individual conversion tools like convert_temperature or convert_length.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for 'multiple unit conversions in a single batch request.' It implicitly suggests alternatives (the sibling tools) for single conversions, though it doesn't name them directly. The context is clear and leaves no ambiguity about its batch-oriented purpose.
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:

[![unit-converter-mcp MCP server](https://glama.ai/mcp/servers/zazencodes/unit-converter-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zazencodes/unit-converter-mcp)

Score Badge

Copy to your README.md:

[![unit-converter-mcp MCP server](https://glama.ai/mcp/servers/zazencodes/unit-converter-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zazencodes/unit-converter-mcp)

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/zazencodes/unit-converter-mcp'

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