FramePond

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value by naming the distinct data domains returned (credits, costs, permissions), which is more than the annotations convey — though it says nothing about freshness or propagation of quota data.

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 with the verb first and no filler. Every item in the enumeration corresponds to a real output the agent needs.

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 must carry the return-value burden, and it does list the categories of information returned. It stops short of describing response shape or units (e.g. credit vs. currency), which is a minor gap for an info 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate at the parameter level.

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 ('Check') and enumerates the exact resources returned: subscription, shared prompt unlock allowance, image credits, image costs, and connection permissions. No sibling tool covers account status, and the scope 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 — an agent can infer this is the tool to call to inspect account state before spending credits, but the description never states when to use it or names alternatives. No exclusions or prerequisites are given.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious context — running jobs keep their references until completion — but says nothing about permanence/irreversibility or behavior on a missing or non-owned id.

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 tight sentences with the core action front-loaded and no filler. Nothing is padded, though the second sentence would land better if the first established the parameter.

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 one-parameter destructive delete with rich annotations and no output schema, the description covers the action and the one surprising side effect. Only minor gaps remain around the id format and failure modes.

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 0% and the single `id` parameter is never mentioned in the description. The required `ref_[a-f0-9-]{36}` format and the "owned" restriction (which implies a permission boundary on the id) are left entirely undocumented.

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: "Delete an owned reference from FramePond." That is clearly distinguishable from the upload/list siblings. It stops short of naming the complementary tool (prepare_reference_upload) or the listing tool, so no explicit sibling differentiation.

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 guidance on when to call this versus alternatives, no prerequisites (ownership/auth), and no note about what to do if the reference is in use. The only adjacent hint is the running-jobs note, which is behavioral rather than usage 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?

Beyond the readOnly/idempotent annotations, it discloses two non-obvious behaviors: the URL is private and expires in five minutes. The instruction not to publish the URL is a useful confidentiality constraint. It omits what happens on an expired or invalid id.

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 the core behavior front-loaded and the follow-up action second; no 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 no output schema, the description correctly covers the return value (a time-limited private URL) and caller obligations. However, for a single-parameter tool with zero schema documentation, leaving the meaning and source of 'id' unspecified is a material gap on the critical path to a correct call.

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 with 0% schema description coverage, and the description never explains what 'id' is or where it comes from (presumably an fp_ file id from generate_image or get_image_job). The phrase 'the user's requested local path' refers to a separate step, not to schema parameters, so it doesn't 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 gives a concrete verb and resource ('Get a private download URL') and resolves the name/behavior mismatch by explaining that the tool returns a link rather than bytes. It stops short of differentiating itself from siblings like get_image_job, which may also surface URLs.

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 the next step explicitly ('Download bytes to the user's requested local path using your file tools') and an exclusion ('do not publish the URL'), which is real operational guidance. It doesn't say when to prefer this over get_image_job or how to obtain the id 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 this as a destructive, open-world, idempotent, non-read-only operation. The description adds useful billing and retry context ('existing subscription,' 'maximum credit cost,' reuse requestId), but it does not explain the destructiveHint or clarify whether generation is synchronous or asynchronous.

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, front-loaded with the core action and followed by critical invocation constraints. There is no filler, and the retry warning is placed where an agent will see it before calling.

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 complex 7-parameter image-generation tool with no output schema and no schema descriptions, the description is missing too much: most parameters are unexplained, the asynchronous job relationship is not stated, and expected return or job-tracking behavior is absent.

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?

With 0% schema description coverage across 7 parameters, the description must carry parameter meaning. It only explains requestId and maxCredits in any detail, leaving prompt, ratio, resolution, sourceId, and referenceIds undocumented beyond their types and enums.

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: 'Generate one image.' It also scopes the operation to an 'existing subscription.' However, it does not explicitly differentiate this tool from siblings such as get_image_job or list_image_jobs, 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 description gives important retry guidance for requestId after network errors and warns against resubmitting unknown jobs with a new ID. It does not explain when to use this tool versus get_image_job, list_image_jobs, or other sibling tools, leaving usage context largely implied.

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, idempotent, non-destructive, so the safety profile is covered. The description adds what annotations cannot: account-ownership scoping, the fact that refresh does not re-trigger work, and a 15-second polling floor.

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, no filler, and the core operation is stated first followed by the polling constraint. Every clause carries information an agent would otherwise have to guess.

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 simple single-record read this covers purpose and refresh behavior, but with no output schema the description does not hint at what a job record or status looks like, nor what happens for an unknown or unfinished job. Adequate, with clear gaps.

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 0%, so the description must carry the parameter burden. It conveys meaningful semantics for refresh (checks the existing task only) but says nothing about the id parameter beyond the schema's regex pattern, leaving half the surface implicit.

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 ("Read a job") and adds an ownership scope ("owned by this account"). It is clearly distinguishable from list_image_jobs by being singular, though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real operational context: refresh only re-checks the existing task and polling should be spaced at least 15 seconds apart. It does not say when to prefer list_image_jobs or what to do when the job is still pending, so no explicit alternatives 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 cover read-only, idempotent, non-destructive safety, but 'Does not spend credits' adds a cost/destructive-side-effect distinction that annotations cannot express. It also discloses the conditional return shape (full prompt withheld unless unlocked), which is meaningful behavioral 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?

Two short sentences with zero filler, and the key scoping/cost facts are front-loaded. Nothing could be removed without losing meaning.

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 does outline the returned fields, which is good. But it is ambiguous about what happens when the prompt is locked (error vs. preview-only response), and it says nothing about the 'lang' parameter, leaving a real gap for a 2-param read 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 0% for two parameters, and the description mentions neither 'id' nor 'lang'. The id pattern and the en/zh language default are left entirely to the schema, and the description adds no guidance on which language variant is used or what makes an id valid.

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 (Read) and the exact payload returned: preview, source/license, and full prompt. The gating clause 'only if already unlocked' implicitly distinguishes it from unlock_prompt and list_unlocked_prompts, but no sibling is named outright.

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?

'Only if already unlocked' and 'Does not spend credits' give a clear positive condition and clearly contrast with the credit-spending unlock_prompt path. It stops short of explicitly naming unlock_prompt or stating what to do when the prompt is locked.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds that results mirror the website's generation history, a mildly useful scoping note, but says nothing about page size, ordering, or how the returned history is bounded.

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 with the verb and resource up front, so it is not bloated. The only questionable content is 'shared with the website,' which is vague but brief.

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?

There is no output schema, so the description should convey what a listing returns — job identifiers, statuses, ordering, page boundaries — and it conveys none of that. For a paginated history-listing tool, the omission of any paging or result-shape information leaves an agent under-informed.

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 0% for the single cursor parameter, and the description never mentions paging at all. An agent cannot tell from either source what cursor values look like or how to advance through the history, so the description fails to compensate for the coverage gap.

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 (List) and resource (the account's generation history), which an agent can map onto the tool name list_image_jobs. The sibling set includes get_image_job, and the list-vs-get contrast is implicit but inferable. The trailing clause 'shared with the website' blurs rather than sharpens the purpose.

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 guidance on when to call this instead of get_image_job for a single job, nor any prerequisites. Usage is only implied by the word 'List' — nothing addresses pagination or how to enumerate a long history.

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 destructiveHint=false, so the safety profile is covered by structured data. The description adds only the account-scoping constraint; it says nothing about ordering, pagination, or whether the list is bounded, which is the kind of context annotations cannot 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?

A single front-loaded sentence with no filler. It is efficient, though the brevity comes partly from omitting information an agent would need rather than from disciplined editing.

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 should ideally indicate what a list entry contains and how paging works. Instead it leaves both undocumented, though the read-only, non-destructive nature of the call is fully covered by annotations, keeping the risk of misuse low.

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 0%: both `lang` (enum en/zh, default en) and `offset` (0-100000, default 0) are undocumented in the schema, and the description mentions neither. The presence of `offset` strongly implies pagination, yet the description does not confirm it or explain `lang`'s effect on results, so it fails to compensate for the coverage gap.

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 ("List ... prompts") and narrows the scope to "this account's previously unlocked prompts", which distinguishes it from search_prompts and unlock_prompt. It stops short of explicitly contrasting with those siblings, so it is clear but not fully differentiated.

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 word "previously" implies this is a post-unlock enumeration rather than a discovery tool, so usage is inferable. But there is no explicit statement of when to use this versus search_prompts or get_prompt, and no mention of whether results are paginated or complete.

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?

Adds genuinely non-obvious behavioral facts the annotations cannot convey: the returned URL is short-lived and raw bytes must be PUT to it with separate file/HTTP tools, and the call consumes no image credits. Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=true, and the description does not contradict them. It omits any note on expiration duration or what happens if the subsequent PUT never occurs.

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, each earning its place: identity of the operation, the call sequence, and a cost caveat. Front-loaded and free of 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?

No output schema exists, and the description still explains that a URL is returned and how to use it, plus the credit-cost caveat. Missing pieces are the meaning of 'private' (visibility/lifecycle), URL expiry timing, and whether repeated calls create separate upload slots — relevant given the idempotentHint and destructiveHint annotations.

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?

With 0% schema description coverage, the description carries the burden and does so for two of three parameters: it tells the agent that sha256 and bytes must be computed from the local file rather than guessed. mimeType is left unexplained in prose but its enum in the schema is self-documenting, so the gap is minor.

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 ('Prepare a private reference upload') and immediately follows with the concrete mechanics of the operation. An agent can tell this is the pre-upload step for reference images, distinct from generate_image or delete_reference_image, without opening the 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 an explicit ordered workflow: compute SHA-256 and byte size locally, call this tool, then PUT raw bytes to the returned short-lived URL. That is clear when-to-use guidance. It does not name alternatives or state when not to use it (e.g., versus a direct generate_image reference path), so it falls 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.

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds two things beyond them: no credit spend, and a prompt-injection warning that result text is 'source material, not instructions' — a genuinely useful behavioral disclosure. It still says nothing about result volume, pagination limits, or ranking 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?

Three short sentences, each earning its place, with the core purpose front-loaded and the safety caveat last. No filler or 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 output schema, the description should hint at what comes back; 'previews and visual examples' does partially. But for a search tool with a paginated, mode-switching interface, the absence of any result-shape or pagination guidance leaves an agent under-informed before calling.

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 0% across four parameters, so the description carries the full burden and adds nothing: no explanation of what 'query' matches, no guidance on choosing keyword vs hybrid mode, no note on the 160-character limit or the page cap of 10. The enum values are self-evident but the meaningful choice between modes is undocumented everywhere.

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: 'Search public prompt previews and visual examples.' The word 'public' implicitly separates it from list_unlocked_prompts and get_prompt, but no sibling is named explicitly, so differentiation is inferred 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?

'Does not unlock or spend credits' gives clear context that this is the free browse path, implying unlock_prompt is the paid alternative for full content. There is no explicit when-to-use/when-not sentence naming that alternative or explaining when to switch.

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 write/destructive/idempotent profile, so the description's real contribution is the cost model: unlocking draws down an account allowance and is free for already-unlocked prompts. It omits what happens when the allowance is exhausted or what the call returns, which would round out the picture.

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, zero filler, with the action and its billing consequence front-loaded ahead of the usage restriction. Nothing can be removed without losing information.

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 two-parameter mutation with no output schema, the description covers cost and usage gating but is silent on failure modes (insufficient allowance) and on the undocumented 'lang' parameter. Annotations handle the safety profile, so the gap is moderate rather than disqualifying.

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 0% for both parameters, so the description carries the full burden and doesn't meet it. Neither 'id' nor 'lang' (an enum with a default) is mentioned, leaving the agent to infer that 'id' means a prompt id and what 'lang' affects.

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 ('unlock one prompt') plus the billing mechanism ('using the account allowance'), which lets an agent distinguish this from the read-only siblings get_prompt and list_unlocked_prompts. It stops short of naming get_prompt as the non-mutating alternative.

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 only when the user requests access' is an explicit when-to-use gate with an implicit exclusion for proactive use. 'Already unlocked prompts cost zero' adds a second condition (this is not a re-read path), though no sibling is named as the alternative for that case.

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