Field Service Business Platform by Doing Work

quotes_get

One customer quote in this shop: status, every version with its lines and totals, the job and customer, and when it was sent and viewed. Read only. This is a quote, not an AI line draft (that is quotes.draft).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "quote_id": "<quote_id>"
    },
    "name": "quotes_get"
  }
}

Input Schema

Name	Required	Description	Default
`quote_id`	Yes

Output Schema

Name	Required	Description
`job_id`	Yes
`status`	Yes
`shop_id`	Yes
`currency`	Yes
`quote_id`	Yes
`versions`	Yes
`created_at`	Yes
`customer_id`	Yes
`total_minor`	Yes	Amount in minor units of the currency (cents).
`last_sent_at`	Yes
`customer_name`	Yes
`last_viewed_at`	Yes
`first_viewed_at`	Yes
`max_total_minor`	Yes	Amount in minor units of the currency (cents), or null.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedOutput schema / properties / versions / items / properties / lines / items / properties / source
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / versions / items / properties / lines / items / required

Previous value: -[
-  "position",
-  "description",
-  "quantity",
-  "unit_price_minor",
-  "amount_minor",
-  "option_key",
-  "optional",
-  "kind",
-  "taxable"
-]New value: +[
+  "position",
+  "description",
+  "quantity",
+  "unit_price_minor",
+  "amount_minor",
+  "option_key",
+  "optional",
+  "kind",
+  "taxable",
+  "source"
+]

AddedNov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description must carry the safety profile, and it does: 'Read only' clearly signals a non-mutating fetch, compensating for the missing readOnlyHint. It also enumerates the payload shape (status, all versions with lines and totals, job, customer, sent/viewed times), which tells the agent what depth of data to expect. It omits not-found behavior and any scoping/permission caveats beyond the vague 'in this shop'.

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

Conciseness5/5

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

Three short sentences with no waste, and the resource plus payload contents are front-loaded before the safety note and the disambiguation. Each sentence does distinct work: identify the resource, declare read-only, exclude the lookalike sibling.

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?

The tool is simple (one required param) and an output schema exists, so return-value detail need not be spelled out here. The description covers what is fetched, that it is read-only, and which sibling it is not, which is enough to call it correctly. The only real gap is the unexplained quote_id parameter, which neither schema nor description resolves.

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

Parameters2/5

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

Schema description coverage is 0% – quote_id is documented only as a UUID string, with no statement of what it identifies or where it comes from. The description never mentions the identifier at all, so it adds no meaning beyond the bare schema. For a one-parameter tool with zero schema coverage, the description should at minimum say that quote_id is the quote's unique identifier obtainable from quotes_list or quotes_search.

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?

The description pins down exactly what is returned: a single customer quote with its status, every version with lines and totals, the job and customer, and sent/viewed timestamps. It also explicitly separates itself from quotes.draft, so an agent can distinguish it from at least the most confusable sibling. It stops short of 5 because the head phrase 'One customer quote in this shop' is a noun phrase rather than a stated verb+resource, leaving the retrieval action implicit.

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?

There is an explicit when-not: 'This is a quote, not an AI line draft (that is quotes.draft)', which routes the agent away from the draft workflow. 'Read only' further bounds it to inspection rather than mutation. It gives no guidance on when to use this versus quotes_list or quotes_search, so alternatives for bulk/filtered lookup are left to inference.

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

All Field Service Business Platform by Doing Work 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?