SpryTools API MCP Server
Server Details
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
- 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.7/5 across 9 of 9 tools scored.
Each tool targets a distinct function (domain availability, DNS records, currency conversion, text analysis, validation, etc.) with no overlapping purposes. Even domain-related tools serve different needs.
All tool names follow a consistent snake_case verb_noun pattern (e.g., check_domain, convert_currency, validate_email) with no deviations.
9 tools is a well-scoped number for a general utility server, covering a variety of common tasks without being overwhelming or too sparse.
The set covers core utilities like domain checks, text analysis, validation, time, and currency conversion. Minor gaps exist (e.g., no image or file handling), but the surface is reasonable for stated purpose.
Available Tools
9 toolscheck_domainAInspect
Check whether a domain name is available for registration (WHOIS + DNS).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the method (WHOIS + DNS) and that it checks availability, but lacks details on return format, rate limits, or prerequisites. With no annotations, the description provides moderate 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?
Single sentence that is concise and immediately conveys the tool's purpose without unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema), the description sufficiently covers the core functionality. Some agents might benefit from a hint about the output format, but it is not critical.
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 a clear description for the single 'domain' parameter. The tool description adds 'WHOIS + DNS' context but does not significantly enhance parameter semantics beyond 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?
Clearly states the action 'Check whether a domain name is available for registration' using specific methods 'WHOIS + DNS', distinguishing it from siblings like dns_lookup.
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?
Implies usage for checking registration availability but provides no explicit when-to-use, when-not-to-use, or references to alternatives like dns_lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_currencyAInspect
Convert an amount between currencies using current ECB exchange rates.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target currency code, e.g. USD | |
| from | Yes | Source currency code, e.g. EUR | |
| amount | Yes | Amount to convert |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses the use of ECB exchange rates, but does not mention potential side effects, auth requirements, rate limits, or behavior on invalid codes. The burden is on the description, which gives minimal behavioral insight.
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 wasted words. Directly conveys the core action and data source.
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?
The description covers the basic purpose but lacks details on output format, precision, error handling, or any constraints. Given no output schema and simple parameters, it is minimally acceptable but could be improved.
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?
All three parameters (from, to, amount) have descriptions in the input schema. The tool description adds no additional semantic meaning beyond the schema, so baseline score of 3 is appropriate.
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 'convert', the resource 'amount between currencies', and the data source 'current ECB exchange rates'. It distinguishes from sibling tools which are unrelated (domain, DNS, text, validation, time).
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 currency conversion but gives no explicit guidance on when to use this tool versus alternatives. Siblings are unrelated, so not a critical gap, but no when-not conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dns_lookupAInspect
Look up DNS records (A, AAAA, MX, TXT, NS, CNAME, SOA) for a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Record type | A |
| domain | Yes | Domain name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions basic functionality. It does not disclose side effects, network dependencies, or limitations.
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, efficient sentence listing all relevant information without wasted 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?
Sufficient for a simple two-parameter tool. The description covers the primary action and supported record types, though return format is not specified.
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% but the description adds a list of record types not in the schema, enhancing meaning beyond the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Look up' and the resource 'DNS records', listing specific record types. It implicitly distinguishes from unrelated sibling tools.
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 alternatives. Usage is implied by the tool's purpose, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geo_auditBInspect
Run a CiteReady GEO audit: how well can AI search engines (ChatGPT, Perplexity, Google AI Overviews) crawl, understand and cite a website. Returns score, grade and actionable findings.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL to audit | |
| pages | No | Pages to audit via sitemap (max 3 via MCP) |
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 of behavioral disclosure. It only states the tool runs an audit and returns results, but does not mention any side effects, permissions, rate limits, or whether it is read-only. This lack of detail leaves the agent unaware of potential impacts.
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 that front-loads the action and states the output. It is efficient but could be slightly improved with clearer structure or separate sentences for purpose and output.
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 two parameters, no output schema, and no annotations, the description covers the high-level purpose and output but lacks details on return format or constraints. It is adequate but leaves some gap for a complete understanding.
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 both parameters (url and pages) having descriptions. The tool description adds no further semantics beyond summarizing return values. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 runs a 'CiteReady GEO audit' to evaluate how well AI search engines crawl, understand, and cite a website, and specifies the return of score, grade, and findings. This is a specific verb+resource that distinguishes it from siblings like check_domain or validate_email.
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 auditing website citability by AI search engines but does not explicitly state when to use it versus alternatives or provide any when-not guidance. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hash_textAInspect
Compute a cryptographic hash (md5, sha1, sha256, sha512) of a text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to hash | |
| algorithm | No | md5 | sha1 | sha256 | sha512 | sha256 |
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 states 'cryptographic hash', implying a pure, deterministic computation with no side effects. This is sufficient for a simple utility, but it doesn't disclose potential performance considerations or idempotency explicitly.
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 of 14 words, containing no filler or redundancy. Every word is essential and directly conveys the tool's functionality.
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, stateless hashing tool with no output schema, the description covers the core functionality and algorithm choices. It could optionally mention the return format (hex string), but this is easily inferred. The description is complete enough for an AI agent to understand the tool's purpose.
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%: both parameters ('text' and 'algorithm') are clearly described in the input schema. The tool description adds no additional parameter-level context beyond what the schema provides. Baseline 3 is appropriate.
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 specifies the verb 'Compute', the resource 'cryptographic hash', and explicitly lists the supported algorithms (md5, sha1, sha256, sha512). It clearly distinguishes from sibling tools, which are unrelated utilities.
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 does not provide explicit when-to-use or when-not-to-use guidance. However, sibling tools are all in different domains (domain checking, currency conversion, etc.), so the purpose is self-explanatory. A slight improvement would be to mention this is for secure hashing, but it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
text_statsAInspect
Analyze text: word/sentence counts, reading time and Flesch readability scores.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only lists outputs but does not mention whether the tool is read-only, requires authentication, has rate limits, or any side effects. For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and lists key outputs concisely with no redundant 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?
For a simple tool with one parameter and no output schema, the description sufficiently conveys the analysis performed. However, it does not specify the return format (e.g., numbers, object) or any constraints on input length, leaving some 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?
The input schema covers the single parameter (text) with description 'Text to analyze'. The description adds value by explaining what analysis is performed (word/sentence counts, reading time, Flesch scores), providing context beyond 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 clearly states the verb 'Analyze text' and specifies the exact outputs: word/sentence counts, reading time, and Flesch readability scores. This distinguishes it from sibling tools which perform different tasks like domain checking or currency conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites, when-not-to-use, or context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_emailAInspect
Validate an email address: RFC syntax, MX records, disposable/role-based detection.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to validate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses all checks performed: syntax, MX, disposable/role-based. However, it does not mention return format or error handling, leaving some behavioral uncertainty.
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 wasted words. Information is front-loaded and every part is meaningful.
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 single parameter and no output schema, description covers core functionality well. Lacks return value details (e.g., boolean or object), but sufficient for most use cases.
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% with 'Email address to validate'. Description adds value by specifying validation scope (syntax, MX, etc.), enhancing understanding beyond 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 the verb 'validate' and resource 'email address', listing specific aspects: RFC syntax, MX records, disposable/role-based detection. It distinguishes from sibling tools like check_domain or dns_lookup.
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 when-to-use or when-not-to-use guidance. Implied that it's for comprehensive email validation, but no alternatives mentioned. Lacks clarity on when to use this vs sibling tools like check_domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_ibanBInspect
Validate an IBAN (ISO 13616 MOD-97) and return bank/country details.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN to validate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention whether the tool is read-only, whether external calls are made, what happens on invalid input (error vs. false), or any authentication/rate limits. Only the success output is hinted at.
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 with no unnecessary words. It conveys the essential purpose and output in a compact form, with no wasted text.
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?
The description lacks detail on return structure, error handling, and validation logic (e.g., does it call an external API?). Given the absence of an output schema, the description should provide more information about the returned bank/country details. However, for a simple one-parameter tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'iban' has a schema description ('IBAN to validate') that matches the tool's purpose. Since schema coverage is 100%, the description adds no extra semantics beyond what the schema already provides. This meets the baseline 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 validates an IBAN and returns bank/country details. The verb 'Validate' and resource 'IBAN' are specific, and the result is mentioned. It effectively distinguishes from sibling tools, which do not perform IBAN validation.
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 guidance is provided on when to use this tool versus alternatives. The description does not specify prerequisites, when not to use it, or how it compares to other validation tools like validate_email. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
world_timeAInspect
Get the current time and UTC offset for an IANA timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | IANA timezone, e.g. Europe/Berlin | UTC |
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 that the tool returns 'current time' and 'UTC offset', which is straightforward. However, it does not mention any potential network dependency, caching behavior, or accuracy guarantees. For a read-only time tool, this level is adequate but not exceptional.
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 concisely conveys the tool's purpose. It is front-loaded and contains no superfluous 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 (one optional parameter, no output schema), the description is complete. It explains what the tool does, what information it returns (current time and UTC offset), and the parameter format (IANA timezone). No further details are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the only parameter 'timezone'. The tool description adds no additional parameter meaning beyond what the schema provides, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current time and UTC offset for an IANA timezone. It uses a specific verb 'Get' and resource 'current time and UTC offset'. The sibling tools are all unrelated (check_domain, convert_currency, etc.), so it is well-distinguished.
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 when needing current time for a timezone, but it does not explicitly state when to use it versus alternatives, nor does it provide any exclusions or prerequisites. Since no sibling tool performs a similar function, the lack of explicit guidance is somewhat mitigated.
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!