Read-only bilingual Wash Bodega services, pricing, hours, pickup policy, and ordering handoff.
Return the verified store location and scoped 24/7 customer-access hours without implying continuous staffing or service availability.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en-US |
| Name | Required | Description |
|---|---|---|
| locale | Yes | |
| location | Yes | |
| sourceUrl | Yes | |
| publishedAt | Yes | |
| storeAccess | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: the returned hours are 'scoped 24/7 customer-access hours' and must not be interpreted as continuous staffing or service availability. This prevents a meaningful misinterpretation. There is no contradiction with the 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 front-loaded sentence that states the action, the resource, and the important semantic caveat. There is no filler, repetition, or unnecessary detail. Every phrase contributes to correct tool use.
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 read-only tool with an output schema, strong safety annotations, and one optional enum parameter, the description is nearly complete. It communicates the key non-obvious nuance about staffing while the output schema covers return details. It could mention locale handling, but the schema already provides that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the `locale` parameter at all. The parameter's enum and default in the schema partially self-document it, but the description adds no meaning about how locale affects the response or when a caller should specify it. Given low coverage, the description fails to compensate.
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, 'Return', and identifies a precise resource: 'verified store location and scoped 24/7 customer-access hours.' It also adds a clarifying caveat about not implying continuous staffing, which sharpens the purpose. This clearly distinguishes the tool from sibling tools about ordering, policies, pricing, and services.
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 should be used when someone asks for the store location or customer-access hours, and the sibling list suggests alternatives for other topics. However, it never explicitly states when to use this tool versus alternatives or what questions should be routed elsewhere. Usage guidance is inferred, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Cents ordering link and its limits. This read-only tool does not open the link, submit data, confirm a route, create an order, or take payment.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en-US | |
| service | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| locale | Yes | |
| notice | Yes | |
| status | Yes | |
| handoff | Yes | |
| service | Yes | |
| sourceUrl | Yes | |
| publishedAt | Yes |
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 value by enumerating specific non-actions, such as not opening the link or creating an order, which clarifies that calling this tool has no side effects beyond returning data.
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 and followed by behavioral exclusions. The word 'read-only' slightly duplicates the annotation, but the rest of the second 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?
Annotations and the output schema cover safety and return shape, and the description is clear about the tool's non-actions. However, the description never explains what 'limits' means or how the parameters influence the result, leaving a real gap for an agent deciding how to invoke it.
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 0%, and the description says nothing about the 'service' or 'locale' parameters. An agent cannot tell how service choices like 'wash-fold' vs 'pickup-delivery' affect the returned link or its limits, or how locale changes the response.
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?
States a specific verb 'Return' and a clear resource: 'the Cents ordering link and its limits.' This distinguishes it from sibling tools that cover hours, pricing, services, and pickup/delivery policy.
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?
Gives clear when-not-to-use guidance: it 'does not open the link, submit data, confirm a route, create an order, or take payment.' It does not explicitly name which sibling to use as an alternative, so it misses the top score, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the public route-qualification policy without accepting an address, ZIP code, location, or other personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en-US |
| Name | Required | Description |
|---|---|---|
| locale | Yes | |
| status | Yes | |
| service | Yes | |
| sourceUrl | Yes | |
| explanation | Yes | |
| publishedAt | Yes | |
| acceptsAddress | Yes | |
| serviceAreaStatus | Yes | |
| publishedPostalCodes | Yes | |
| routeConfirmationAvailable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the privacy-relevant fact that no personal data is accepted, but it does not disclose additional behavioral details such as auth needs or rate 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 a single, front-loaded sentence with no filler. It states the action, the resource, and the key input constraint efficiently.
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?
This is a simple, low-risk read-only tool with an optional locale parameter and an output schema. The description covers purpose, scope, and privacy constraints; annotations cover safety; and the output schema covers return shape. Nothing important is missing.
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, locale, is fully defined by its enum and default in the schema, so an agent can invoke it correctly. However, the description does not mention locale at all, and schema description coverage is 0%. The negative constraint about personal data adds some context but does not compensate fully for the missing locale explanation.
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 does: 'Return the public route-qualification policy'. It names a specific resource and distinguishes itself from sibling tools by explicitly excluding address, ZIP, location, or other personal 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?
The description gives clear context: this is for the public policy, not for personalized route qualification involving personal data. It does not name an alternative sibling tool explicitly, which prevents a 5, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return verified public pricing and minimums for Wash & Fold or pickup/delivery. Read only; specialty and commercial quotes are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en-US | |
| service | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| unit | Yes | |
| rates | Yes | |
| locale | Yes | |
| status | Yes | |
| service | Yes | |
| currency | Yes | |
| minimumLb | Yes | |
| pickupFee | Yes | |
| sourceUrl | Yes | |
| verifiedAt | Yes | |
| deliveryFee | Yes | |
| publishedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'Read only' adds no new information. It does add useful scope context beyond annotations: the pricing is 'verified public' and excludes 'specialty and commercial quotes'. No contradiction exists between description and 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, front-loaded sentence that states the action and scope efficiently. The phrase 'Read only' is redundant with the annotations, but it is short and does not meaningfully bloat the description.
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 tool has a small parameter set, self-documenting enums, an output schema, and annotations covering safety. The description covers purpose, service scope, and exclusions well. It does not mention the locale parameter or specific sibling alternatives, but those are minor given the structured metadata present.
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 description maps the required 'service' parameter to 'Wash & Fold' and 'pickup/delivery', matching the enum values. However, with 0% schema description coverage, it does not add explicit parameter-level guidance for the optional 'locale' parameter. The locale enum and default are self-explanatory in the schema, but the description only partially compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clear resource ('verified public pricing and minimums') scoped to 'Wash & Fold or pickup/delivery'. It also distinguishes itself by explicitly excluding specialty and commercial quotes, making it easy to tell apart from sibling tools about hours, policy, ordering, and services.
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 when to use the tool: when public Wash & Fold or pickup/delivery pricing is needed. It also gives an explicit when-not boundary by stating that specialty and commercial quotes are excluded. However, it does not name a specific sibling alternative for those excluded quote types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return verified public Wash & Fold and pickup/delivery availability in English or Spanish. Read only; never collects personal data or creates an order.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en-US |
| Name | Required | Description |
|---|---|---|
| locale | Yes | |
| services | Yes | |
| sourceUrl | Yes | |
| boundaries | Yes | |
| publishedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is pre-covered. The description adds useful behavior beyond that: the data is 'verified public', and the tool 'never collects personal data or creates an order', giving extra clarity on privacy and side-effect expectations. No contradiction with the 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 short sentences with no filler. The primary action and resource are front-loaded, and the read-only/privacy qualifier follows immediately. 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?
Given the tool's simplicity (one optional param), rich annotations, and existing output schema, the description is fully sufficient. It explains what data is returned, the language options, and the side-effect profile. Nothing critical is missing 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 schema has no descriptions for its single parameter, so the description must compensate. 'In English or Spanish' adds meaning to the locale parameter, clarifying that the enum values control the response language. The parameter is optional and self-explanatory further, but the description could have explicitly mapped locale to language for full clarity.
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 verb ('Return') and resource ('verified public Wash & Fold and pickup/delivery availability'), which clearly distinguishes it from siblings focused on location hours, ordering handoff, pickup/delivery policy, and pricing. The 'in English or Spanish' phrase also clarifies the locale scope without confusing it with other service resources.
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 gives clear context for when to use the tool: when needing verified public availability information. It also provides a when-not by saying it never creates an order, signaling not to use it for order-related tasks. However, it does not explicitly name or contrast the sibling tools, so the routing guidance is slightly less direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Nonpartisan U.S. Congress data: bill decodes, rep lookup, bilingual EN/ES, read-only, no accounts.
Services, case studies, 169 data and AI guides, and AI readiness scoring. Read-only, keyless.
Wash-filtered intelligence for x402: categories, services, wash analysis, trends.
Read-only MatFlow data: pricing, competitors, features, FAQs for combat-sports gyms.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct information area: hours/location, ordering link, delivery policy, pricing, and services. There is no meaningful overlap between tool purposes, and the descriptions reinforce these boundaries.
All tool names follow the exact pattern get_washbodega_<topic> with consistent snake_case verb-noun naming. The naming is predictable and makes the tool set easy to navigate.
Five tools is a well-scoped size for a read-only service discovery server. Each tool covers one necessary public information category without excess or redundancy.
For the stated purpose of service discovery, the tool set covers all key public-facing information: location hours, ordering link, pickup/delivery policy, pricing, and services. No major operational gaps exist because this server is intentionally read-only and does not need create/update/delete tools.
