Dreep MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and a closed-world profile, so the safety story is covered. The description adds genuine context beyond that: transforms run on the fly at the CDN and are cached, which tells the agent the result is a derived, reproducible URL. It stops short of saying whether the URL is permanent, how transform errors surface, or that the underlying asset is never mutated.

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 short sentences, front-loaded with the core verb and resource, then the CDN/caching behavior, then two compact examples. Nothing is redundant and the reading order matches what an agent needs first.

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 100% documented schema and an output schema present, return values need no explanation, and the description covers what the tool does and how transforms behave. The one real gap is disambiguation from build_signed_url, which the description leaves entirely unaddressed.

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 description coverage is 100% and every transform field is documented inline, so the baseline of 3 applies. The description only illustrates parameter combinations (width 400 + format webp, format pdf for a Word doc) rather than adding semantics the schema lacks, such as how url must match exactly or what preset does relative to explicit fields.

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?

Uses a specific verb and resource ("Builds a delivery URL") and enumerates the transform capabilities (resize, crop, convert, transform). It is clear what the tool produces, but it never distinguishes itself from the sibling build_signed_url, which an agent could easily confuse with a delivery-URL builder.

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 through examples ("width 400 and format webp for a thumbnail; format pdf to convert a Word document"), which do convey intent but not exclusions. There is no statement about when to use this versus build_signed_url, convert_document, or create_preset, all of which sit in the sibling list and are natural alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, but the description adds genuinely non-derivable behavior: it depends on the DREEP_SIGNING_SECRET server secret and the resulting URL is a bearer credential that anyone can use until expiry. That last point materially affects how an agent should handle the output. It stops short of saying what happens when the secret is missing or whether the signed URL embeds the transform.

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 short sentences with zero filler: the operation first, then the precondition, then the security consequence. Nothing is repeated from the schema or annotations.

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 full output schema, complete parameter coverage and annotations covering safety, the description only needs to supply the operational and security context, which it does. The remaining gap is the lack of explicit differentiation from build_delivery_url and create_upload_url among nine siblings.

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 description coverage is 100%, so the baseline is 3 per the rubric. The description adds no meaning about the four parameters, notably why both 'url' and 'asset_id' are required and which one actually gets signed, which is the main ambiguity an agent would face.

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 builds a time-limited (signed) URL for an asset, and it scopes that to assets in a signed folder. That distinguishes it from the unsigned sibling build_delivery_url in substance, but the sibling is never named, so the agent must infer the contrast.

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 is implied by the 'signed folder' qualifier and the warning about sharing, so an agent can infer this is for private assets. There is no explicit when-not guidance and no named alternative such as build_delivery_url for public assets, leaving the routing decision to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description builds on top by explaining the conflict error's meaning and the correct retry target — behavior an agent cannot infer from the schema. It stops short of saying whether a second confirm on an already-confirmed upload is a no-op, which matters given idempotentHint=false.

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 load-bearing: the first defines the operation and its return, the second handles the single most likely failure mode. Nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the description still names the return ('returns the asset'), and the error path is covered, so an agent has what it needs to call and retry correctly. The one gap is the absence of any note on repeated confirmation behavior for a non-idempotent mutation 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?

Schema description coverage is 100%, so upload_id, transform, and preset_key are fully documented in the schema, including that the transform 'runs before storage' and that preset_key is an alternative to transform. The description adds no parameter-level meaning 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?

States a specific verb ('Finalises') and resource ('a presigned upload'), and ties itself into the workflow by naming the prerequisite state ('once its bytes are in storage'). This distinguishes it from create_upload_url (which mints the URL) and from the raw PUT, without the agent needing to guess.

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 states when to call it (after bytes land in storage) and gives concrete error-recovery guidance ('a conflict error means the bytes haven't landed yet: retry this call, not the PUT'). It does not contrast itself with sibling upload_file, which is the main remaining ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=false, destructive=false, openWorld=true, and idempotent=false. The description adds real value beyond that: it discloses that output is persisted as a new asset, and it explains the asynchronous behavior where `status` is 'processing' and the `url` returns 202 until conversion completes — a non-obvious operational detail. It stops short of noting that repeated calls create duplicate assets despite a read-modify shape.

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 short sentences, front-loaded with the core action and examples, with no filler. The stray line breaks and parenthetical ellipsis make it slightly less polished but the content is efficient.

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 9-parameter conversion tool with a required `format`, full schema coverage, and an output schema, the description covers purpose and the key async status behavior. The source-selection logic (key vs path vs content_base64) is left entirely to the schema, but since the schema documents it precisely, the definition is adequate.

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 description coverage is 100%, so the input parameters are already fully documented and the description adds no input-parameter semantics. It does mention the output fields `status` and `url`, but the tool has an output schema, so this is supplementary rather than compensating for a gap. 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 names a specific verb and resource ('Converts a document') and illustrates it with concrete conversions (Word to PDF, PDF to Word, PDF page to image), so the agent immediately understands the operation. It doesn't distinguish itself from siblings like extract_text or upload_file, which is the only thing keeping it from a 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?

Usage is implied by the conversion examples, so an agent can infer this is the tool for format transformation. However, there is no explicit when-to-use versus upload_file (plain storage) or extract_text (text extraction), and no statement of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds genuinely new behavioral facts: access control is only settable at the top level, nested folders inherit it, and folders cannot be deleted via the API. It does not address the non-idempotent hint, i.e. what happens when the same folder name or path is created twice.

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?

Four short sentences, purpose front-loaded, with the caveats following in descending order of importance. Every sentence carries information; the stray line breaks are the only cosmetic flaw.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the annotations carry the safety profile. The description supplies the operationally important constraints for a mutation tool. Remaining gaps are duplicate-creation behavior and which of the mutually exclusive location parameters to choose.

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, and the description does add one useful constraint tying parameters together: access_control_type only applies to a folder created by name with no parent. However, it never explains the selection logic among the six optional parameters — name vs. path, parent_id vs. parent_path — which is the most consequential semantic question for this 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 first sentence gives a specific verb and resource ('Creates a folder'), and the second sentence carves out a boundary against the upload flow ('Uploads create folders on demand'), which implicitly separates it from upload_file. What keeps it from a 5 is that 'mainly for setting access control' narrows the stated purpose in a way that could make an agent think plain folder creation is not the intended use.

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 states a concrete when-to-use case (pre-creating a top-level folder so access control exists before content lands) and effectively a when-not-needed case (uploads auto-create folders). It does not cover edge cases such as what to do if the folder already exists or how this interacts with list_folders to check first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true. The description usefully adds how the created key is consumed elsewhere, but it does not say what happens on a duplicate key (relevant given idempotentHint=false), whether an existing preset is overwritten, or what errors to 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?

A single well-formed sentence with the action front-loaded and no filler. The trailing clause is slightly terse and takes a second read, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the nested transform fields are fully documented in the schema. Still, for a non-idempotent create tool the description omits key-uniqueness/overwrite behavior and any mention of the sibling preset-listing 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?

Schema description coverage is 100%, including the note that `transform` must include `format`, so the schema carries most of the burden. The description does add meaning for `key` by showing it is the reference value used as `preset: key` elsewhere, which is a modest but real contribution above the schema's pattern note.

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 ('Saves a named transform') and clarifies what a saved preset is for. It does not name the sibling `list_presets` or otherwise differentiate from related tools, so it stops short of a 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?

The phrase 'applied anywhere with transform `preset`: key' implies the use case (define once, reuse by key), but there is no explicit when-to-use guidance and no mention of `list_presets` as the alternative for inspecting existing presets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description discloses important behavior: the upload URL is valid for about ten minutes, the PUT must match Content-Type and Content-Length exactly, and already_exists allows skipping the PUT. It also names the required follow-up tool and returned id. With annotations already covering safety and openness, this adds substantial operational context.

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 purpose, then gives a compact procedural sequence and an edge-case rule. Every sentence carries operational value with no redundant restatement of structured fields. It is appropriately sized for the workflow.

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 eight parameters, an output schema, and annotations, the description covers the essential workflow: create URL, PUT bytes, handle already_exists, then confirm. The output schema removes the need to explain return values. A minor gap is not naming the upload_file sibling as the alternative path.

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 description coverage is 100%, so parameter documentation is already strong. The description reinforces that content_type and size_bytes must be used exactly as Content-Type and Content-Length during the PUT, but it does not add meaning for the other six parameters beyond what the schema provides. Baseline 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 and resource: 'Starts a direct-to-storage upload'. It also scopes the use case to 'bytes this server can't read', which helps distinguish it from server-read upload paths. However, it does not explicitly name or differentiate from the sibling upload_file tool, so it falls short of full sibling clarity.

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 clear when-to-use context ('bytes this server can't read') and a concrete follow-up procedure: PUT with exact headers, then call confirm_upload. It also handles the already_exists shortcut. It does not explicitly state when to use upload_file instead, so alternatives are implied rather than named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description frames the tool as a pure read ("returns the extracted text") while the annotations declare readOnlyHint=false and the schema shows it can write a .txt asset into a folder — a side effect the description never mentions. No annotation contradiction exists, but for a tool with a non-read-only side effect the description should disclose that it can create files, and it does not.

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 that names the operation, the accepted input types, and the primary return value with zero filler. Nothing needs to be trimmed.

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 seven parameters, zero required fields, and an output schema (which removes the need to describe return values), the definition should still state that an agent must supply either `path` or `content_base64`. As written, an agent could plausibly call with no arguments, and the optional asset-storing side effect is never mentioned.

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 description coverage is 100%, so every one of the seven parameters is already documented in the schema, including the path-vs-content_base64 exclusivity and the 20 MB cap. The description adds no parameter meaning at all, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Runs OCR on an image or PDF") and the return payload (`text`), which is enough to tell it apart from most siblings such as upload_file or remove_background. It never explicitly contrasts itself with the closest sibling, convert_document, which could also be read as extracting 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 gives no when-to-use, when-not-to-use, or alternative-tool guidance; the choice between extract_text and convert_document is left entirely to inference. The only selection constraint in the definition ("Give this or content_base64, not both") lives in the schema, not the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the payload covers storage and counts, but leaves open which project is measured (no parameters are accepted, so it must come from credentials or server config) and whether the numbers are live or cached — both material for interpreting results.

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?

A single front-loaded sentence naming the resources returned, with zero filler or redundant restatement of the tool name.

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 and an output schema present, return values do not need explaining. The only real gap is the implicit project scoping and data freshness, which the low-complexity shape of the tool makes a minor omission rather than a blocking one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly signals that the result is implicitly scoped rather than parameterized.

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 names the specific resource and return content: storage consumed plus image, file and folder counts. No sibling tool returns usage metrics, so it is distinguishable by resource alone, though the verb is only implied by the name rather than stated in the description.

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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to any alternative or related tool among the many siblings. An agent must infer that this is a reporting/monitoring call from the word 'consumed' alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results include full paths and access-control data, and an unfiltered call returns every folder at any depth — an important signal that the default result set can be very large. It stops short of mentioning pagination or size limits.

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, zero filler, with the most decision-relevant fact (unfiltered = everything at any depth) placed where it will be read. Nothing is repeated from the schema or annotations.

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 an output schema present, the description needn't explain return values, and annotations cover safety, so what remains is query semantics — which it handles for the default case. The only gap is guidance on scoping large listings (pagination or filter selection) for a tool that can return an unbounded tree.

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 description coverage is 100%, so each parameter (path, parent_id, root_only) is already documented in the schema, including their defaults. The description only alludes to the notion of a filter without adding precedence rules or format details, so 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 gives a specific verb and resource ("Lists folders") and adds the returned payload shape ("full paths and access control"), which distinguishes it from siblings like list_media and list_presets. It does not name those siblings explicitly, so it falls short of a 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?

The second sentence implies usage context by explaining that no filter returns everything at any depth, hinting at a narrow-vs-broad query choice. However, it never states when to prefer this over list_media or when to apply path/parent_id/root_only, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint. The description adds real behavioral context beyond that: results are sorted newest first, `pagination.total` reflects the full count across pages (not just the current page), and no text-search capability exists. It does not discuss rate limits or behavior when a folder slug does not exist, but the added context is substantive.

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 short lines, with the result ordering and pagination fact front-loaded before the field list and the no-search caveat. Every sentence carries information an agent needs; nothing is padding.

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?

The tool has an output schema, so enumerating asset fields is a minor redundancy, and it is otherwise complete: ordering, pagination total semantics, and the absence of search are all covered. The only gap is how folder filtering interacts with paging and recursive, which the schema covers at a basic level.

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 description coverage is 100%, so page, limit, folder, folder_id and recursive are all documented in the schema. The description only hints at folder filtering via "filter by filename or folder" and does not clarify the folder vs folder_id or recursive distinctions. Baseline 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 names a specific verb and resource ("Lists ready assets"), adds ordering ("newest first") and pagination semantics ("`pagination.total` across all pages"). The resource is clearly distinct from siblings like list_folders and list_presets, though no sibling is named 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?

It gives actionable guidance for the retrieval task: "There is no text search: page through and filter by filename or folder." That tells an agent how to use the tool rather than what alternatives exist; it does not mention list_folders or folder_id vs folder slug selection, so it stops short of a full when/when-not statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered structurally. The description adds a small amount of behavior by implying the result set is complete rather than filtered or paginated ('every saved preset'), but does not discuss ordering, volume, or failure modes.

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 short sentence, front-loaded with the verb and resource, with the return fields appended as useful detail. Nothing is redundant or padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the field enumeration in the description is not strictly required, and annotations cover read-only semantics. For a zero-argument list tool the description is complete enough to call correctly; only ordering or size expectations are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool 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 ('Lists every saved preset') and even enumerates the returned fields, so the operation is unmistakable. It does not explicitly contrast with the neighbouring create_preset sibling, but the verb 'list' versus 'create' makes the distinction obvious enough.

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?

No when-to-use or when-not-to-use guidance is given, and no alternatives are named. Usage is only implied by the verb 'Lists' and the zero-argument schema, which is sufficient for such a simple read tool but leaves no explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds useful context that the operation persists a new stored asset with an alpha channel rather than returning an inline result, plus how to later display it. It does not discuss overwrite behaviour on name collisions despite idempotentHint=false.

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 short sentences, front-loaded with the core action and effect, with no filler. The second sentence is slightly cryptic — it references a `bg` transform and a bare hex value without naming the tool that applies it — but it earns its place as actionable follow-up guidance.

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 seven fully described parameters and an output schema present, the description does not need to explain return values, and it correctly covers the essential action and storage side effect. Gaps are minor: it says nothing about source image limitations or what happens when the destination filename already exists.

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 description coverage is 100%, so all seven parameters (path, content_base64, folder, folder_id, format, filename, auto_create_folders) are already documented in the schema, including the mutual exclusivity of source options. The description contributes nothing additional about parameters; the colour hex in the example relates to a delivery transform, not an input. 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 ('cuts the subject out of an image') plus the effect ('stores the transparent cutout'), which is clearly distinct from siblings like upload_file, convert_document, or extract_text. It never names an alternative tool directly, so sibling differentiation is implicit rather than stated.

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 implies the use case (isolating a subject from an image) and gives a follow-up hint about rendering the cutout over a colour via a `bg` transform, which implicitly points at build_delivery_url. However, it gives no explicit when-to-use/when-not guidance and does not name that sibling or any alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds genuinely non-obvious behavior: the 100 MB presigned streaming path, and that a transform runs before storage and replaces the original rather than producing a separate derived asset. It stops short of stating auth requirements or failure modes, so a 4 rather than 5.

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 short sentences, front-loaded with what the tool does and what it returns, followed by the two operationally important caveats. No filler or restated field names.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the brief mention of the `url` field is sufficient and return values need no further explanation. For a 10-parameter upload tool the description covers the important behavioral surprises, though it leaves the routing question against the presigned-upload siblings unanswered.

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 description coverage is 100%, so the baseline is 3; every parameter, including the full TransformInput object, is already documented inline. The description adds only the timing semantics of `transform` (applied before storage, replacing the original), which is useful but narrow.

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 ('Uploads an image, video, audio file or document to Dreep') and names the outcome ('returns the asset'). It does not, however, distinguish itself from siblings like create_upload_url and confirm_upload, which appear to implement the two-step presigned flow this tool is adjacent to.

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 note that files over 100 MB stream through a presigned upload implies this tool handles large files directly, but there is no explicit when-to-use/when-not guidance versus create_upload_url + confirm_upload. The choice between inline base64 and this tool is only documented in the schema, not in the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.