Commercial floor care enquiries and urgent flood response requests for Australian facilities.
Scored across 2 tools
The two tools target clearly different actions: list_services retrieves available services, while submit_service_request creates an enquiry. There is no overlap in purpose or resource.
Both names use consistent snake_case and follow a verb_noun pattern: list_services and submit_service_request. The convention is predictable and readable.
With only 2 tools, the surface feels thin for a service enquiry domain. A third tool for service details or request status would make the set feel better scoped.
The set covers browsing services and creating a request, but lacks read/update/cancel operations for submitted requests. An agent cannot retrieve a request by reference or modify a booking, which are notable lifecycle gaps.
List Premrest flooring services. Includes urgent flood restoration and phone/text contact options. Prices and availability require assessment by the Premrest team.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the returned catalog includes urgent flood restoration and phone/text contact options, and that prices/availability are NOT returned but require assessment.
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?
Three short, front-loaded sentences with no filler; the purpose leads and the expectations-setting note about pricing follows. Slightly more expository than strictly necessary but each sentence carries 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?
For a parameterless, read-only list tool with no output schema, the description is nearly sufficient: it covers what is returned and explicitly warns that prices/availability are excluded. Only the relationship to the sibling submit tool is unaddressed.
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 takes zero parameters, so the schema-level semantics baseline is 4. The description correctly adds no parameter claims that could conflict with the empty object 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?
States a specific verb+resource ('List Premrest flooring services'), which is unambiguous about what the tool does. It does not, however, explicitly distinguish itself from the sibling submit_service_request, leaving that differentiation to inference.
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 statement of when to call this versus the alternative (submit_service_request) or any prerequisite. The discovery use case is only implied by the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Premrest quote, preferred-date booking or urgent flood response enquiry in the private staff queue and sends it to the website Formspree inbox with the configured AI integration source. Submitting an enquiry requests contact from Premrest about that enquiry. urgent_flood requests use flood-restoration and do not require a preferred date. Returns a request reference, delivery status and call/text contact options. Repeated identical requests with the same idempotency_key return the original reference without duplicate delivery. Does not confirm dispatch, arrival time, price or booking and does not process payments. Photo inputs are optional customer-provided HTTPS links.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Customer contact email | ||
| phone | Yes | Customer phone number | |
| address | Yes | Job street address, suburb, state and postcode | |
| company | No | Optional company name | |
| details | Yes | Floor type, condition, work required and access requirements. For flooding, include what happened, when it started, affected areas and any known access hazards; never ask the customer to enter an unsafe area | |
| service | Yes | ||
| area_sqm | No | Approximate area if known; omit if unknown | |
| photo_urls | No | Optional customer-provided HTTPS links. Images are not fetched; chat attachments are not automatically transferred. | |
| request_type | Yes | Use urgent_flood for an immediate flooding issue; no preferred date is required | |
| customer_name | Yes | Customer full name | |
| property_type | Yes | Office, retail, hotel, school, or other property type | |
| preferred_date | No | YYYY-MM-DD in Melbourne time. Required for bookings. A preference only. | |
| preferred_time | No | Optional preferred time or time window | |
| idempotency_key | Yes | Generate a unique key for this request; reuse it for retries only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true and destructiveHint=false, yet the description adds substantial context beyond them: idempotent replays return the original reference without duplicate delivery, the tool does NOT confirm dispatch/arrival/price/booking and does not process payments, and photo links are not fetched. That side-effect and non-guarantee disclosure is exactly the extra value descriptions should carry.
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 passage is dense but front-loaded, leading with what gets created and where, then constraints. One sentence ('Submitting an enquiry requests contact from Premrest about that enquiry') is mildly circular, but the rest earns its place and nothing critical is buried.
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 14 parameters, 9 required, and no output schema, the description compensates by describing the return payload (request reference, delivery status, call/text contact options) and the negative space (no dispatch/price/payment confirmation). Combined with 93% schema coverage, an agent has everything needed to call and interpret this 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 93%, so the baseline is 3, but the description still adds meaning: urgent_flood needs no preferred_date, photo_urls are optional customer-provided HTTPS links that are not fetched, and idempotency_key should be reused only for retries. That is genuine semantic value layered over an already well-documented 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 names a specific verb (Creates) and resource (Premrest quote / preferred-date booking / urgent flood response enquiry) and specifies the destination systems (private staff queue, Formspree inbox, AI integration source). An agent can immediately distinguish this from the sibling list_services without opening any 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?
It clearly states the conditions that select each request_type, e.g. 'urgent_flood requests use flood-restoration and do not require a preferred date', and clarifies that submitting an enquiry only requests contact rather than confirming a booking. It does not explicitly name an alternative tool (only list_services exists as a sibling, and it is not a substitute), so it stops short of 5.
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.
list_servicessubmit_service_requestIndustrial Cleaning Quotes: the site's own MCP server — enquiry (enquiry = a human handoff, not...
Commercial Drainage Quotes: the site's own MCP server — enquiry (enquiry = a human handoff, not...
Industrial Flooring Cost: the site's own MCP server — enquiry (enquiry = a human handoff, not a...
Commercial Laundry Cost: the site's own MCP server — enquiry (enquiry = a human handoff, not a...
Add one secure layer between your agents and this server.