Try 26 utility REST APIs keylessly: NAICS classification, IP geo, email validation, currency.
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.
Average 3.6/5 across 7 of 7 tools scored. Lowest: 2.9/5.
Each tool targets a distinct functionality (fetching URLs, converting currency, validating email, geolocating IPs, listing APIs, matching NAICS codes, fetching URL metadata), with no overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., currency_convert, ip_lookup, naics_match, ensuring predictability.
Seven tools is well-scoped for an API catalog service providing trial endpoints for a variety of utilities—neither too sparse nor overloaded.
The set covers key read-only operations for each featured API, though missing write or list operations (e.g., listing supported currencies) are minor gaps that users can work around.
cors_fetchAInspectFetch any URL through the SSRF-hardened CORS proxy and return its response headers + status. Keyless trial of the CORS Proxy & Web Toolbox API.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch through the proxy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description states 'SSRF-hardened CORS proxy' and 'Keyless trial', it does not disclose important behavioral traits such as rate limits, authentication requirements for full access, or whether the full response body is returned.
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 consists of two concise sentences with no wasted words. It front-loads the core action and result.
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 adequately explains purpose and outcome. However, it could specify the return format (e.g., JSON structure) to be fully 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?
The single parameter 'url' is well-described in the schema, and the description adds no extra semantics beyond the schema. With 100% schema coverage, 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 clearly states the verb 'Fetch', the resource 'any URL', and the output 'response headers + status'. It differentiates from sibling tools like url_metadata by specifying raw response headers.
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 'Keyless trial', implying a trial version, but does not provide explicit guidance on when to use this tool versus alternatives like url_metadata or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
currency_convertAInspectConvert an amount between currencies using European Central Bank daily reference rates. Keyless trial of the Currency Exchange Rates API.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ISO currency code to convert to, e.g. EUR. | |
| from | Yes | ISO currency code to convert from, e.g. USD. | |
| amount | No | Amount to convert (default 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the schema by noting the data source (ECB daily rates) and the 'Keyless trial' limitation, implying potential rate constraints. However, it does not disclose error behavior, rate limits, or whether conversion is live vs. historical.
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 very concise, containing exactly two sentences that efficiently convey the core purpose and a key detail (data source and trial nature) without any 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?
Given the simplicity of the tool (3 simple parameters, no output schema), the description covers the essential points: conversion action, data source, and trial nature. It could mention the daily frequency or precision, but overall it is sufficiently 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 description coverage is 100% with clear descriptions for each parameter. The description does not add significant additional meaning for the parameters beyond what the schema already provides, meeting the baseline.
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's purpose: converting currency amounts using ECB reference rates. It is distinct from all sibling tools, which handle different tasks like fetching, email validation, IP lookup, etc.
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, nor does it mention prerequisites, limitations, or best practices. The phrase 'Keyless trial' hints at trial usage but does not explicitly guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
email_validateAInspectValidate an email address — syntax, MX records, disposable/role detection, and typo suggestions. Keyless trial of the Email Validator API.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It lists validation checks but lacks details on return format, rate limits, or whether authentication is required. The mention of 'trial' hints at limitations but is insufficient for full 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?
Two sentences, front-loaded with the verb and resource, no extraneous information. Every sentence adds value and is efficient.
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?
No output schema and no annotations; the description is adequate for a simple tool but could be more complete by mentioning return type or behavioral traits like asynchronous processing. Still, it covers the main 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 coverage is 100% but the schema description is minimal ('The email address to validate'). The tool description adds context on validation aspects but does not elaborate on the parameter format or constraints beyond what the schema provides.
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 it validates an email address and lists specific checks (syntax, MX records, disposable/role detection, typo suggestions). This clearly distinguishes it from sibling tools like currency_convert or ip_lookup which serve different purposes.
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 'Keyless trial' implying a trial context but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools are distinct in function, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ip_lookupCInspectGeolocate an IPv4/IPv6 address — country, city, coordinates, timezone. Keyless trial of the IP Geolocation API.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | The IP address to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must disclose all behavioral traits. It only states geolocation and trial status, but omits details like rate limits, authentication requirements, error handling, or that it is a read-only operation.
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?
Two sentences, front-loaded with the core purpose. No extraneous words. Efficient for a simple tool, though slightly more detail could be added without sacrificing conciseness.
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 one-parameter lookup tool with no output schema, the description covers the essential purpose and return values. However, it lacks information on potential failures, usage limits, or prerequisites, leaving some gaps for completeness.
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 already describes the 'ip' parameter with 100% coverage. The description adds that it supports IPv4/IPv6, which is a minor improvement. Baseline 3 is appropriate as the schema does most of the work.
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 verb 'Geolocate' and resource 'IP address', and lists return fields (country, city, etc.). However, it does not explicitly distinguish from siblings, which are quite different (currency_convert, email_validate), so it loses a point.
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 on when to use this tool versus alternatives. The description mentions 'Keyless trial', hinting at limited usage, but no explicit when-to-use or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_apisAInspectList the full Abundance APIs catalog — every API with its description, category, OpenAPI spec URL, RapidAPI listing URL, gateway host, and pricing. Call this first to discover what is available and how to get production access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states a read operation with no side effects and lists output contents. Lacks details on error handling or latency but adequate for a list tool.
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?
Two sentences with no redundancy. First sentence delivers purpose and content, second focuses on usage timing. Every word earns its place.
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?
No output schema, so description fully explains return fields (description, category, specs, pricing). Advises call order. No missing information for a zero-parameter listing 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?
No parameters; baseline score of 4 per guidelines. Description adds context for output but not needed for params. Schema coverage is 100% by absence.
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 uses specific verb 'List' and resource 'full Abundance APIs catalog' and details the data returned (description, category, URLs, pricing). It clearly distinguishes from sibling tools which are not about listing APIs.
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?
Explicitly advises 'Call this first to discover what is available and how to get production access,' indicating optimal timing. No explicit when-not or alternatives, but sibling tools are unrelated, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
naics_matchAInspectSemantically match a plain-English company description to 2022 NAICS industry codes. Returns ranked codes with a 0-100 match rating, hierarchy, and the official Census activities that matched. Keyless trial of the NAICS Code Finder API.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Company description, capabilities, or services (3-1000 chars). | |
| limit | No | Number of matches (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format (ranked codes, 0-100 rating, hierarchy, activities) and indicates it's a keyless trial. However, it does not specify behavioral traits such as rate limits, authentication needs, or whether the operation is read-only. The description is adequate but incomplete.
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 two sentences, front-loaded with the main purpose, and contains no superfluous information. Every sentence adds value: the first states the core functionality, the second adds trial context.
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 explains what the tool returns (ranked codes, rating, hierarchy, activities) and covers the input parameters clearly. Since output schema is absent, the description compensates well. Missing information about authentication or usage limits is minor given the 'Keyless trial' indication.
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 schema already documents both parameters. The description adds the context of 'Keyless trial' but does not provide additional semantics beyond what is in the schema. 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 clearly states the action (semantically match), the input (plain-English company description), the target (2022 NAICS industry codes), and the output (ranked codes with rating, hierarchy, activities). It is specific and distinguishes from sibling tools which perform different operations like fetching URLs, converting currency, etc.
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 matching company descriptions to NAICS codes, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. The mention 'Keyless trial' hints at possible usage limits but lacks clear instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url_metadataBInspectFetch a URL's Open Graph / Twitter card metadata (title, description, preview image) server-side. Keyless trial of the Web Toolbox API.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to inspect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It notes 'server-side' and 'keyless trial', but fails to disclose important behaviors like error handling, rate limits, or whether the operation is read-only. The potential for trial limitations or silent failures is not addressed.
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?
A single, well-structured sentence that immediately states the action and scope. No extraneous information; every word serves a 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?
With no output schema, the description enumerates the returned metadata fields (title, description, preview image) which is helpful. However, it omits typical return format, error scenarios, and limitations (e.g., only works on pages with OG tags). The tool is simple so this may be adequate, but gaps remain.
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 single parameter 'url' described as 'The page URL to inspect.' The tool description adds context that this URL will be used to fetch metadata, but does not add new constraints or format details beyond what the schema provides.
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 'Fetch' and the resource 'URL's Open Graph / Twitter card metadata', listing specific fields (title, description, preview image). It differentiates from siblings like cors_fetch or email_validate by specifying the unique functionality.
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 such as cors_fetch for raw fetching or naics_match for industry codes. The mention of 'Keyless trial' is a caveat but does not help an agent decide tool selection.
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.
No comments yet. Be the first to start the discussion!
