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

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

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.
`next_steps`	No	Present only on a real assessment made with no key: two links to offer the person. "I manage this building" -> url puts this job in their maintenance queue (sign in or sign up, then it is a job; good 7 days); "I live here" -> url is the Triage Profile link to send to their building manager. Pass each url on exactly as given.
`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 20, 2026

addedOutput schema / properties / next_steps

Added value: +{
+  "description": "Present only on a real assessment made with no key: two links to offer the person. \"I manage this building\" -> url puts this job in their maintenance queue (sign in or sign up, then it is a job; good 7 days); \"I live here\" -> url is the Triage Profile link to send to their building manager. Pass each url on exactly as given.",
+  "items": {
+    "properties": {
+      "choice": {
+        "type": "string"
+      },
+      "id": {
+        "enum": [
+          "keep",
+          "send_manager"
+        ],
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      },
+      "sub": {
+        "type": "string"
+      },
+      "text_line": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

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.8/5.0

Behavior5/5

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

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) only sketch the safety profile. The description goes much further: one call spends one request from the key's daily allowance, keyless callers get up to 3 reads per connection in a rolling 24 hours shared against a daily ceiling, past-limit responses fall back to a labelled SAMPLE result, and unreadable input yields a link rather than a verdict — all failure and cost behaviour an agent cannot infer from structured fields.

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 purpose and the returned contract before the quota, fallback and scope clauses. It is long, but nearly every sentence carries operational information an agent needs; the only near-redundancies are the repeated restatements of the free-key and sample-fallback rules and the slightly abstract line that 'an urgency, trade or finding that this call did not return is not fixRAgent's'.

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 6-parameter, nested-object, quota-metered tool with an output schema, the description supplies exactly what the schema cannot: cost/quota semantics, keyless degradation, SAMPLE labelling, out-of-scope inputs, and the emergency carve-out. Return-value shape is left to the output schema, which is appropriate, so nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is already 100%, so the schema carries the parameter detail (enums for depth/reporter/mime_type, the image vs image_base64 exclusivity, size bounds). The description still adds genuine semantic value by tying 'no photo' and 'problem_text' to actual behaviour — a written description is not assessed and reported symptoms are checked against, never treated as, ground truth. It does not, however, explain depth fast vs deep trade-offs itself,

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?

Specific verb+resource (assesses a photo of building assets/faults) plus a precise inventory of what the caller gets back (asset, fault visibility, one of four urgency words, trade, resident line, agreement count). The scope paragraph explicitly delimits what it is not for (people, pets, vehicles, documents, screenshots), so it is distinguishable from get_triage_profile and try_sample without opening a 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?

States when to use it (a real photo of a building asset or fault), when not (a written description is not a photo; no photo returns a link, not an assessment), what is out of scope, and defers genuine emergencies to 911. Also explains that it routes rather than prices, books or dispatches, which prevents misfires on adjacent jobs.

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?