Premrest

submit_service_request

Idempotent

Creates a Premrest quote, preferred-date booking or flood restoration 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.

Input Schema

Name	Required	Description
`email`	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. For slippery floors: wet or dry conditions, contamination or existing coatings, and any slip-test findings if known. For flooding: what happened, when it started, affected areas and known access constraints.
`service`	Yes	Service id. non-slip-coatings covers slippery-floor assessments, anti-slip coatings and tile etching. A product or treatment choice is not required.
`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	quote, booking, or urgent_flood. urgent_flood is a flood restoration enquiry; preferred date is not 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	Unique key for this request; reuse only when retrying the same request

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 29, 2026

changedInput schema / properties / details / description

Previous value: -"Floor type, condition, work required and access requirements. For slippery floors, include wet/dry conditions, contamination or existing coatings and any slip-test findings if known; do not require a brand or report. For flooding, include what happened, when it started, affected areas and any known access hazards; never ask the customer to enter an unsafe area"New value: +"Floor type, condition, work required and access. For slippery floors: wet or dry conditions, contamination or existing coatings, and any slip-test findings if known. For flooding: what happened, when it started, affected areas and known access constraints."

changedInput schema / properties / idempotency_key / description

Previous value: -"Generate a unique key for this request; reuse it for retries only"New value: +"Unique key for this request; reuse only when retrying the same request"

changedInput schema / properties / request_type / description

Previous value: -"Use urgent_flood for an immediate flooding issue; no preferred date is required"New value: +"quote, booking, or urgent_flood. urgent_flood is a flood restoration enquiry; preferred date is not required."

changedInput schema / properties / service / description

Previous value: -"Use non-slip-coatings for slippery-floor assessments, anti-slip coatings or tile etching enquiries. The customer does not need to select a product or treatment."New value: +"Service id. non-slip-coatings covers slippery-floor assessments, anti-slip coatings and tile etching. A product or treatment choice is not required."

Changed2 schema fields changedOct 4, 2026

changedInput schema / properties / details / description

Previous value: -"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"New value: +"Floor type, condition, work required and access requirements. For slippery floors, include wet/dry conditions, contamination or existing coatings and any slip-test findings if known; do not require a brand or report. For flooding, include what happened, when it started, affected areas and any known access hazards; never ask the customer to enter an unsafe area"

addedInput schema / properties / service / description

Added value: +"Use non-slip-coatings for slippery-floor assessments, anti-slip coatings or tile etching enquiries. The customer does not need to select a product or treatment."

First observedOct 4, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare non-read-only, open-world, idempotent, non-destructive, but the description adds substantive behavior: the side effect of emailing the Formspree inbox with a configured AI integration source, the idempotency mechanism (same idempotency_key returns the original reference without duplicate delivery), and that photos are not fetched. These are exactly the mutation and retry semantics an agent needs beyond the hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and destination are front-loaded in the first sentence, and each subsequent sentence covers a distinct concern (contact implication, urgent-flood exception, return values, idempotency, scope limits, photo handling). It is dense but nearly every sentence earns its place; only the photo/contact sentences edge toward redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter mutation tool with no output schema, the description supplies what structured fields cannot: the return shape (request reference, delivery status, call/text contact options), the scope boundaries, and retry behavior. Nothing essential to calling it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline applies. The description restates schema facts (urgent_flood needs no preferred date, photo links are optional HTTPS URLs) rather than adding new meaning such as format constraints, valid combinations, or how fields differ in priority.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Creates) and precise resources (Premrest quote, preferred-date booking, or flood restoration enquiry) plus the destination (private staff queue / Formspree inbox). It is clearly distinct from the only sibling, list_services, which is a read-only catalogue action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the condition of use ('Submitting an enquiry requests contact from Premrest about that enquiry') and carves out what the tool is not for (no dispatch, arrival, price, booking confirmation, or payments), which steers the agent away from misuse. It does not explicitly name an alternative tool, but with only one read-only sibling the routing picture is still clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Premrest tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?