MLS compliance for edited listing photos: classify edits, write disclosures, verify provenance.
Scored across 10 tools
Most tools have clear, distinct roles, but there is minor overlap: get_checkout_url duplicates the unpaid fallback in get_listing_pack, and classify_edit overlaps with list_prohibited_alterations on prohibition checks. The descriptions are detailed enough that a careful agent can usually pick correctly.
All tools share the duskly_ prefix and follow a predictable verb_noun snake_case pattern such as get_listing, generate_disclosure, list_edits, and verify_image. The get_ vs list_ vs start_ verbs are used consistently and make the tool roles easy to infer.
Ten tools is well-scoped for this server's combined domain of listing lifecycle management and photo-edit compliance. Each tool serves a distinct workflow step and none feel like filler or redundant additions.
The core workflow is well covered: starting a listing, checking status, obtaining payment, retrieving the paid deliverables, generating disclosures, and verifying image provenance. Minor gaps exist, such as no listing cancellation or update tool and no direct jurisdiction rulebook lookup, but these do not create dead ends for the primary use cases.
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" (no rulebook names it explicitly; 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 indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral context: classifications, the meaning of 'prohibited' as location-specific, the direct-rulebook sourcing, and the instruction to read carve_out when present.
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 moderately long but each sentence adds information about classification semantics or usage. The most important usage guidance is near the front, and the classification list is structured clearly.
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, no-output-schema tool, the description covers return substance, classification values, and an important caveat about 'prohibited'. It does not define 'exempt' or the response shape, but these are minor gaps given the classification list.
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 only parameter is an enum with descriptions. The tool description does not add further parameter-level detail, so the baseline of 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 clearly identifies the tool's job: classifying whether an edit must be disclosed and whether any market prohibits it. It is distinct from sibling tools in intent, though it does not explicitly contrast with duskly_generate_disclosure or duskly_list_prohibited_alterations.
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 a clear trigger condition: use this before telling someone an edit is safe to publish. It does not explicitly name alternatives or exclusions, but the use case is specific enough to guide selection.
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 unaltered 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 read-only, idempotent, and non-destructive. The description adds meaningful behavioral nuance: the paid/unpaid behavior, the per-photo and per-surface disclosure generation, and the legal duty of the licensee. It also clarifies the output contents beyond what annotations imply, without contradicting them.
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 concise and front-loaded: it starts with 'Everything a paid listing returns' and lists the three key components. It adds necessary condition and behavior without fluff. The note about duty is slightly extra but relevant. Overall, every sentence contributes.
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?
Given it has one parameter, no output schema, and clear annotations, the description covers what the tool returns, the required condition, and the behavior for unsatisfied condition. It also mentions the disclosure responsibility, which is important context. Nothing essential is missing for an agent to call it correctly.
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 only one parameter (listing_id), and the schema provides a clear description with pattern and example. The description does not add extra parameter details, but with 100% schema coverage, the baseline of 3 is appropriate since the tool description doesn't need to compensate.
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 clear verb ('get') and resource ('listing pack'), and explicitly enumerates what it returns: download link, disclosure wording, and public page. It distinguishes itself from siblings like duskly_get_checkout_url and duskly_generate_disclosure by clarifying it bundles the full set of deliverables for a paid listing.
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 clear precondition ('Requires the listing to have been paid for') and explains the fallback behavior for unpaid listings (returns checkout URL). While it doesn't explicitly name alternatives, it conveys when this tool is appropriate and what happens otherwise, which is sufficient guidance for an agent to decide.
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_imageEvery visual AI tool for property listings — staging, enhancement, decluttering, cinematic video.
Edit images over MCP with object removal, background removal, and guided generative edits.
Washington property evidence and transaction math for software and AI assistants.
AI virtual staging for real estate — stage rooms, beautify floor plans, classify images.
Add one secure layer between your agents and this server.
