fixRAgent maintenance triage

Server Details

Assess a property maintenance photo: what it is, how urgent, which trade to call.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 21 days
Last Tested: 2026-10-18 08:46
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-10-17 11:00 across 3 tools

Disambiguation4/5

The three tools have largely distinct purposes: assess_property_photo runs a new assessment, get_triage_profile retrieves a saved one by id, and try_sample returns a stored sample. The main ambiguity is that try_sample and the sample-fallback path of assess_property_photo, plus get_triage_profile, all return stored assessments, but the descriptions clearly separate them.

Naming Consistency4/5

All names follow snake_case verb_noun form (assess_property_photo, get_triage_profile, try_sample), which is predictable and readable. Minor deviation in verb style (assess/get/try) but nothing confusing.

Tool Count4/5

Three tools is on the thin side but well-scoped for a focused photo-triage service, with each tool (create assessment, retrieve by id, get sample) earning its place. No bloat or redundancy that would justify a lower score.

Completeness4/5

The core lifecycle is covered: submit a photo for assessment, retrieve a saved assessment by id, and fetch a sample. There is no listing/enumeration of past assessments and no update or re-assessment operation, but given immutable assessments this is a minor gap an agent can work around.

Available Tools

3 tools

assess_property_photoAssess a property maintenance photoAInspect

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.

ParametersJSON 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

ParametersJSON 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

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.

get_triage_profileRead back a saved triage profileA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.4/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

try_sampleTry a sample assessment (no key needed)A

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

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

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 17, 2026

Changedassess_property_photo1 field changed

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"
+}

Changedget_triage_profile1 field changed

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"
+}

2 tool updatesOct 16, 2026

Changedassess_property_photo6 fields changed

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"
-]

Changedget_triage_profile6 fields changed

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"
-]

2 tool updatesOct 16, 2026

Changedassess_property_photo2 fields changed

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."

Changedget_triage_profile1 field changed

changedInput schema / properties / diagnosis_id / description

Previous 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."

1 tool updateSep 30, 2026

Changedassess_property_photo4 fields changed

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"
-]

3 tool updatesSep 29, 2026

Changedassess_property_photo1 field changed

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."

Changedget_triage_profile1 field changed

changedInput schema / properties / diagnosis_id / description

Previous 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."

Changedtry_sample1 field changed

changedOutput schema / properties / label / description

Previous value: -"One sentence saying what this is, to show the person as-is."New value: +"One sentence saying what this is."

3 tool updatesSep 27, 2026
- First observedassess_property_photo
- First observedget_triage_profile
- First observedtry_sample

Related MCP Connectors

Who Do I Call For? — Emergency Home-Service Router A
io.github.woodydaniel
Routes home emergencies to the right trade: who to call in what order, first steps, sourced costs.
Knowledge & Memory Search
31
Maintenance Concierge AI A
com.checkmycontractorquote
Property maintenance triage and vendor packet generator.
Real Estate Project Management Customer Support
1
PropSWOT — Property Management AI
io.github.TapAds
Property management AI: work orders, vendors, appliances, and triage for Claude and ChatGPT.
Real Estate Customer Support
2
JustFix Estimator B
io.github.Just-Fix
Quote UK trades jobs from any AI agent. Price breakdown + tappable booking link.
CRM Project Management
32

Related MCP Servers

HomeOps Relay
Home Automation & IoT App Automation
woahwhattheheck
A
license
Not graded
quality
B
maintenance
Enables turning spoken household issues into evidence-linked maintenance cases, deterministic diagnostic plans, quote comparisons, and owner-approved but unexecuted action proposals.
Updated 9 days ago (2026-10-09 18:42 UTC)
Apache 2.0
MCP PropTech
Real Estate App Automation Communication
utkarsh-portfolio
F
license
A
quality
D
maintenance
Enables AI agents to automate property maintenance workflows by managing tickets, sending WhatsApp notifications via Twilio, and triggering n8n automation webhooks. It allows users to query maintenance statuses, notify tenants, and escalate issues to vendors using natural language.
Updated 7 months ago (2026-03-10 18:40 UTC)
4
-
plat-costmodel
Real Estate Finance
paintbrushv
A
license
B
quality
B
maintenance
Enables multifamily renovation cost estimation, scope of work generation, contractor bid evaluation, ROI gating, and risk flagging for real estate intelligence agents.
Updated 15 days ago (2026-10-03 20:55 UTC)
11
Apache 2.0
FixTrail
Real Estate Customer Support Legal & Compliance
himani-png
A
license
Not graded
quality
B
maintenance
Enables tenants to report rental repair issues by voice and landlords to be notified instantly, keeping both sides on one append-only, hash-chained timeline with photos, follow-ups, disputes, and dated response-time reports that neither party can quietly alter.
Updated 4 days ago (2026-10-14 22:46 UTC)
MIT

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?