Assess a property maintenance photo: what it is, how urgent, which trade to call.
Scored across 3 tools
The three tools have broadly distinct roles: assess_property_photo creates an assessment, get_triage_profile retrieves a saved one, try_sample returns a fixed demo. However, try_sample overlaps conceptually with both the keyless SAMPLE fallback of assess_property_photo and the retrieval behavior of get_triage_profile, which could cause minor misselection.
All three names use clean snake_case with a verb_noun/verb_object structure: assess_property_photo, get_triage_profile, try_sample. The convention is predictable and readable throughout.
Three tools is a lean but defensible surface for a single-purpose photo-triage service, and each tool has a clear justification. It leans slightly thin, since there is no listing or key-management tool, but nothing feels redundant.
The core lifecycle (create an assessment via photo, retrieve it by id) is covered, and assessments being immutable removes the need for update/delete. Minor gaps exist, such as no way to list a caller's prior assessments or manage API keys, but agents can work around these.
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.
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
Returns a saved fixRAgent assessment by its diagnosis_id (from an assessment, the last part of a fixragent.com/c/ link, or the h- code that comes with a fixragent.com photo link once the photo has been added there; with no photo added yet, it reports that there is no result). Read only: it never re-reads the photo, never calls the model and spends nothing from the daily allowance. It takes one id and returns one assessment with no contact details of any kind, the same assessment anyone with its fixragent.com/c/ link can open. It needs no key; if a key is sent, it must be a valid one. Reads are limited to 20 an hour per address, shared with assessments.
| Name | Required | Description | Default |
|---|---|---|---|
| diagnosis_id | Yes | The UUID of a saved assessment, the last path segment of a fixragent.com/c/<id> link, or h- followed by the code from a fixragent.com photo link. |
| Name | Required | Description |
|---|---|---|
| core | No | |
| reason | No | |
| agreement | No | |
| config_id | No | |
| share_url | No | |
| created_at | No | |
| 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. |
| diagnosis_id | No | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: no photo re-read, no model call, no spend from the daily allowance, no contact details in the response, no key required but a supplied key must be valid, and a 20/hour shared rate limit. That is exactly the operational context an agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and every clause is substantive, but the single sprawling sentence with nested parentheticals is denser than needed and pushes the cost/privacy/rate-limit facts into a run-on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description still covers auth posture, cost, privacy, no-result behavior and rate limiting. Nothing required to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter's schema description already explains the UUID / link-segment / h- code forms. The description restates the same id sources without adding syntax or format meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Returns a saved fixRAgent assessment by its diagnosis_id'. It is the only read-back tool against siblings assess_property_photo (which creates an assessment) and try_sample, so an agent can place it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when it applies (an existing diagnosis_id from a link or photo code) and the no-result case when no photo has been added yet. It does not explicitly name a sibling as the alternative for producing a fresh assessment, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a stored fixRAgent assessment of a sample photo from fixRAgent's test set (an HVAC air handler and furnace), labelled SAMPLE, plus how to get a free key. Needs no key and no input, reads no photo and spends nothing. The result is a sample, not an assessment of anyone's own photo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| core | Yes | The fixed contract, exactly as the engine returned it for the sample photo. |
| label | Yes | One sentence saying what this is. |
| photo | No | What the sample photo shows, in words. The photo itself is not served. |
| sample | Yes | Always true: this is a stored example, not a read of any photo you sent. |
| agreement | No | n reads ran, k agreed. |
| config_id | No | |
| next_step | Yes | How to get a free key and assess your own photo. |
| captured_utc | No | When the real engine produced this answer. |
| diagnosis_id | No | |
| engine_version | No | |
| rubric_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive. The description adds meaningful context beyond them: no key required, nothing is read or spent, and the output is a static sample rather than a live assessment. It stays silent only on output shape, which the output schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and kept to two sentences. The 'no key, no input, reads no photo, spends nothing' clause is slightly listy/redundant, but each element disambiguates a distinct worry, so it mostly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input, read-only sample tool with an output schema present, the description covers everything an agent needs: what it returns, that it is a sample, and that it is free and keyless. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly reinforces that no input is required, matching the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and artifact: it returns a stored fixRAgent assessment of a sample photo from a test set, explicitly labelled SAMPLE. It also disambiguates from sibling assess_property_photo by clarifying that the result is not an assessment of the caller's own photo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames the use case: no key, no input, no cost, meant for trying the service. It doesn't explicitly name assess_property_photo as the alternative for real photos, but the 'sample, not an assessment of anyone's own photo' line makes the boundary easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
assess_property_photo1 field changedOutput schema / properties / next_stepsAdded 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"
+}assess_property_photo1 field changedOutput schema / properties / problem_textAdded 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"
+}get_triage_profile1 field changedOutput schema / properties / problem_textAdded 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"
+}assess_property_photo6 fields changedOutput schema / properties / add_photo_urlAdded value: +{
+ "description": "fixragent.com page where the person adds the photo and sees the full Triage Profile.",
+ "type": "string"
+}Output schema / properties / handoff_idAdded value: +{
+ "description": "h-<code>: get_triage_profile reads the result back once the photo is added there.",
+ "type": "string"
+}Output schema / properties / instructionAdded value: +{
+ "description": "What to do with a not-assessed reply, and that nothing in it is fixRAgent's.",
+ "type": "string"
+}Output schema / properties / not_assessedAdded value: +{
+ "description": "true = nothing was assessed; there is no fixRAgent urgency, trade or finding. Pass add_photo_url on.",
+ "type": "boolean"
+}Output schema / properties / reasonAdded value: +{
+ "enum": [
+ "no_photo",
+ "photo_not_arrived",
+ "not_added_yet"
+ ],
+ "type": "string"
+}Output schema / requiredRemoved value: -[
- "diagnosis_id",
- "share_url",
- "core"
-]get_triage_profile6 fields changedOutput schema / properties / add_photo_urlAdded value: +{
+ "description": "fixragent.com page where the person adds the photo and sees the full Triage Profile.",
+ "type": "string"
+}Output schema / properties / handoff_idAdded value: +{
+ "description": "h-<code>: get_triage_profile reads the result back once the photo is added there.",
+ "type": "string"
+}Output schema / properties / instructionAdded value: +{
+ "description": "What to do with a not-assessed reply, and that nothing in it is fixRAgent's.",
+ "type": "string"
+}Output schema / properties / not_assessedAdded value: +{
+ "description": "true = nothing was assessed; there is no fixRAgent urgency, trade or finding. Pass add_photo_url on.",
+ "type": "boolean"
+}Output schema / properties / reasonAdded value: +{
+ "enum": [
+ "no_photo",
+ "photo_not_arrived",
+ "not_added_yet"
+ ],
+ "type": "string"
+}Output schema / requiredRemoved value: -[
- "diagnosis_id",
- "share_url",
- "core"
-]assess_property_photo2 fields changedInput schema / properties / image_base64 / descriptionPrevious 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."Input schema / properties / problem_text / descriptionPrevious 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."get_triage_profile1 field changedInput schema / properties / diagnosis_id / descriptionPrevious value: -"The UUID of a saved assessment, or the last path segment of a fixragent.com/c/<id> link."New value: +"The UUID of a saved assessment, the last path segment of a fixragent.com/c/<id> link, or h- followed by the code from a fixragent.com photo link."assess_property_photo4 fields changedInput schema / properties / imageAdded 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"
+}Input schema / properties / image_base64 / descriptionPrevious 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."Input schema / properties / mime_type / descriptionPrevious 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."Input schema / requiredRemoved value: -[
- "image_base64",
- "mime_type"
-]assess_property_photo1 field changedInput schema / properties / depth / descriptionPrevious 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."get_triage_profile1 field changedInput schema / properties / diagnosis_id / descriptionPrevious value: -"The UUID from assess_property_photo, or the last path segment of a fixragent.com/c/<id> link."New value: +"The UUID of a saved assessment, or the last path segment of a fixragent.com/c/<id> link."try_sample1 field changedOutput schema / properties / label / descriptionPrevious value: -"One sentence saying what this is, to show the person as-is."New value: +"One sentence saying what this is."assess_property_photoget_triage_profiletry_sampleRoutes home emergencies to the right trade: who to call in what order, first steps, sourced costs.
Property maintenance triage and vendor packet generator.
Property management AI: work orders, vendors, appliances, and triage for Claude and ChatGPT.
Quote UK trades jobs from any AI agent. Price breakdown + tappable booking link.
Add one secure layer between your agents and this server.
