postcache

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful trait, that nothing is stored/uploaded, which reassures the agent this is a non-mutating check, but it says nothing about auth requirements, rate limits, or whether the target file is fetched or uploaded.

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 compact sentences with zero filler, front-loading the core action and scope before the conditional convert 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 6-parameter tool with no output schema and no annotations, the description leaves notable gaps: it never states the result shape (pass/fail detail), how the file is supplied (mutual exclusivity of source_url vs data_base64), or what filename is for. The ttl-on-a-check-tool oddity is also unexplained.

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 83%, giving a baseline of 3, and the description adds genuine meaning for the convert parameter by explaining that it reports whether cropping or padding can fix the file. It doesn't clarify the relationship between source_url and data_base64 or the ttl field, but it does go beyond the schema for the key behavioral param.

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?

Specific verb ('check a file') plus resource (a file against a target platform), and 'without storing it' cleanly distinguishes it from the upload_media sibling. It stops short of naming alternatives, but the purpose is 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?

Usage is only implied: validating without persisting suggests a pre-upload check, and the mention of convert hints at a second use case. There is no explicit when-to-use/when-not or prerequisite 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?

No annotations are provided, so the description carries the full burden for a destructive operation. 'Now' implies immediacy, but the description never says the deletion is irreversible, what permissions are needed, or whether a still-referenced file would break existing posts.

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 short sentence with the action front-loaded and no filler. It is efficient, though the parenthetical timing note is doing double duty as usage 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?

For a destructive, annotation-free tool with an undocumented required parameter and no output schema, the description is far too thin. It omits irreversibility, auth requirements, failure modes, and what the caller receives on success.

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 one required parameter (id) with 0% schema description coverage, and the description never mentions it. 'An uploaded file' only loosely implies that the id identifies the media, leaving the agent to infer accepted formats.

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 (Delete) and resource (an uploaded file), which cleanly separates it from the check/get/upload siblings. It stops short of naming 'media' to match the tool name, but the intent is 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?

The parenthetical 'call after the post is published' hints at sequencing, but the description never states prerequisites, what happens if called too early, or why check_media/get_media are not the right siblings. Usage is implied rather than fully specified.

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?

With no annotations, the description carries the full behavioral burden; it does useful work by disclosing the possible status values (converting, ready, failed) and the accompanying fields, which hints at read-only polling behavior. However, it never states that the call is non-mutating, what happens for an unknown/expired id, or how errors surface.

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?

It is a single short fragment with no filler, so it is not bloated, but it is a noun phrase describing outputs rather than a front-loaded statement of action. There is no wasted text yet also no structural cue about what the tool does.

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 lookup tool with no output schema, no annotations, and an undocumented required parameter, the description should at minimum state that it fetches a file's metadata by id. Instead it only lists return fields, leaving action, input meaning, and failure behavior uncovered alongside three sibling tools it never disambiguates from.

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 schema has one required parameter at 0% description coverage, so the description must compensate and does not: the word 'id' never appears and the identifier's origin, type, or format is left entirely implicit. Only the phrase 'of an uploaded file' loosely ties the input to a media identifier.

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 resource (an uploaded file) and enumerates the fields it exposes (status, URL, expiry, fetch count), which implies retrieval, but it never states a verb or that it looks up a single file by identifier. It also gives no differentiation from the sibling check_media, which sounds like it could return status too.

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 prerequisites, and no mention of the alternatives (check_media, upload_media, delete_media). The agent must guess whether get_media or check_media is the right call for checking an upload's status.

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?

No annotations are provided, so the description carries the full burden and does so well: it discloses the return contract (public URL or problems with fixes), the async 'converting'/'ready'/'failed' status machine, and the eventual cleanup requirement via delete_media. It omits auth/permission requirements and failure modes for uploads themselves, which keeps it from a 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?

Four dense sentences, front-loaded with purpose, then return value, then the conditional convert/poll branch, then the next-step pointer to delete_media. Every sentence earns its place with no restatement of the name or schema.

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

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

With no output schema and no annotations, the description must carry the return contract, and it does: URL vs. problems-with-fixes, plus the status lifecycle. It is complete enough to drive the tool and its follow-up calls, though it leaves auth requirements and the shape of the 'problems' response implicit.

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 83%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining what convert actually does behaviorally (fixes rule failures by cropping/padding, triggers the 'converting' status and requires polling). It says nothing extra about source_url vs data_base64 tradeoffs or ttl, which the schema already covers.

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 ('Upload an image or video for a social platform') and immediately distinguishes itself from siblings by naming get_media and delete_media in the lifecycle. The agent can tell this is the entry point of the media pipeline without opening a schema.

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 clear workflow context: use convert when a file fails platform rules, poll get_media while status is 'converting', then call delete_media after handing the URL to the platform API. It does not explain when to prefer check_media or when this tool should be avoided, so it stops short of full when/when-not guidance.

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