utility-converter
Server Details
7 utility tools in here: exchange rate, UUID, hash, Base64, timestamp, calculator, unit conversion.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: arithmetic, timestamp conversion, unit conversion, base64 encoding/decoding, UUID generation, exchange rate fetching, and hashing. There is no functional overlap.
Most tools follow a verb_noun pattern (e.g., convert_timestamp, get_exchange_rate), but 'calculate' is a bare verb and 'encode_decode_base64' combines two actions into one name, introducing slight inconsistency.
With 7 tools, the count is well-scoped for a general utility server. It is neither too sparse nor overcrowded.
The set covers several useful conversions (units, time, currencies, base64, hashing) but lacks other common utilities like string manipulation, JSON conversion, or data formatting, which would be expected given the server name.
Available Tools
7 toolscalculateAInspect
Revised July 13 at 11am Safely evaluate an arithmetic expression and return the exact result.
Supports +, -, *, /, //, %, ** (power), parentheses, the constants pi and e, and the functions sqrt(), abs(), round(). Does not execute arbitrary code.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | An arithmetic expression, e.g. "(3 + 4) * 2 ** 5" or "sqrt(2) * pi". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states safe evaluation and that arbitrary code is not executed. The revision date adds no behavioral insight. For a pure arithmetic calculator, this is sufficient; no side effects or destructive behavior apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences. The first sentence states purpose, followed by a list of supported operations and a security disclaimer. The revision note is slightly extraneous but does not detract significantly. Overall, every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no nested objects, output schema present), the description comprehensively covers purpose, supported operations, safety, and format examples. No additional behavioral or return details are necessary for an arithmetic evaluator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description provides example expressions (e.g., '(3 + 4) * 2 ** 5' and 'sqrt(2) * pi'), which add value beyond the schema's minimal description by illustrating expected format and use of constants/functions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Safely evaluate an arithmetic expression and return the exact result,' which clearly identifies the verb (evaluate) and resource (arithmetic expression). It distinguishes from sibling tools (e.g., convert_timestamp, convert_units) which handle different types of calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the important note 'Does not execute arbitrary code,' guiding agents not to misuse it for code execution. It lists supported operations and constants, providing context for appropriate use. However, it does not explicitly state when to use this tool over others, though the sibling list implies distinct domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_timestampBInspect
Convert between Unix timestamps and human-readable datetimes.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone name used for display/interpretation. Defaults to "Asia/Seoul". | Asia/Seoul |
| value | Yes | For "to_datetime", a Unix timestamp in seconds (e.g. "1752300000"). For "to_timestamp", an ISO 8601 datetime (e.g. "2026-07-12 15:30:00"). The special value "now" returns the current time in both formats. | |
| direction | No | "to_datetime" or "to_timestamp". Defaults to "to_datetime". | to_datetime |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It merely states conversion behavior without disclosing side effects, required permissions, rate limits, or return format details. For a data manipulation tool, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core purpose. It wastes no words, though it could benefit from slightly more structured detail about direction and special values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full parameter documentation, the description is minimally adequate. However, it lacks mention of default timezone, direction handling, and the 'now' special value, which are important for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already thoroughly documents each parameter. The description adds no additional meaning beyond what is in the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts between Unix timestamps and human-readable datetimes, which is a specific verb-resource pair. It distinguishes from sibling tools like 'convert_units' or 'hash_text' which handle different conversion types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for timestamp-datetime conversion but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Context from sibling tools suggests distinct purposes, but no direct comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_unitsAInspect
Convert a value between units of length, weight, or temperature.
Supported units:
Length: mm, cm, m, km, inch, ft, yard, mile
Weight: mg, g, kg, ton, oz, lb
Temperature: C, F, K (Celsius, Fahrenheit, Kelvin)
Both units must belong to the same category (e.g. km -> mile is valid, kg -> mile is not).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The numeric value to convert. | |
| to_unit | Yes | The target unit (e.g. "mile"). | |
| from_unit | Yes | The source unit (e.g. "km"). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral traits: supported unit categories and the requirement that units belong to the same category. Could further detail error handling or precision, but adequately covers main constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured, with a clear purpose statement followed by listed units and a critical constraint note. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description is complete: it covers input constraints, supported units, and category rules. No missing information for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic parameter descriptions. The tool description adds value by listing the allowed unit values and the category constraint, which is not captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it converts values between units of length, weight, or temperature, listing supported units and categories. It is distinct from sibling tools that perform different operations like calculating, converting timestamps, or encoding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraint that both units must belong to the same category, with an example of valid and invalid conversion. Lacks explicit guidance on when to use this tool over siblings, but the sibling tools are clearly different in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
encode_decode_base64AInspect
Encode text to Base64 or decode a Base64 string back to text.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Either "encode" or "decode". Defaults to "encode". | encode |
| text | Yes | The text to encode, or the Base64 string to decode. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states basic functionality. It lacks details on encoding assumptions, error handling, or performance characteristics, leaving the agent uninformed about important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, meeting conciseness and front-loading standards.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with comprehensive schema and output schema, the description is mostly adequate. However, it lacks behavioral details like character encoding or error handling, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no new semantics beyond restating the mode and text roles, providing marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool encodes text to Base64 or decodes a Base64 string to text, providing a clear verb-resource pair. It is distinct from siblings like hash_text or convert_units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for Base64 encoding/decoding but does not explicitly state when to use it over siblings or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_uuidAInspect
Generate one or more random UUID v4 strings.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of UUIDs to generate (1-100). Defaults to 1. | |
| uppercase | No | If true, return UUIDs in uppercase. Defaults to false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose randomness source, entropy, or any behavioral traits beyond generating strings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with output schema; could mention output format but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (count range 1-100, uppercase bool); description adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses clear verb 'generate' and resource 'UUID v4 strings', differentiating from sibling tools like calculate, convert, hash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings; context aligns with the tool's unique functionality, but no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_exchange_rateAInspect
Get the latest exchange rate between two currencies and convert an amount.
Uses the free Frankfurter API (no API key required). Currency codes must be ISO 4217 codes such as USD, KRW, EUR, JPY, GBP.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Amount in the base currency to convert. Defaults to 1.0. | |
| to_currency | Yes | Target currency code (e.g. "KRW"). | |
| from_currency | Yes | Base currency code (e.g. "USD"). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 discloses the underlying API and currency code requirements, but does not address potential issues like API rate limits, error handling, or behavior with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately state the purpose and add key context about the API and code format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It covers the API source, currency code format, and conversion amount. Could mention that only latest rates are provided, but overall sufficient for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context about ISO 4217 codes and the conversion action, but largely duplicates what the schema already provides, offering limited additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and specifies the resource 'latest exchange rate between two currencies' and the action 'convert an amount'. This distinguishes it from sibling tools like 'convert_units' (different conversion type) and 'calculate' (general computation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the free Frankfurter API and ISO 4217 currency codes, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives like 'convert_units' for unit conversions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hash_textAInspect
Compute the cryptographic hash of a UTF-8 text string.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The input text to hash. | |
| algorithm | No | One of "md5", "sha1", "sha256", "sha512". Defaults to "sha256". | sha256 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions 'cryptographic hash' implying one-way and deterministic, but does not specify output format (e.g., hex) or that different algorithms produce different length hashes. Basic transparency but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It directly communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and full parameter descriptions, the description covers core functionality. It could mention irreversibility or algorithm selection, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds only 'UTF-8 text string' context, which is minor. Baseline 3 is appropriate since schema already explains parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a cryptographic hash of a UTF-8 text string. This verb-resource pair is unambiguous and differentiates it from all sibling tools, none of which perform hashing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a cryptographic hash is needed, but does not provide explicit context such as when not to use (e.g., for encryption) or alternatives. However, no sibling tool directly competes, so guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!