Virtual staging of one empty room from a public listing photo, labelled, original returned.
Scored across 2 tools
The two tools form a clean submit/poll pair: stage_room enqueues a job and stage_status checks it. There is no overlap in purpose, and the description of stage_room explicitly directs agents to stage_status for follow-up.
Both names use snake_case with a shared 'stage_' prefix and a clear object (room/status). The convention is consistent and immediately readable.
Two tools is lean but justified by the simple async-job pattern (submit plus poll). It is at the low edge of the typical 3-15 range, but nothing feels redundant.
The core lifecycle—queue, poll, delivered/skipped/failed outcome—is fully covered, including error reasons. Minor gaps remain: no way to list past jobs, cancel a queued job, or check remaining daily sampler quota.
Queue virtual staging of one empty interior room from a public photo URL (https, JPG/PNG/WebP up to 15 MB). Returns an id to poll with stage_status. Furnished rooms, exteriors and photos with people are skipped. The public sampler stages up to 10 rooms a day for free.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | optional reference, up to 80 characters | |
| photo_url | Yes | https URL of the room photo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses asynchronous queue semantics, the returned id for polling, input format/size limits and a rate limit. It stops short of error/failure behavior or auth requirements, which leaves a modest gap for a mutating job-creating tool.
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?
Three tight sentences: purpose and input constraints first, return/polling behavior second, eligibility exclusions and quota last. No filler and no repetition of the schema.
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 an async job-creation tool with no output schema or annotations, the description supplies the essential contract: accepted inputs, exclusions, quota, and the id-to-poll handoff. Only failure modes and result retrieval details beyond the polling pointer are 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%, so the baseline is 3, but the description adds real constraint detail the schema lacks for photo_url (https only, JPG/PNG/WebP, 15 MB cap). The optional 'ref' parameter is left entirely to the schema, keeping this just under a 5.
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 (queue virtual staging), a precise scope (one empty interior room) and an input source (public https photo URL). It also names the sibling tool stage_status as the polling counterpart, so an agent can distinguish the two without opening schemas.
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?
Explicitly lists what is ineligible (furnished rooms, exteriors, photos with people), states the daily free quota, and routes follow-up work to stage_status. An agent knows both when to call it and what to do next.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a queued staging job. Returns queued, working, delivered (with the labelled staged image URL and the original, valid 30 days), skipped (with the reason) or failed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral load and does so well for outcomes: it enumerates queued, working, delivered (with staged image URL plus original valid 30 days), skipped (with reason), and failed. It provides good visibility into return states and retention, though it does not say whether polling is needed (async timing) or what auth/permissions apply.
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?
One front-loaded sentence states the action, and a second compactly enumerates the possible outcomes. Every clause earns its place with no redundancy.
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?
With no annotations and no output schema, the description compensates by describing the status outcomes and what accompanies delivered and skipped results. It is nearly complete for a one-parameter read tool, missing only guidance on the id's source/format and whether polling is expected.
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 0% and the single required 'id' parameter is undocumented in the schema, but the description's "queued staging job" context makes clear the id identifies the job. However, it adds no format, source, or constraint details for the id.
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 specific verb/resource pair ("Check a queued staging job") and clarifies that it reports status rather than creating one. Sibling stage_room is presumably the enqueueing counterpart, and the "queued staging job" phrasing implicitly distinguishes the two, but it never names the sibling explicitly.
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?
Usage is only implied: the agent must infer that this is the polling/status-check tool to call after stage_room has queued a job. There is no explicit when-to-use, when-not-to-use, or alternative named.
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.
stage_roomstage_statusAI virtual staging that doesn't change the house.
AI virtual staging and architectural rendering: stage rooms, render interiors, exteriors, sketches.
AI virtual staging for real estate — stage rooms, beautify floor plans, classify images.
Enhance, virtually stage and turn real estate listing photos into video with AI.
Add one secure layer between your agents and this server.
