fixRAgent maintenance triage

Assess a property maintenance photo

assess_property_photo

Use this when someone has a PHOTO of something in a building — an appliance, a boiler, a pipe, a water heater, an electrical panel, a fitting, a leak, damage — and wants to know what it is, how urgent it is, and which trade to call. Typical asks: "what is wrong with this water heater", "my tenant sent this photo, is it urgent", "which trade do I call for this". Returns the fixed contract: what the asset is, whether a fault is visible, one of four urgency words (EMERGENCY, TODAY, THIS WEEK, WHENEVER), which trade to call, a line to say to the resident, and how many independent reads agreed. One call reads the photo on fixragent.com and spends one request from the key's daily allowance. Sent with NO key, it does not read the photo: it returns fixRAgent's stored sample result, labelled SAMPLE, and says how to get a free key. Do not use this for: a person, a pet, an injury, a rash, a medical or veterinary question, a vehicle, food, a document, a screenshot, or a photo of a screen. Do not use it for anything happening RIGHT NOW that needs emergency services — a fire, a gas smell or hissing gas, a carbon-monoxide alarm sounding, water pouring onto live electrics, or anyone hurt: tell the user to leave the building and call 911 (or the local emergency number) first, and do not call this tool. Do not use it to price a repair, to book a contractor, or to decide an insurance claim; it routes the job, it does not quote or dispatch it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`depth`	No	fast reads the photo three times, deep five, and the reply reports how many agreed. deep is slower and spends more of the day's budget; use it only when a first read disagreed with itself.	fast
`reporter`	No	Who took the photo. Changes how the explanation is worded, not the verdict.	resident
`mime_type`	Yes	The photo's type. Must match the bytes; a mismatch is refused, not guessed.
`image_base64`	Yes	The photo, base64-encoded. A data:image/jpeg;base64, prefix is accepted and stripped. JPEG, PNG or WebP, at most 3 MB once decoded, at least 1 KB. Location metadata is removed on our server before the photo is hashed, read or stored; it is NOT removed before it leaves the caller.
`problem_text`	No	What the person reported, in their own words ("no hot water since Tuesday"). Optional. Treated as a reported symptom to be checked against the photo, never as ground truth: the reply says whether the report and the photo agree.

Output Schema

TableJSON Schema

Name	Required	Description
`core`	Yes	The fixed contract: asset, fault, tier, trade_required, resident_explanation and the rest.
`sample`	No	true = no key was sent: this is the stored SAMPLE, NOT an assessment of the photo you sent. Absent on a real assessment.
`warnings`	No
`agreement`	No	n reads ran, k agreed. k is null on a tie.
`config_id`	No	An id beginning "fallback-" means a hardcoded config answered, not a measured one.
`share_url`	Yes	The Triage Profile as a page a resident or contractor can open.
`outcome_url`	No	Two taps to tell us what actually fixed it.
`diagnosis_id`	Yes	Server-minted id for this assessment; the key for the profile and the outcome.
`engine_version`	No
`rubric_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description explains why: each call spends one request from the key's daily allowance and the reply reports how many independent reads agreed (implying run-to-run variance). It also discloses the no-key SAMPLE fallback and the location-metadata handling nuance (stripped server-side, not before the payload leaves the caller), which is well beyond what the annotations convey.

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?

Front-loaded with the trigger and payload contract before the exclusions, and every sentence carries real routing information. It is on the long side and the three consecutive 'Do not use' sentences cover related ground, which is slight redundancy but not padding.

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?

Despite an output schema existing, the description still enumerates the return contract, cost model, sample behavior, and privacy handling, so an agent knows exactly what to expect. Nothing needed to call it correctly, or to decide not to, is 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% and the parameters are already well documented in-schema (depth's read count and cost, reporter's wording effect, mime_type match rule, image constraints, problem_text as symptom not ground truth). The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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?

States a specific verb+resource ('assess a PHOTO of something in a building') and the scope of inputs it handles, then spells out the fixed return contract (asset identity, fault visibility, one of four urgency words, trade, resident line, agreement count). An agent can distinguish this from a general triage or sample tool without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit positive triggers with example asks, a hard exclusion list (people, pets, injuries, vehicles, food, documents, screenshots), an emergency escalation rule with concrete signals (gas hiss, CO alarm, water on live electrics) and the instruction not to call the tool, plus what it must not be used for (pricing, booking, insurance). This is about as complete a when/when-not specification as exists.

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

All fixRAgent maintenance triage 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?