Real-world data for agents: air quality, geocoding, quakes, holidays, web search
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 4/5 across 9 of 9 tools scored.
Each tool has a clear, distinct purpose (air quality, country indicators, earthquakes, elevation, geocode, holidays, URL reading, web search, catalogue). The only overlap is that geocode already returns elevation, making the separate elevation tool redundant and potentially confusing.
All tool names follow a consistent lowercase snake_case pattern, mixing noun-based names (earthquakes, elevation) and verb_noun names (read_url, web_search). The style is uniform across the set, so naming is predictable and readable.
Nine tools is a reasonable count for a general-purpose data/web utility server. However, the set feels like a random assortment of free APIs rather than a coherent scoped collection, which slightly undermines the sense of appropriateness.
The server name 'tokenguard' implies a focus on token safety and blockchain intelligence, but the free tools cover unrelated domains (air quality, geocoding, holidays, web). The actual token-safety features are only mentioned in the paid_catalogue and are not exposed as MCP tools, leaving a significant gap between the server's apparent purpose and its actual capabilities.
air_qualityAInspectCurrent air quality for a place: PM2.5, PM10, ozone, NO2, SO2, CO and dust, plus the US and European AQI and the US AQI band ('Good', 'Unhealthy'). Takes a place name — no coordinates needed. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Place name, e.g. 'Tokyo' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states this is a read-only data lookup and lists the output contents, but it does not mention potential errors, data staleness, units, or response format. The mention of free and paid API is extra context but not essential for using the 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?
The core instruction is a single information-dense sentence that lists outputs and input requirements. The parenthetical about the paid API is somewhat off-topic for tool usage, adding a minor distraction, but the description remains reasonably concise and well-structured.
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 one-parameter, read-only lookup with no output schema, the description adequately covers what the tool returns and how to specify the input. It does not describe the output structure, but the tool is simple enough that this is not a critical gap.
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% and the schema already explains that 'location' is a place name with an example. The description reinforces this with 'place name — no coordinates needed' but adds little 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 identifies the tool as returning current air quality for a place, and enumerates the specific pollutants and AQI metrics included. It distinguishes itself from sibling tools by focusing on air quality and explicitly noting that it takes a place name rather than coordinates.
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?
It explicitly says 'Takes a place name — no coordinates needed', which guides the agent to use a simple location string and avoid unnecessary geocoding. It does not explicitly compare with sibling tools, so it falls slightly short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_indicatorAInspectWorld Bank time series for a country: gdp, gdp_per_capita, population, inflation, unemployment, life_expectancy, co2_per_capita or internet_users. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | 1-60 most recent years (default 5) | |
| country | Yes | ISO 2- or 3-letter country code | |
| indicator | No | Alias above, or a World Bank code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds context about being free and mentioning the paid API, which is useful. However, it does not disclose output format, rate limits, or behavior on invalid inputs, so transparency is 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 concise, front-loaded with the core purpose in the first sentence. The second sentence about the paid API is relevant and adds context without being verbose. Every sentence 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?
Given the tool's simplicity (3 params, no output schema), the description covers the essential information: what data is available and how to get it. It doesn't explain return structure, but that is not critical here. The paid API mention adds extra context, making it fairly 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%, but the description adds value by listing the valid indicator aliases (gdp, population, etc.) that the schema only refers to as 'Alias above'. This goes beyond the schema's basic descriptions, aiding parameter interpretation.
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 that the tool provides World Bank time series data for a country and lists specific indicators (gdp, gdp_per_capita, etc.). This clearly distinguishes it from sibling tools like air_quality or earthquakes, making the purpose specific and unambiguous.
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 retrieving country-level economic indicators. It also mentions the paid API and directs users to 'paid_catalogue' for paid routes, offering context for alternative/premium options. However, it does not explicitly state when to use this tool over sibling tools, so a slight gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
earthquakesAInspectRecent earthquakes from the USGS feed — worldwide, or within a radius of a named place. Returns magnitude, depth, tsunami flag and felt reports. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 1-30 days back (default 1) | |
| limit | No | 1-100 events (default 20) | |
| location | No | Centre on a place name | |
| radius_km | No | Radius around location (default 500) | |
| min_magnitude | No | Lower bound (default 4.5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool is free, returns specific fields (magnitude, depth, tsunami flag, felt reports), and supports location-based filtering. It does not mention rate limits or pagination, but covers core 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 two sentences, front-loaded with the main purpose, and includes a parenthetical about the paid API that is relevant but not excessive. Every sentence earns its place, and there is 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 explains the data source, scope, and return fields (compensating for the lack of an output schema). It does not explicitly describe output format or defaults, but the schema covers defaults, and the tool is a relatively simple read operation. The provided details are adequate for an agent to invoke it correctly.
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 provides 100% coverage with descriptions for all 5 parameters, so the schema does the heavy lifting. The description adds context that 'location' is a named place and that radius applies around it, but does not significantly enhance parameter meaning 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 identifies the tool as providing recent earthquakes from the USGS feed, with a scope of worldwide or radius around a named place. This distinguishes it from sibling tools like elevation or air_quality, which handle different data domains.
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?
It states the primary use case (retrieving recent earthquake data) and differentiates the free tool from a paid API by pointing to paid_catalogue for routes and prices. It does not explicitly list exclusions or when to use alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
elevationAInspectGround elevation in metres for a place name. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Place name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the output unit but does not disclose behavior for invalid or missing locations, accuracy, or response structure. The mention of the paid API adds cost context but not operational behavior.
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, with a clear main clause and a parenthetical note. The parenthetical about the paid API is slightly tangential but does not bloat the overall length.
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 simple single-parameter tool and no output schema, the description covers the core purpose and unit. It lacks explicit return format information, but the simplicity and sibling context keep this from being a major gap.
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 schema already fully describes 'location' as a place name, and the description merely echoes that. No additional meaning is added beyond what the schema provides, so 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 states a specific resource (ground elevation) and output unit (metres) for a place name, clearly distinguishing it from sibling tools like geocode or air_quality. The verb is implicit but the purpose is unmistakable.
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 clearly implies the use case: when you need elevation for a place name. It does not explicitly name alternatives, but the context is specific enough that an agent can determine when to select it. The note about free/paid API provides extra context but not exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geocodeAInspectResolve a place name to coordinates, country, admin region, timezone, elevation and population. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Place name to resolve | |
| count | No | 1-20 candidates (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is 'Free' and mentions a paid API, but does not reveal rate limits, response structure, behavior for invalid place names, or the fact that it can return multiple candidates via the count parameter. This is minimal transparency for a geocoding service.
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, with the main purpose in the first sentence and a relevant note about the paid API in the second. Every sentence contributes value, and it is appropriately concise.
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 core purpose and output fields are covered, which is helpful given no output schema. However, the description omits the multi-candidate behavior (count parameter) and any error-handling or rate-limit information, which would be expected for a geocoding tool with no annotations.
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% for both parameters, so the baseline is 3. The description adds context by listing outputs, which indirectly clarifies what 'name' should accept, but it does not elaborate on the count parameter beyond the schema's description. No additional semantics are needed 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 specific verb 'Resolve' and the resource 'place name', and enumerates the outputs (coordinates, country, admin region, timezone, elevation, population). This distinguishes it from sibling tools like elevation or web_search, which have 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 implies use for converting place names to geographic data but does not explicitly state when to prefer this tool over alternatives. It does mention calling paid_catalogue for the paid API, giving a hint about cost-based alternatives, but no direct comparison with other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
paid_catalogueAInspectList the paid API routes this same server offers, with prices and which ones need no input. The MCP tools here are free and general-purpose; the paid routes are specialised (on-chain token safety, live DEX prices, wallet intel, supply-chain scans). Payment is x402 over USDC on Base — no account or API key. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool lists routes, takes no arguments, and that the MCP tools are free, implying this call is free and read-only. It also discloses payment details for the paid routes themselves. It does not mention output format or potential error behavior, but for a simple listing tool this is not a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. Every sentence adds distinct value: what it lists, how it differs from free tools, and payment details. There is no fluff or redundancy, making it highly 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?
For a zero-parameter listing tool with no output schema, the description is complete. It specifies the content (paid routes, prices, input needs), the context (free vs paid, specialized use cases), and the operational details (payment method, no account). An agent can decide to invoke it without further clarification.
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 tool has zero parameters and the schema is an empty object. The description explicitly confirms 'Takes no arguments,' which matches the schema. Per the baseline for 0-parameter tools, a score of 4 is appropriate; there is nothing more to add since no parameters exist.
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 opens with a specific verb-resource pair: 'List the paid API routes this same server offers, with prices and which ones need no input.' This clearly distinguishes the tool from sibling data-lookup tools and indicates exactly what the tool does. The scope ('this same server') and the included details (prices, input requirements) add further precision.
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 clear context by contrasting the free MCP tools with specialized paid routes, and explains the payment method (x402 over USDC on Base) and that no account/API key is needed. It implies when to use this tool (when someone needs specialized on-chain, DEX, wallet, or supply-chain data) rather than the free general-purpose tools. It does not name specific alternative tools, but the distinction is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
public_holidaysAInspectPublic holidays for a country and year, with local names and a past/upcoming flag. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year (defaults to current) | |
| country | Yes | ISO 2-letter country code, e.g. JP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the output contents (local names, past/upcoming flag) and notes that the service is free, which is useful. It does not mention error handling or rate limits, but for a simple read-only lookup these may not be critical.
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 short sentences. The first states the core purpose, and the second provides a straightforward note about free vs paid API. No unnecessary words or repetition.
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 two self-explanatory parameters and no output schema, the description covers the essential behavior and return values. Adding a note about the free tier and paid catalogue is extra context that helps decision-making. It is nearly complete, though it could mention response format or data source specifics for a perfect score.
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 provides clear descriptions for both parameters: country is an ISO 2-letter code and year defaults to the current year. The description adds little beyond restating 'for a country and year', so it does not significantly improve on the schema's 100% coverage.
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 what the tool returns: public holidays for a country and year, including local names and a past/upcoming flag. This is specific and distinct from sibling tools like air_quality or geocode.
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 when to use this tool (when you need public holidays) and mentions a paid alternative (paid_catalogue), but it does not explicitly compare to other data tools or state when not to use it. The free/paid note gives some context but not full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_urlAInspectFetch a URL and return its main content as clean Markdown, boilerplate stripped. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and sufficiently discloses that it returns clean Markdown stripped of boilerplate, and that the service is free. It does not mention potential limitations (e.g., dynamic content, paywalls, timeouts) or response error formats, which leaves some gaps, but the core output behavior is clearly stated.
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, with the primary purpose front-loaded in the first sentence. The second sentence about the paid API is somewhat tangential to the tool's core function but is short and provides relevant context about the service's broader ecosystem, so it does not significantly detract from 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 tool with one parameter and no output schema, the description fully explains what the tool does, what it returns (clean Markdown), and the cost model. The absence of an output schema is compensated by explicitly stating the return format, making the description adequate for an agent to invoke the tool correctly.
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 documents the only parameter ('url' as 'Page to fetch'), so schema coverage is 100%. The description does not add additional meaning about URL formats, accepted protocols, or constraints, providing no extra value 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 uses a specific verb ('Fetch') and names the resource ('a URL') and the exact outcome ('return its main content as clean Markdown, boilerplate stripped'). This clearly distinguishes it from the sibling web_search tool, which searches rather than fetches a specific URL.
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 fetching a specific URL, which contrasts with web_search but does not explicitly state when to choose one over the other. There is no when-not-to-use guidance or mention of alternatives beyond the paid API aside, which is more about monetization than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchAInspectSearch the live web and return ranked title/url/snippet results, through an automatic multi-engine failover chain. (Free. This server also sells a paid API — call paid_catalogue for the routes and prices; x402 over USDC on Base, no signup.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | 1-25 (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the automatic multi-engine failover chain and notes that the tool is free, with a paid API alternative, adding context beyond the bare schema. However, with no annotations provided, it fails to mention rate limits, authentication needs, or error behavior, leaving significant transparency gaps.
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 first sentence is concise and front-loaded, clearly stating the tool's function. The second sentence is a promotional note about the paid API and directs to 'paid_catalogue'; while tangential, it adds useful cross-information, so it does not feel wasteful.
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 two-parameter tool with no output schema, the description explains the result format (title/url/snippet) and ordering (ranked), which is sufficient. It omits potential failure modes or pagination details, but these are not critical for basic invocation, making it fairly 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 input schema already describes both parameters with 100% coverage, so the description adds no parameter-specific detail. Per the rubric, the baseline 3 is appropriate when schema covers all parameters and the description doesn't compensate further.
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 a specific verb 'Search' and identifies the resource as 'the live web', with a clear output of 'ranked title/url/snippet results'. This differentiates it from the sibling data-lookup tools like 'air_quality' and 'geocode', 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 implies usage for general live-web searches but does not explicitly state when to use this tool versus alternatives or mention any exclusions. The mention of the paid API is a cross-reference rather than usage guidance, so the guidance remains only implied.
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!
Sign in to create a connector for this server.