Entervista

Place a service request

place_service_request

One call for any trade job (repair, quote, booking). Pass service_sku (or a plain description and it matches one), intake_answers keyed by the field ids from get_service_requirements, customer (name, phone, address with line1+zip), preferred_time, and slot_start only when the service flow asks for one. For an unchanged retry after receiving a receipt, include retry_ref and its customer_token with the original details. For quote-first requests without a slot, optionally generate and securely save intent_capability before the first submission; explicitly repeat the same business/details/capability to recover a lost first receipt. Do not silently resubmit. Without either capability this creates a separate request, even if the phone matches. A quote_required request is sent to the business without a price; a priced booking draft waits for the customer's approval. Follow the returned next_step, and never call a request booked until the business confirms.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	Yes
`notes`	No
`photos`	No	URLs (use upload_photo to turn an image into a URL)
`urgency`	No
`customer`	Yes	Who the job/order is for. Use what the customer already gave you; ask only for what a tool says is missing.
`retry_ref`	No	Existing request reference for an unchanged retry; requires customer_token. A phone number never authorizes a retry.
`slot_start`	No	ISO start from get_availability
`description`	No	The problem in the customer's words; used to match a service if service_sku is omitted
`referred_by`	No	Slug of the business whose error response listed this one under referrals[] (its trusted partner). Lets both businesses see the referral.
`service_sku`	No
`customer_token`	No	Customer token returned with retry_ref; only for an unchanged retry of that request.
`intake_answers`	No
`preferred_time`	No	e.g. 'Tomorrow morning' or an ISO datetime
`intent_capability`	No	Optional secret 32-byte random client capability, encoded as lowercase hex. Save before sending a quote-first request without a slot; explicitly repeat unchanged details with the same capability to recover a lost first receipt. Never combine with retry_ref/customer_token; never silently resubmit.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

addedInput schema / properties / customer_token

Added value: +{
+  "description": "Customer token returned with retry_ref; only for an unchanged retry of that request.",
+  "type": "string"
+}

addedInput schema / properties / intent_capability

Added value: +{
+  "description": "Optional secret 32-byte random client capability, encoded as lowercase hex. Save before sending a quote-first request without a slot; explicitly repeat unchanged details with the same capability to recover a lost first receipt. Never combine with retry_ref/customer_token; never silently resubmit.",
+  "pattern": "^[a-f0-9]{64}$",
+  "type": "string"
+}

addedInput schema / properties / retry_ref

Added value: +{
+  "description": "Existing request reference for an unchanged retry; requires customer_token. A phone number never authorizes a retry.",
+  "type": "string"
+}

First observedSep 30, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only give the safety profile (readOnly=false, openWorld=true, idempotent=false); the description adds real behavioral substance beyond them: the retry identity model ('Without either capability this creates a separate request, even if the phone matches'), quote_required vs priced-booking draft outcomes, and the state rule 'never call a request booked until the business confirms.' These are non-obvious semantics an agent cannot derive from the schema.

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?

Dense but front-loaded, opening with the core capability and then layering the retry, capability, and flow-state rules in roughly priority order. Nearly every clause carries decision-relevant information; it is a single long run-on paragraph rather than cleanly segmented, which slightly hurts scanability.

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

Completeness4/5

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

For a 14-parameter, multi-flow tool with no output schema, the description covers the hard parts (retry identity, capability recovery, quote vs booking outcomes, next_step handling). It is incomplete on the required 'slug' input and auxiliary fields (notes, photos, urgency, referred_by), and does not describe the receipt/response shape it references.

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

Parameters4/5

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

At 64% schema coverage the description does useful work: it explains that service_sku can be substituted by a plain description (matching), that intake_answers keys come from get_service_requirements, the customer shape (name, phone, address with line1+zip), preferred_time, and the slot_start/retry_ref/customer_token/intent_capability rules. However, it never mentions the required 'slug' parameter nor notes/photos/urgency/referred_by, leaving several fields to the schema alone.

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

Purpose4/5

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

Opens with a specific verb+resource and scope: 'One call for any trade job (repair, quote, booking).' It clarifies that a single tool covers repair, quote, and booking flows, but it never names the sibling tools (request_quote, book_slot) it overlaps with, so the agent must infer the boundary from flow semantics rather than an explicit contrast.

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?

Gives strong conditional guidance: when to pass slot_start ('only when the service flow asks'), when to use retry_ref/customer_token ('unchanged retry after receiving a receipt'), when to generate intent_capability, and an explicit negative rule ('Do not silently resubmit'). It stops short of naming alternative tools for adjacent cases (e.g., request_quote or book_slot), which is the main gap.

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

All Entervista 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?