Skip to main content
Glama

Truvon

Report how it went

report_outcome

After you have acted for your user (booked, ordered, called, got a quote): say what happened, with the search_id and the business's truvon_id. If something was arranged you get the questions to ask your user later and, for a job, a job id. Test traffic (x-truvon-test) is refused: dry-run at https://sandbox.truvon.ai/mcp.

Input Schema

NameRequiredDescriptionDefault
viaNoHow you acted: a Truvon door, the business's own agent endpoint, a platform (a booking or ordering service), its link, its phone, its email
kindNoWith business_closed: closed for good, or temporarily (renovation, vacation, season)
fieldNoWith wrong_information: which fact is wrong
modelNoOptional: the model you run on (for example claude-sonnet-5-5 or gpt-5.5), kept with this report's provenance so what each model reports can be weighed over time. Leave it out if you do not know.
actionYesWhat you did for your user
sourceNoWith business_closed: the link where you saw it (a news story, its own post, a listing marked closed). It is checked and archived, and if it says so the business is closed for every agent.
correctNoWith wrong_information: the right value, as you found it
failureNoWhen failed. business_closed: the business has closed (say what you saw in detail: a closed sign, a disconnected phone, a recording)
outcomeYesconfirmed: the business confirmed; pending: submitted, awaiting the business; handed_off: you gave your user the link or number and they finish it (never counts against the business; the follow-up asks whether it happened); failed: give failure
reopensNoWith a temporary closure: the reopening date it states, YYYY-MM-DD
businessYesThe truvon_id from a result (biz_…) or the business's website domain. Never a name. A business Truvon does not list cannot be reported
assertionNoPlatforms only: your Truvon agent assertion (identity protocol §4, a JWS binding this report to your user's pairwise sub). Accepted only when this MCP request carries an OAuth DPoP access token; see /.well-known/truvon-agent-auth.
search_idNoThe search_id from find_local_businesses, so the outcome teaches similar future needs
connectionNoThe connection code connect_truvon gave you, once your user approved its link. Not needed when your app signed in to Truvon itself.
expected_atNoISO time when the outcome will be knowable: delivery ETA or appointment time

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

The description goes beyond mere data recording by noting the downstream benefits, such as generating 'questions to ask your user later' or a 'job id'. This informs the AI about the value and operational impact of the report.

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 definition is highly concise, using a single focused paragraph. It front-loads the core function and provides necessary technical context about test traffic handling.

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?

Given the high complexity of the 15-parameter schema, the description is appropriately complete by focusing on the high-level flow rather than listing every field.

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?

The schema coverage is complete (100%), which sets a baseline of 3. The description only adds minor semantic context by emphasizing the necessity of the `search_id` for future training needs.

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 clearly states the tool's purpose is to report the outcome of actions taken (booking, ordering, etc.). It specifically requires the inclusion of the `search_id` and `truvon_id`, grounding the purpose in the context of previous interactions.

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 provides an explicit usage prerequisite: the action must have already occurred for the user. This defines the specific window when the tool is relevant in the agent's workflow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources