MLS compliance for edited listing photos: classify edits, write disclosures, verify provenance.
Scored across 10 tools
Most tools have clearly differentiated roles: listing state, checkout, pack, pricing, and start are distinct lifecycle steps. The only real overlap is among duskly_list_edits, duskly_classify_edit, and duskly_list_prohibited_alterations, since the prohibited set is a subset of the edit catalog and descriptions must be read closely to pick between them. The descriptions do draw the line (catalog vs. per-edit classification vs. never-acceptable subset), which keeps it workable.
Every tool follows the same duskly_<verb>_<noun> snake_case pattern with no deviations. Verbs are used consistently for their action type (get/list/classify/generate/start/verify).
Ten tools is well within a comfortable range and each maps to a distinct step or question in the compliance-and-listing workflow. Nothing appears redundant or padded, and no obvious consolidation is needed.
The surface covers the full read-side lifecycle: discover edits, classify, list prohibited cases, start a listing, check state, pay, fetch deliverables, and verify provenance. Editing and payment are deliberately excluded and redirected to URLs, which is documented but does leave the agent unable to complete the core action end-to-end. There is also no tool to validate or re-check an already-published disclosure for compliance.
Whether a given edit to a real estate listing photo must be disclosed, and whether any market prohibits it outright.
Use this before telling someone an edit is safe to publish. Returns Duskly's classification with the reasoning behind it, drawn from rulebooks read directly rather than summarised from secondary sources.
Classifications: "disclosable" (permitted with disclosure), "ambiguous" (most rulebooks Duskly has read do not name it; Duskly discloses by default), "prohibited" (one or more markets forbid it even with disclosure), "exempt".
Note that "prohibited" means prohibited somewhere, not everywhere. Read carve_out when present.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The edit being performed. One of: day-to-dusk, virtual-staging, declutter, occupied-to-vacant, sky-replacement, virtual-renovation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds substantive context: the four classification meanings, the crucial caveat that "prohibited" means prohibited somewhere rather than everywhere, the instruction to read carve_out when present, and the provenance of the rulings. With no output schema, this interpretation of return values is exactly the kind of disclosure an agent needs.
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 purpose sentence, then a usage instruction, then the classification glossary, then a caveat — a sensible information hierarchy. The one soft spot is the mildly promotional clause about rulebooks "read directly rather than summarised from secondary sources," which adds flavor more than operational value.
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 output schema, the description carries the return-value burden and does so: it names the classification values, explains each, mentions the accompanying reasoning, and flags the carve_out field. Combined with the covered safety annotations, an agent has everything needed to call and interpret this tool.
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?
There is a single required enum parameter with 100% schema description coverage, so the schema fully documents the accepted values. The description only implies the parameter is an edit type ("a given edit") and adds no syntax or selection guidance beyond that, 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?
The description opens with a specific verb+resource pair: it classifies whether a listing-photo edit must be disclosed and whether any market prohibits it. That is far more concrete than the title alone and clearly distinct from the generate/list/verify siblings. It stops short of explicitly naming a sibling tool to contrast against, so it lands at 4 rather than 5.
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?
"Use this before telling someone an edit is safe to publish" gives a clear triggering context and ordering relative to downstream disclosure work. No alternatives are named or excluded, though, so an agent isn't told when to reach for duskly_list_prohibited_alterations or duskly_generate_disclosure instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The exact disclosure text to publish alongside an edited listing photo, written for each surface it has to appear on: the MLS photo description, public remarks, print, and the syndication feed.
Surfaces have different character budgets, so the wording differs per surface rather than being one sentence repeated. Anything that exceeds its budget is reported in over_limit instead of being silently truncated.
Supply original_url when the unaltered original is published somewhere, which California Bus. & Prof. Code §10140.8 requires for listings there. Supply required_string only when a jurisdiction mandates exact wording; it is then used verbatim and never paraphrased.
The disclosure duty falls on the licensee publishing the listing, not on the software or the photographer. This generates the wording; a licensee publishes it.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The edit being performed. One of: day-to-dusk, virtual-staging, declutter, occupied-to-vacant, sky-replacement, virtual-renovation. | |
| original_url | No | Public URL where the unaltered original can be viewed, if one is published. | |
| required_string | No | Exact wording a jurisdiction mandates. Used verbatim when supplied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds behavioral details beyond annotations: wording differs per surface, over-limit items are reported in over_limit instead of truncated, and required_string is used verbatim without paraphrasing. This enriches the agent's understanding of the tool's behavior.
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?
The description is front-loaded with the core purpose, then expands into surface details, budget behavior, and parameter conditions. Every sentence serves a purpose—no filler. It is concise for the complexity it covers.
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 output schema, the description adequately conveys the return value: disclosure text for each surface and an over_limit report for budget exceedances. It lists the surfaces and explains the over-limit behavior. While it doesn't specify the exact output structure (e.g., JSON keys), it gives enough for an agent to infer the shape. Given the tool's complexity, this is nearly complete.
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. The description adds value by explaining the legal requirement for original_url (California Bus. & Prof. Code §10140.8) and clarifying that required_string should only be supplied when jurisdiction mandates exact wording, and is used verbatim. This goes beyond the schema's brief descriptions.
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 action and resource: generating MLS disclosure wording for edited listing photos. It clearly specifies the output is per-surface (MLS photo description, public remarks, print, syndication feed) and distinguishes it from sibling tools, none of which generate disclosure text.
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?
The description provides clear context: it is for generating wording, not publishing; the licensee publishes it. It also gives conditions for optional parameters (original_url for California, required_string for mandated jurisdictions). However, it does not explicitly name alternative tools or state when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Stripe Checkout URL for an unpaid listing, for a person to open and pay.
Duskly does not take payment through MCP and no agent completes a purchase. Give this URL to the person you are working for; once they have paid, the listing is unlocked and duskly_get_listing_pack returns the deliverables.
Returns an error for a listing that is already paid.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | The listing id, the part of a Duskly listing URL after /listing/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the tool does not process payments, the URL is for a human to pay externally, payment unlocks the listing, and the error condition for paid listings. This adds operational context annotations alone do not provide.
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?
The description is four sentences with no waste. The core function is front-loaded in the first sentence, and each subsequent sentence adds essential detail about usage, payment flow, and error behavior.
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 single-parameter tool with no output schema, the description covers the return value (a URL), how to use it (give to person), the post-payment effect, and the error case. Annotations already handle idempotency and side-effect flags, so nothing critical 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%: listing_id is already described as the part after /listing/. The description adds only the contextual implication that the listing must be unpaid, but no new parameter-specific semantics beyond what the schema provides. 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?
The description states a specific action: returning a Stripe Checkout URL for an unpaid listing, for a person to open and pay. It explicitly distinguishes this from payment processing and from siblings like duskly_get_listing_pack, making the purpose unambiguous.
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 gives explicit when-to-use guidance: give the URL to the person, and after payment the listing unlocks and duskly_get_listing_pack returns deliverables. It also states when not to use it (already paid listings return an error), and clarifies no agent completes the purchase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The state of a Duskly listing: how many photos it holds, which have been edited, whether it has been paid for, and how much of its render budget remains.
Takes the listing id from the listing URL. Possession of that id is what authorises this, exactly as it does on the website.
Use this before duskly_get_listing_pack to check whether a listing has been paid for.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | The listing id, the part of a Duskly listing URL after /listing/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context by explaining that possession of the listing id is what authorizes access, exactly as on the website. It does not describe the response format, but the stated state fields partially cover what the caller should expect.
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?
The description is compact and front-loaded: the first sentence states what data is returned, the second explains the id source and authorization, and the third gives usage guidance. Every sentence earns its place without 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?
For a single-parameter read-only lookup with strong annotations, the description is complete enough: it names the data fields, explains how to obtain and use the id, and routes to the relevant sibling. No output schema exists, but the first sentence effectively enumerates the key return values.
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 input schema already documents the single listing_id parameter with a pattern and description, so schema coverage is 100%. The description's 'Takes the listing id from the listing URL' mostly restates the schema's 'part of a Duskly listing URL after /listing/,' adding little beyond the structured definition.
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 clearly states what the tool does: it returns the state of a Duskly listing, including photo counts, edit status, payment status, and render budget. It differentiates itself from the sibling duskly_get_listing_pack by positioning this as the precursor check for payment.
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?
The description explicitly says 'Use this before duskly_get_listing_pack to check whether a listing has been paid for,' giving concrete when-to-use guidance against at least one sibling. It does not cover all sibling alternatives or provide explicit when-not-to-use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything a paid listing returns: the download link for the archive, the disclosure wording for every edited photo, and the public page showing the originals.
Requires the listing to have been paid for. An unpaid listing returns the checkout URL instead, for a person to open.
The disclosure wording is generated per photo and per publishing surface. The duty to publish it falls on the licensee publishing the listing, not on the software.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | The listing id, the part of a Duskly listing URL after /listing/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real value beyond that: the paid prerequisite, the degraded unpaid response (a checkout URL for a human to open), and the fact that disclosure wording is generated per photo and per publishing surface. The licensee-obligation note is context rather than invocation guidance.
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 return payload, then the prerequisite, then a caveat — a sensible order with no padding. The final paragraph on publishing duty is somewhat tangential to calling the tool, keeping it short of a 5.
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 output schema, the description carries the burden of describing returns and does so by naming all three deliverables. Prerequisite and failure-mode behavior are both covered; only the exact shape/format of the returned artifacts is left unspecified.
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?
Only one parameter, listing_id, and schema description coverage is 100% with a pattern and a clear explanation of where the id comes from in a listing URL. The description adds nothing about the id beyond the schema, 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 and resource ('get the deliverables') and enumerates the three things returned: the archive download link, per-photo disclosure wording, and the public originals page. It implicitly separates itself from duskly_get_listing and duskly_get_checkout_url, though it never names those siblings 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?
Gives a clear precondition ('Requires the listing to have been paid for') and the alternative path when it isn't met ('An unpaid listing returns the checkout URL instead, for a person to open'). This is strong conditional routing, but it stops short of naming the sibling tool an agent should call instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duskly's price and what a paid listing returns. Use this when someone asks what it costs or what they get.
Editing is not available over MCP: renders spend model credit and require a browser session. Send the person to the URL in the response to do the work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the main burden is additional context. The description supplies that context by warning that editing requires a browser session and instructing the agent to send the user to the URL in the response. However, the phrase 'renders spend model credit' is grammatically unclear and weakens the disclosure.
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?
The definition is short and front-loads the core purpose in the first clause before the caveat and follow-up instruction. It loses one point because the second sentence mixes two ideas (credit spend and browser requirement) in an awkward colon construction.
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 read-only, zero-parameter tool with no output schema, the description explains the high-level return ('what a paid listing returns') and points to the URL in the response. It would be more complete with a clearer statement of what the response literally contains, but the essential agent behavior is covered.
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 has zero parameters, and the schema coverage is complete at 100%, so there is no parameter-meaning burden for the description to carry. It appropriately mentions no parameter details, matching the baseline for a no-parameter tool.
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 opens with the resource and return content: 'Duskly's price and what a paid listing returns' and adds a direct trigger: 'Use this when someone asks what it costs or what they get.' It does not name a sibling tool, but the stated scope is specific enough to separate it from checkout, listing, and edit tools.
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 gives an explicit invocation condition ('Use this when someone asks what it costs or what they get') and a clear process limitation ('Editing is not available over MCP... Send the person to the URL in the response'). It stops short of a full 5 because it never names alternatives or states when another sibling should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every edit Duskly performs, with what it does and how it is classified for disclosure.
Use this to pick the right edit for what someone is asking for, and to see in one call which ones carry compliance consequences.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds only a hint about compliance consequences, which is more about content than behavior. It does not contradict 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?
Two sentences, both informative and front-loaded: the first defines the scope, the second gives the use case. No filler or 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?
For a parameterless listing tool with no output schema, the description adequately conveys what the agent will receive: a list of edits with their descriptions and compliance classification. It could mention format details, but that is not essential for correct invocation.
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 has zero parameters, so schema coverage is trivially 100%. Baseline for 0 params is 4. The description adds no parameter details (since none exist) but does explain the output's purpose, which is sufficient.
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 ('lists') and resource ('every edit Duskly performs') along with the key attributes (what it does and compliance classification). It clearly distinguishes from siblings like duskly_classify_edit and duskly_generate_disclosure by focusing on enumeration rather than single-edit actions.
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 tells the agent when to use it: 'Use this to pick the right edit for what someone is asking for, and to see in one call which ones carry compliance consequences.' It does not name alternatives or state when not to use it, but the intended scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edits that are prohibited outright in one or more markets and are never made acceptable by adding a disclosure.
Use this when someone asks to remove, conceal or change something in a property photo and you need to know whether a label would make it acceptable. For these, it does not.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description doesn't need to cover safety. It adds that it returns a list of prohibited edits, which is useful context, but it doesn't detail the output structure or any edge cases. Given the annotation coverage, a 3 is appropriate for the incremental behavioral context provided.
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?
The description is two sentences long, with the core definition in the first sentence and usage guidance in the second. Every sentence carries essential information, and it is front-loaded with the most important fact (what the tool lists). No redundancy or unnecessary detail.
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 parameters, no output schema, and safety annotations already provided, the description covers everything an agent needs: what the tool returns (a list of prohibited alterations) and when to call it. It is complete for the tool's simplicity.
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 has zero parameters, so the schema is empty and fully covers the parameter surface. The description acknowledges this by not referencing any inputs. According to the calibration baseline for 0-parameter tools, a 4 is justified.
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 and resource: it lists prohibited alterations that cannot be made acceptable by disclosure. It also clarifies the context by tying it to property photo edits and the 'label' concept. This clearly distinguishes it from sibling tools like duskly_list_edits or duskly_classify_edit.
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?
The description explicitly says when to use the tool: when someone asks about removing, concealing, or changing something and you need to know if a disclosure would make it acceptable. It lacks an explicit mention of alternatives, but the phrase 'For these, it does not' implies that other edits may be acceptable with disclosure, effectively routing the agent to this tool only for the prohibited set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the URL a person should open to upload listing photos and run an edit themselves.
Use this when someone wants an edit performed. Editing is deliberately not callable over MCP: a render spends model credit and is gated behind a browser check that an automated client cannot pass. Hand the person the link rather than attempting the edit.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Preselects the edit on the page, when known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description explains why this tool exists: a render spends model credit and is gated behind a browser check that an automated client cannot pass. This is valuable behavioral context that the annotations alone do not convey.
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 sentences, each earning its place: the first states the core output, the second gives the usage condition, and the third explains why automation cannot replace the link. The key information is front-loaded and there is no redundant filler.
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 a single optional parameter, annotations covering safety, and a clear description of the returned URL and its purpose, nothing essential is missing. The description also anticipates the likely failure mode—an agent trying to perform the edit itself—and addresses it directly.
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 input schema already documents the only parameter, task, with a clear description and enum values, giving 100% schema coverage. The tool description adds high-level context about the edit workflow but does not need to explain parameter semantics further because the schema already does so.
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 and resource: 'Returns the URL a person should open to upload listing photos and run an edit themselves.' It clearly distinguishes this from actually performing the edit, which is the core purpose of the tool. This prevents an agent from confusing it with editing-capable or checkout-related siblings.
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?
The description explicitly says 'Use this when someone wants an edit performed' and explains that editing is deliberately not callable over MCP. It also instructs the agent to 'Hand the person the link rather than attempting the edit,' providing both when-to-use and when-not-to-attempt guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect an image for provenance signals: an invisible Duskly watermark, IPTC digital source type metadata, and whether a C2PA container appears present.
Works on images Duskly did not produce.
Read the result carefully before repeating it. This is a limited inspection report, not a certificate of authenticity or compliance. The absence of a mark is not evidence that an image is a camera capture — most AI editors write nothing at all, and Duskly's own paid downloads are deliberately unmarked. The C2PA field reports only that a container appears present: manifests are not parsed, signatures are not validated, and Duskly does not sign them.
Prefer repeating the summary lines over paraphrasing individual fields.
| Name | Required | Description | Default |
|---|---|---|---|
| image_base64 | Yes | Base64-encoded JPEG or PNG, up to 8MB decoded. A data: URL prefix is accepted and stripped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses significant behavioral nuances: the report is 'limited' and 'not a certificate of authenticity', absence of a mark is not evidence of camera capture, and the C2PA field only reports container presence without parsing or validation. It also advises careful reading and repetition of summary lines. This richly informs the agent about the tool's limitations and correct interpretation.
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?
The description is well-structured: it opens with a clear purpose, adds a scope constraint, then presents crucial caveats in bold for emphasis, and ends with a usage tip. Every sentence contributes essential information—no fluff. It is appropriately sized for the complexity of the tool.
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?
Without an output schema, the description does a strong job conveying what the tool reports (watermark, IPTC, C2PA presence) and how to interpret it. It mentions 'summary lines' implying a structured output, but does not enumerate the exact fields. For a read-only inspection tool, this is nearly complete; a small gap remains regarding the precise return structure.
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 input schema fully describes image_base64 (base64 JPEG/PNG, up to 8MB, data URL accepted) with 100% coverage. The description adds no additional parameter-specific details, but the schema alone is sufficient. As per the calibration baseline for high schema coverage, a 3 is appropriate.
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 ('Inspect') and resource ('an image'), and enumerates three concrete provenance signals (Duskly watermark, IPTC digital source type, C2PA container presence). It also clarifies the tool operates on images Duskly did not produce, which distinguishes it from related generation tools. This makes the purpose unambiguous and easily differentiable from sibling tools.
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?
The description gives a usage constraint ('Works on images Duskly did not produce') but does not explicitly contrast with sibling tools or state when to choose this over alternatives. It implies the tool is for verification, not classification or generation, but lacks explicit exclusions or references to alternatives. This is adequate but not fully explicit.
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.
duskly_classify_editduskly_generate_disclosureduskly_get_checkout_urlduskly_get_listingduskly_get_listing_packduskly_get_pricingduskly_list_editsduskly_list_prohibited_alterationsduskly_start_listingduskly_verify_imageMLS-ready, Fair-Housing-safe property listing descriptions (en/ko/es) and wording checks.
Enhance, virtually stage and turn real estate listing photos into video with AI.
Every visual AI tool for property listings — staging, enhancement, decluttering, cinematic video.
Edit images over MCP with object removal, background removal, and guided generative edits.
Add one secure layer between your agents and this server.
