Skip to main content
Glama

company_quote_outcomes

Score sealed job quotes against actual job costing to reveal quoted versus recorded labor, missed parts, realized margin, and verdicts like overran or underquoted.

Instructions

Score sealed job quotes against the window's job costing (built now from every persisted work order and contractor engagement): per quote the quoted hours and loaded labour cost against the recorded labour and contractor cost, the parts and stock the quote never priced, the margin realised at the offered or target price, and a verdict (held, overran, underquoted, open, unmatched); across quotes the realised margin and the contingency the stretch overruns say to carry (payload: quotes, and optionally window_start, window_end, contingency_percent).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowNo
engineNo
operationNobuild
entity_refNo
project_idYes
bundle_jsonYes
payload_jsonNo{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden. It transparently describes the analysis performed, the source of data, and the kinds of results produced (verdicts, margins, contingency). However, it does not explicitly state whether the tool is read-only or if there are side effects, though it strongly implies a non-mutating analysis.

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

Conciseness3/5

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

The description is a single dense run-on sentence containing many clauses and semicolons. It is informative but poorly structured, making it hard to parse quickly. It front-loads the action but could be broken into clear sentences for better readability.

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

Completeness3/5

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

The output schema exists, so return values are formally specified. The description explains the conceptual outputs (per-quote and across-quote metrics) but leaves input semantics unexplained Mugen. It does not cover how to invoke the tool correctly (e.g., what bundle_json should contain) or any potential errors, leaving the agent to guess.

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?

The input schema has 7 parameters with 0% description coverage McLaren. The description mentions only the payload contents ('quotes, and optionally window_start, window_end, contingency_percent') but provides no explanation for the required project_id or bundle_json, nor guidance on how to structure the payload. This is a significant gap.

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 starts with a specific verb 'Score' and a clear resource ('sealed job quotes'). It lays out exactly what is computed (hours, labour cost, parts, margin, verdict) and contrasts it with job costing, making it distinct from siblings like company_job_quote or company_job_costing.

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

Usage Guidelines3/5

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

The description implies usage when scoring quotes against job costing and mentions the data sources ('built now from every persisted work order and contractor engagement'), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

Deploy Server

Other Tools