fixRAgent maintenance triage

Assess a property maintenance photo

assess_property_photo

Assesses 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 reports what it is, how urgent it is and which trade it needs. 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 reads the real photo up to 3 times per connection in a rolling 24 hours (a small free allowance, shared across every keyless caller up to a daily ceiling); past either limit it returns fixRAgent's stored sample result, labelled SAMPLE, and says how to get a free key with no such limit. It reads only a real photo: a written description is not a photo and is not assessed. With no photo, or a photo it cannot read, nothing is assessed and the reply gives a fixragent.com link where the person adds the photo and sees the full Triage Profile. An urgency, trade or finding that this call did not return is not fixRAgent's. Scope: photos of building assets and faults. It does not assess people, pets, injuries, rashes, medical or veterinary questions, vehicles, food, documents, screenshots or photos of screens. It is not an emergency service: a fire, a gas smell or hissing gas, a carbon-monoxide alarm sounding, water pouring onto live electrics or anyone hurt needs the local emergency number (911 in the US), not a photo assessment. It does not price repairs, book contractors or decide insurance claims; 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.	fast
`image`	No	The photo as a file reference: an object whose download_url is an https URL of a JPEG, PNG or WebP image (at most 3 MB, at least 1 KB). fixragent.com downloads it once, under the same limits and the same location-metadata removal as image_base64. Give either image or image_base64, not both.
`reporter`	No	Who took the photo. Changes how the explanation is worded, not the verdict.	resident
`mime_type`	No	The photo's type: needed with image_base64, optional with image. Must match the bytes; a mismatch is refused, not guessed.
`image_base64`	No	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. Give either image_base64 (with mime_type) or image, not both. A full photo written out as base64 by the assistant itself is long and slow to send, and a copy shrunk or turned black and white reads worse than the original; a call with no photo instead returns a link where the person adds the original photo, and that result reads back by its code.
`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. Sent without a photo, it is not assessed.

Output Schema

TableJSON Schema

Name	Required	Description
`core`	No	The fixed contract: asset, fault, tier, trade_required, resident_explanation and the rest.
`reason`	No
`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`	No	The Triage Profile as a page a resident or contractor can open.
`handoff_id`	No	h-<code>: get_triage_profile reads the result back once the photo is added there.
`instruction`	No	What to do with a not-assessed reply, and that nothing in it is fixRAgent's.
`outcome_url`	No	Two taps to tell us what actually fixed it.
`diagnosis_id`	No	Server-minted id for this assessment; the key for the profile and the outcome.
`not_assessed`	No	true = nothing was assessed; there is no fixRAgent urgency, trade or finding. Pass add_photo_url on.
`problem_text`	No	On a not-assessed reply: the words the caller sent, handed back so a photo added in the card goes with them.
`add_photo_url`	No	fixragent.com page where the person adds the photo and sees the full Triage Profile.
`engine_version`	No
`rubric_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

addedOutput schema / properties / problem_text

Added value: +{
+  "description": "On a not-assessed reply: the words the caller sent, handed back so a photo added in the card goes with them.",
+  "type": "string"
+}

Changed6 schema fields changedOct 16, 2026

addedOutput schema / properties / add_photo_url

Added value: +{
+  "description": "fixragent.com page where the person adds the photo and sees the full Triage Profile.",
+  "type": "string"
+}

addedOutput schema / properties / handoff_id

Added value: +{
+  "description": "h-<code>: get_triage_profile reads the result back once the photo is added there.",
+  "type": "string"
+}

addedOutput schema / properties / instruction

Added value: +{
+  "description": "What to do with a not-assessed reply, and that nothing in it is fixRAgent's.",
+  "type": "string"
+}

addedOutput schema / properties / not_assessed

Added value: +{
+  "description": "true = nothing was assessed; there is no fixRAgent urgency, trade or finding. Pass add_photo_url on.",
+  "type": "boolean"
+}

addedOutput schema / properties / reason

Added value: +{
+  "enum": [
+    "no_photo",
+    "photo_not_arrived",
+    "not_added_yet"
+  ],
+  "type": "string"
+}

removedOutput schema / required

Removed value: -[
-  "diagnosis_id",
-  "share_url",
-  "core"
-]

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / image_base64 / description

Previous value: -"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. Give either image_base64 (with mime_type) or image, not both."New value: +"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. Give either image_base64 (with mime_type) or image, not both. A full photo written out as base64 by the assistant itself is long and slow to send, and a copy shrunk or turned black and white reads worse than the original; a call with no photo instead returns a link where the person adds the original photo, and that result reads back by its code."

changedInput schema / properties / problem_text / description

Previous value: -"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."New value: +"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. Sent without a photo, it is not assessed."

Changed4 schema fields changedSep 30, 2026

addedInput schema / properties / image

Added value: +{
+  "description": "The photo as a file reference: an object whose download_url is an https URL of a JPEG, PNG or WebP image (at most 3 MB, at least 1 KB). fixragent.com downloads it once, under the same limits and the same location-metadata removal as image_base64. Give either image or image_base64, not both.",
+  "properties": {
+    "download_url": {
+      "description": "An https URL the photo can be downloaded from.",
+      "type": "string"
+    },
+    "file_id": {
+      "description": "The host's id for the file. Not used to fetch it.",
+      "type": "string"
+    },
+    "file_name": {
+      "description": "Optional. Not used.",
+      "type": "string"
+    },
+    "mime_type": {
+      "description": "Optional. If given, it must match the downloaded bytes.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "download_url",
+    "file_id"
+  ],
+  "type": "object"
+}

changedInput schema / properties / image_base64 / description

Previous value: -"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."New value: +"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. Give either image_base64 (with mime_type) or image, not both."

changedInput schema / properties / mime_type / description

Previous value: -"The photo's type. Must match the bytes; a mismatch is refused, not guessed."New value: +"The photo's type: needed with image_base64, optional with image. Must match the bytes; a mismatch is refused, not guessed."

removedInput schema / required

Removed value: -[
-  "image_base64",
-  "mime_type"
-]

Changed1 schema field changedSep 29, 2026

changedInput schema / properties / depth / description

Previous value: -"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."New value: +"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."

First observedSep 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Even though annotations exist, the description adds a great deal beyond them: one request is spent from the key's daily allowance, keyless calls get up to 3 reads per connection in a rolling 24 hours up to a shared daily ceiling, and past either limit it returns fixRAgent's stored sample labelled SAMPLE. It also discloses the auth/quota model, the location-metadata removal at the server (but not before leaving the caller), and that a failed read yields nothing assessed. None of this contradicts the annotations (readOnlyHint=false is consistent with quota consumption).

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?

Long but front-loaded: the core capability and return contract come first, then quota, then exclusions, then scope limits. Nearly every sentence carries distinct information, though the density and length invite skimming; a tighter grouping of the quota rules would help.

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?

For a tool with six parameters, nested file objects, enums, and an output schema, the description covers the return contract (asset, fault visibility, four urgency words, trade, resident line, agreement count), the quota and fallback behavior, and the safety and scope boundaries. Nothing an agent needs to call or interpret it 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%, so the schema already documents all six parameters including the depth fast/deep semantics and the base64 vs file-reference tradeoff. The description reinforces the return contract and the no-photo fallback but adds no parameter syntax or constraints beyond the schema. Baseline 3 is appropriate when the schema carries the weight.

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 precise verb and resource ('assesses a photo') and immediately scopes it to building assets and faults, listing concrete examples (appliance, boiler, pipe, water heater, electrical panel, leak, damage). It also draws the boundary against what it is not (people, pets, injuries, vehicles, food, documents, screenshots), so an agent can distinguish it from both sibling tools without reading either schema.

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 contextual routing: use it when there is a real photo, not a written description; call 911 rather than this tool for gas smells, fire, CO alarms or live electrics; and it does not price, book or dispatch. It does not, however, name its siblings get_triage_profile or try_sample, so alternative-tool selection is 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 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?