TapWaterMap
Server Details
Query US tap-water quality from the EPA's own SDWIS records: the water systems serving a city, contaminants and violations on record (with dates and whether the EPA classifies them as health-based), compare cities, and explain contaminants. Public, no-auth, read-only. ~19,000 cities across all 50 states + DC, ~1.5M EPA records. Every response reports what the EPA recorded, never a safety verdict.
- 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 4/5 across 10 of 10 tools scored.
Some overlap exists, e.g., between search and search_cities (both find cities by name) and between fetch and get_city_water (both retrieve city water records). Descriptions help distinguish them but may still confuse an agent.
Most tools follow a verb_noun pattern (e.g., get_city_water, find_cities), but fetch and search are single verbs, and coverage_stats is noun_noun, creating a mixed convention.
10 tools is well-suited for the domain, covering search, retrieval, comparison, and explanation without being excessive or too sparse.
The tool set covers the main read operations for tap water data, but lacks a contaminant search tool and direct violation lookup, which are minor gaps that can be worked around.
Available Tools
10 toolscompare_citiesARead-onlyIdempotentInspect
Compare the EPA records of several cities side by side. Pass cities as 'City, ST' strings.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | Yes | e.g. ['Burlington, VT', 'Houston, TX'] |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no additional behavioral details, such as what happens if a city is not found or whether partial results are returned. For a simple read-only tool, this is adequate but does not enhance beyond annotations.
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 long: one for purpose and one for parameter format. Every word is useful, no redundancy. Ideal 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?
Given the tool has one parameter, no output schema, and comprehensive annotations, the description is mostly complete. However, it does not specify what 'EPA records' includes (e.g., water, air, or all), leaving some ambiguity. The sibling tool names provide context, but a brief clarification would improve 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 only parameter 'cities' has 100% schema description coverage, including an example. The description repeats the format ('Pass cities as 'City, ST' strings'), adding no new meaning beyond the schema. 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's purpose: 'Compare the EPA records of several cities side by side.' It specifies the verb (compare), the resource (EPA records), and the scope (several cities). This distinguishes it from sibling tools like get_city_water (single city) or find_cities (search).
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 format guidance: 'Pass cities as 'City, ST' strings.' It implies the tool is for comparison of multiple cities, but does not explicitly state when to use this tool over alternatives (e.g., get_city_water for a single city). The context of sibling names helps, but direct exclusion criteria are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coverage_statsARead-onlyIdempotentInspect
What TapWaterMap covers: states, cities, total EPA violation records, and the data quarter/date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by detailing the output content (states, cities, records, date). No contradictions.
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, front-loaded with purpose, no wasted words. Highly concise and clear.
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 zero parameters and no output schema, the description fully covers what the tool returns. All relevant aspects of coverage are listed.
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 exist, so the baseline is 4. The description correctly implies no input needed, and no parameter info is required.
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 provides an overview of what TapWaterMap covers: states, cities, total EPA violation records, and data quarter/date. It uses a specific verb and resource, distinguishing it from sibling tools that focus on specific cities or data.
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 versus alternatives, but the description implies usage for obtaining overall coverage statistics before diving into specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_contaminantARead-onlyIdempotentInspect
Plain-English explanation of an EPA contaminant by name or code: the EPA name, whether the EPA classifies it as health-based, and how often it appears in our records. Not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| contaminant | Yes | Contaminant name or EPA code, e.g. 'TTHM' or '2950'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that the output is a 'plain-English explanation' and includes specific fields, plus a disclaimer about not being medical advice. This adds useful behavioral context beyond annotations.
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 purpose, lists outputs, and includes a simple disclaimer. Every word earns its place with no redundancy or unnecessary detail.
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 required parameter, no output schema, and strong annotations, the description fully covers what the tool does, what it returns, and its limitations. No 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% for the single parameter 'contaminant'. The description adds examples ('TTHM' or '2950') and clarifies it accepts name or EPA code, providing additional meaning beyond the schema's brief description.
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 verbs ('explain') and resources ('EPA contaminant'), lists output fields (EPA name, health classification, frequency), and includes a disclaimer distinguishing from medical advice. It clearly differentiates from sibling tools like search or get_city_water.
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 quick contaminant explanation but does not explicitly state when to use this tool versus alternatives (e.g., search). The disclaimer is helpful but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchARead-onlyIdempotentInspect
Fetch the full plain-English EPA tap-water record for a city id (e.g. 'vt/burlington') returned by search. (ChatGPT/Deep-Research compatible.)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | City id like 'vt/burlington' (state/slug). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context about output being full plain-English and ChatGPT/Deep-Research compatible, but no additional 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?
Two sentences, front-loaded purpose, no wasted words. Efficient and to the point.
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, description hints at 'full plain-English record', which is adequate for a fetch tool. Mentions compatibility with ChatGPT/Deep-Research, adding useful context for AI agents.
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 already covers the 'id' parameter with format and example. Description adds that the id originates from 'search', providing semantic 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?
Clearly states 'Fetch the full plain-English EPA tap-water record' with verb and resource. Distinguishes from sibling 'search' by noting the id comes from search, and uses example 'vt/burlington'.
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 ties usage to a preceding search call by stating id is 'returned by `search`'. Implies the tool is for after search, but lacks explicit when-not or alternative exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_citiesARead-onlyIdempotentInspect
Filter/rank cities across the dataset — e.g. cities in TX with open health-based violations, or cities with a specific contaminant. Returns ranked matches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | Optional 2-letter state code. | |
| contaminant | No | Optional EPA contaminant code or name (use explain_contaminant to find a code). | |
| minPopulation | No | ||
| healthBasedOnly | No | ||
| openViolationsOnly | No | Only cities with violations not returned to compliance. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it 'returns ranked matches', providing basic output behavior, but lacks details on ranking criteria, pagination, or result limits.
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 with two sentences. The first sentence defines the action and scope, and the second provides examples and output type, with no 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 6 parameters, no output schema, and no required parameters, the description is adequate but not comprehensive. It explains return format ('ranked matches') but omits details on ordering, default limit, or how ranking works, leaving gaps for an agent.
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 50%, and the description adds context by referencing filters like 'state' and 'contaminant' through examples. However, parameters like limit, minPopulation, and healthBasedOnly remain unexplained, requiring the agent to infer meaning from parameter names.
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 the tool filters/ranks cities across the dataset and provides clear examples, such as 'cities in TX with open health-based violations' or 'cities with a specific contaminant'. This distinguishes it from siblings like compare_cities or search_cities, 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?
No explicit guidance on when to use this tool versus alternatives. While examples imply usage for filtered searches, it does not compare with search_cities or list_state_cities, nor does it mention 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.
get_city_waterARead-onlyIdempotentInspect
The core tool: what the EPA has on record for a city's tap water — the active community water systems serving it, populations, sources, and violations (contaminant, health-based or not, dates, status, level vs limit when recorded). Plain-English, sourced, never a safety verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| state | Yes | 2-letter state code, e.g. 'VT'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail on the data returned (populations, sources, violations), sources (EPA), and cautions that it is not a safety verdict, providing rich behavioral context beyond annotations.
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 efficiently convey purpose and key details. The first sentence lists contents; the second adds qualifiers. Minor room for structural improvement, but highly 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?
With no output schema, the description must explain return values. It does so adequately by listing systems, populations, sources, and violations, and noting the output is plain-English and sourced. Lacks detail on data format or pagination, but sufficient for a data retrieval 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 50% (state has a description, city does not). The tool description adds no parameter-specific guidance, failing to compensate for the missing city description or clarify input format.
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 retrieves EPA water data for a city, listing specific fields and emphasizing it is 'never a safety verdict'. Distinguishes from siblings like compare_cities and get_water_system.
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 calls it 'The core tool', implying primary use, and warns about safety interpretation. However, it does not explicitly mention when not to use it or suggest alternatives like get_water_system or compare_cities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_water_systemARead-onlyIdempotentInspect
EPA record for a single water system by its PWSID (e.g. 'VT0005053'): name, population served, source, and violations.
| Name | Required | Description | Default |
|---|---|---|---|
| pwsid | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only, idempotent behavior. The description adds value by specifying the exact data returned (name, population, source, violations), which is beyond what annotations provide.
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 16 words, front-loading the purpose. Every word contributes, no wasted 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?
For a simple single-parameter read tool with comprehensive annotations and a clear description of returned fields, the description is sufficiently complete. No output schema exists, but the description compensates.
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 has no description for the 'pwsid' parameter, but the description provides an example value ('VT0005053') and clarifies it's the PWSID. This adds meaning where the schema is lacking.
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 retrieves a single water system record by PWSID and lists the returned fields (name, population, source, violations). It is specific and distinguishes from siblings that operate on multiple cities or comparisons.
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 versus alternatives like search or list tools. The context of retrieving a single system by ID is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_state_citiesARead-onlyIdempotentInspect
List all covered cities in a state (with violation counts).
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | 2-letter state code. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. However, it adds no additional behavioral context such as pagination or data freshness beyond what annotations provide.
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, front-loaded with the key action and resource. Every word adds value: verb, object, scope, and notable output details (violation counts).
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) and annotations that cover safety, the description is sufficiently complete. It informs the agent of the tool's purpose and a key output feature. Minor omission: no explanation of 'covered' or return format, but acceptable for a simple list.
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?
With 100% schema coverage, the description adds no meaning beyond the schema. The single parameter 'state' is documented as '2-letter state code' in both schema and description. 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?
Description clearly states the tool lists all covered cities in a state and includes violation counts. The verb 'list' and resource 'covered cities in a state' are specific, and the tool is distinct from siblings like 'find_cities' or 'search_cities' which imply different scopes.
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. The description does not mention when not to use it or provide context for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotentInspect
Search TapWaterMap for US cities by name. Returns matching cities with an id you can pass to fetch. (ChatGPT/Deep-Research compatible.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City name or partial name, e.g. 'Burlington'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful context about returning IDs for fetch, which aligns with and extends the annotation-provided safety profile.
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 with two sentences, front-loading the purpose and including a useful note about compatibility. No 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?
For a simple search tool with one parameter, the description adequately explains purpose, return value, and usage. It lacks details on limits or error handling but is sufficient for most use cases given the 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% with a clear description for the query parameter. The description adds no additional meaning 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 clearly states the tool searches TapWaterMap for US cities by name, returns matching cities with an id for fetch, and distinguishes from siblings like search_cities and find_cities.
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 for when to use the tool (searching US cities by name to get an id for fetch) but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_citiesARead-onlyIdempotentInspect
Find covered US cities by name, optionally within a state. Returns counts + the page URL for each.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| state | No | Optional 2-letter state code, e.g. 'TX'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns counts and page URLs, but does not disclose additional behaviors such as pagination behavior, result limits, or what happens on no matches. The transparency is adequate but not enriched beyond annotations.
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: two sentences that front-load the purpose and return format with no redundant or vague wording.
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?
Without an output schema, the description should elaborate on the return structure. It mentions counts and page URL, but does not specify if results include city names, states, or other fields. It also omits details on limit behavior and pagination. Given the tool's simplicity and annotations, it is moderately complete but has 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 33% (only 'state' has a description). The description clarifies that 'query' is a city name and 'state' is optional, but does not describe the 'limit' parameter. It adds moderate value beyond the schema but fails to cover all parameters.
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 (Find), resource (covered US cities), and optional state filter. It also specifies the return format (counts + page URL), making the tool's purpose highly specific and distinguishable from siblings like 'find_cities' or 'list_state_cities'.
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 indicates optional state filtering but provides no explicit guidance on when to use this tool over siblings like 'find_cities' or 'coverage_stats'. It lacks context on prerequisites, exclusions, or recommended scenarios.
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!