fixragent-mcp

Assess a property maintenance photo

assess_property_photo

Assesses a photo of a building fault—appliance, boiler, leak, pipe or panel—to report what it is, how urgent it is, and which trade to call.

Instructions

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. 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_path`	No	Local to this stdio server, not a field of the remote tool: a path to the photo inside the folder named by FIXRAGENT_IMAGE_DIR (off when that is not set). The file is read here and sent as image_base64 with its mime_type. JPEG, PNG or WebP, 1 KB to 3 MB. Give image_path, image_base64 or image, only one.
`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.
`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 observedv0.1.1Oct 14, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description explains why the call is not free of side effects — it spends one request from the key's daily allowance, or up to 3 keyless reads per connection in a rolling 24 hours, then degrades to a SAMPLE-labelled stored result. That is real context beyond the annotations, though the auth/quota mechanics are stated at length rather than crisply.

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 purpose, then the return contract, then limits, then scope, then the emergency disclaimer — a sensible order for a caller skimming for eligibility. It is long and carries some restatement ('it routes the job, it does not quote or dispatch it' after 'does not price repairs, book contractors'), but almost every sentence carries a distinct constraint.

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 seven parameters, a nested image object and three string-output paths, nothing an agent needs to call correctly is missing: input modes, size/format limits, quota behavior, sample fallback and out-of-scope content are all covered. An output schema exists, so the description is not obliged to detail return values, yet the contract summary is a useful orientation.

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 baseline is 3; the description adds value by tying the 'how many independent reads agreed' output back to the depth setting and by explaining that location metadata is stripped server-side before hashing or storage. It does not, however, walk through the three mutually exclusive image input paths, which is handled entirely in the schema.

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?

Names a specific verb and resource ('Assesses a photo of something in a building'), enumerates the asset types it covers (appliance, boiler, pipe, water heater, electrical panel, leak, damage), and states the returned contract. Scope exclusions at the end make it trivially separable from unrelated tools.

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 when-to-use conditions (a photo of a building asset or fault), explicit when-NOT-to-use boundaries (people, pets, injuries, vehicles, food, documents, screenshots), and an escalation rule pointing to emergency services for fire, gas, CO alarms or live-electrics water. It also explains the keyed vs keyless paths so the caller knows which mode it is in.

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

Deploy Server