Read-only bilingual Wash Bodega services, pricing, hours, pickup policy, and ordering handoff.
Scored across 5 tools
Each tool maps to a distinct facet of the business (hours, pricing, services, route policy, ordering link), and the descriptions explicitly cross-reference boundaries (rates on get_washbodega_pricing, links on ordering handoff). Minor overlap exists between get_washbodega_services (which returns explanatory HTML pages) and get_washbodega_ordering_handoff (which returns the ordering link), so an agent may occasionally need both.
All five tools follow the identical get_washbodega_<noun> pattern, keeping the same verb and namespace prefix throughout. The convention is verbose but perfectly predictable.
Five focused, read-only lookup tools is exactly the right scope for a small business service-discovery server. Every tool covers a distinct customer question with no filler.
The surface covers the core inquiry lifecycle for a laundry service: location/hours, services offered, pricing, pickup/delivery qualification, and how to order. Minor gaps exist (no contact info, FAQ/turnaround times, or specialty/commercial quote path beyond being excluded), which agents can work around.
Return the verified store location, scoped 24/7 customer-access hours, and the owner-confirmed 24/7 staffing without implying service-specific 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 declare this a safe, idempotent, read-only, closed-world operation, so the safety burden is covered. The description adds genuine provenance context ('verified', 'owner-confirmed') and a caveat about not conflating hours with service availability. It says nothing about caching, rate limits, or freshness beyond the provenance adjectives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the return content. It is dense and slightly convoluted in phrasing ('scoped 24/7 customer-access hours', 'owner-confirmed 24/7 staffing'), but every clause carries a distinct qualifier rather than padding.
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?
An output schema exists, so return values need not be described, and annotations cover the safety profile. For a simple read tool with one optional parameter, the description supplies enough to call it correctly, with the only real gap being the unmentioned locale parameter.
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 single 'locale' parameter is never mentioned in the description. The schema's enum (en-US/es-US) and default carry the meaning, but the description does not compensate for the coverage gap by explaining localization behavior. Only the enum values themselves add 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 clearly names the resources: store location, customer-access hours, and staffing. This is distinguishable from siblings like pricing and services. It stops short of explicitly naming which sibling to use instead, but the resource scope is 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?
There is no explicit when-to-use or when-not-to-use statement. The clause 'without implying service-specific availability' implicitly routes the agent elsewhere (the services tool) for service availability, which is weak but real boundary guidance. No prerequisites or alternatives are named directly.
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, plus the HTML pages that explain them. Read only; never collects personal data or creates an order. Rates stay on get_washbodega_pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | en-US |
| Name | Required | Description |
|---|---|---|
| locale | Yes | |
| services | Yes | |
| sourceUrl | Yes | |
| boundaries | Yes | |
| publishedAt | Yes | |
| readingPages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower; the description still adds useful guarantees ('never collects personal data or creates an order') and a scope qualifier ('verified public'). It says nothing about response shape, but an output schema exists to carry that.
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 tight sentences, front-loaded with what is returned before the constraints; every clause (language, HTML pages, read-only, no PII, no order, pricing redirect) carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and full annotations, the description covers nearly everything needed for a single-enum read tool. The only omission is disambiguating versus get_washbodega_pickup_delivery_policy, which an agent might otherwise consider for the same question.
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?
Single optional enum parameter with 0% schema description coverage, but the description supplies the meaning: results come back in English or Spanish, mapping to the en-US/es-US enum values. That is the only semantic an agent needs here.
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?
Names a specific verb (return) and resource (verified public Wash & Fold and pickup/delivery availability plus explanatory HTML pages), and explicitly carves out rates as belonging to a sibling. An agent can tell it apart from get_washbodega_pricing without opening either schema.
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 redirects rate questions to get_washbodega_pricing, which is a real routing rule. However, it does not clarify the boundary with get_washbodega_pickup_delivery_policy, a sibling whose subject overlaps with 'pickup/delivery availability'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_washbodega_services3 fields changedOutput schema / properties / readingPages / properties / petGuideAdded value: +{
+ "format": "uri",
+ "type": "string"
+}Output schema / properties / readingPages / properties / petToolkitAdded value: +{
+ "format": "uri",
+ "type": "string"
+}Output schema / properties / readingPages / requiredPrevious value: -[
- "washFold",
- "pickupDelivery",
- "comparison",
- "caregiverToolkit"
-]New value: +[
+ "washFold",
+ "pickupDelivery",
+ "comparison",
+ "caregiverToolkit",
+ "petToolkit",
+ "petGuide"
+]get_washbodega_services2 fields changedOutput schema / properties / readingPagesAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "caregiverToolkit": {
+ "format": "uri",
+ "type": "string"
+ },
+ "comparison": {
+ "format": "uri",
+ "type": "string"
+ },
+ "pickupDelivery": {
+ "format": "uri",
+ "type": "string"
+ },
+ "washFold": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "washFold",
+ "pickupDelivery",
+ "comparison",
+ "caregiverToolkit"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "sourceUrl",
- "publishedAt",
- "locale",
- "services",
- "boundaries"
-]New value: +[
+ "sourceUrl",
+ "publishedAt",
+ "locale",
+ "services",
+ "boundaries",
+ "readingPages"
+]get_washbodega_location_hoursget_washbodega_ordering_handoffget_washbodega_pickup_delivery_policyget_washbodega_pricingget_washbodega_servicesBook, track and manage laundry & dry-cleaning pickup in Los Angeles and San Francisco.
Public Bidwell Health service information, state availability, care limits, and visit guidance.
Read-only info for a Buenos Aires dental clinic: treatments, reference prices, hours and booking.
Services and prices of lovefengis, a software studio in Izmir, Turkey. Read-only, no auth.
Add one secure layer between your agents and this server.