Arumi

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

No annotations exist, so the description carries the burden. It discloses the two-step ordering and the downstream use of asset_id, but says nothing about idempotency, whether a premature call fails, upload_id expiry, or authentication requirements for a state-finalizing operation.

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: action, prerequisite, and output are packed into one clause, and nothing is repeated from the 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?

For a one-parameter finalization step with an output schema present, the description covers sequencing and the follow-up use of the result, so an agent can place the call correctly. Only failure-mode and prerequisite detail about upload_id are 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 description coverage is 0%, so the description must explain upload_id, yet it never says where the id originates or what format it takes. The parameter name is self-describing, but the only real meaning added is implied by 'after the PUT'.

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 action ('Finish an upload') plus the exact point it applies ('after the PUT') and what it yields ('asset_id'). This cleanly separates it from the sibling create_upload, which starts the sequence rather than ending it.

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

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

Gives a clear triggering condition — call it after the PUT — and tells the agent where the result goes (a generation's references). It does not name exclusions or contrast failures, 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.

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

With no annotations, the description carries the full burden and does disclose the non-obvious behavior that matters most: this is a two-phase protocol where the actual byte transfer happens outside the tool against a returned URL with exact headers. It omits other behavioral traits an agent would want — URL expiry, whether an uncompleted upload is retained or garbage-collected, and how sha256/size mismatch is handled.

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, and the sequence is front-loaded so the agent learns the 'start' step before the follow-up instruction. Every clause carries actionable 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?

An output schema exists, so upload_url and headers needn't be described, and the input schema is well documented; the description fills the remaining gap by explaining the out-of-band PUT step and the handoff to complete_upload. Minor omissions around expiry and failure handling keep it from being fully self-sufficient for a multi-step 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 83%, so the schema already documents file_name, content_type, sha256, and the image width/height requirements. The description adds no parameter-level meaning of its own and never references size_bytes or the relationship between the declared hash/size and the bytes actually PUT.

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 ('Start uploading one of the user's files') and explicitly frames it as the first half of a two-step flow by naming complete_upload, which separates it from that sibling. It stops short of saying what a 'reference' file is used for downstream, so the agent knows the mechanism but not the full intent.

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

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

Gives a clear operational sequence: call this first, PUT the bytes to upload_url with exactly the returned headers, then call complete_upload. That is strong when-to-use guidance for the happy path, but it offers no exclusions or prerequisites — nothing about size limits, supported content types as a gate, or what to do if an upload is abandoned.

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 annotations (readOnlyHint=false, destructiveHint=false), the description discloses the two traits an agent most needs: the call spends credits and is refused with nothing charged when over budget, and it returns immediately as an async job rather than producing a result. That polling contract is stated outright.

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 carrying distinct information: spend, refusal condition, and async follow-up. The call pattern (get_generation) is front-loaded in the final clause where an agent needs it.

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?

This is a complex, chargeable, asynchronous tool with nested inputs and an output schema, and the description covers the spend/refusal contract and the polling requirement. Return-value details are correctly left to the output schema.

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 all six parameters including the nested references object are already documented; the description nonetheless adds real meaning by explaining that max_credits is a quote-based spend ceiling with refusal semantics rather than just an integer field.

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 ('Start a generation') plus the resource it consumes (the user's credits), which distinguishes it from quote (pricing) and get_generation (status) among the 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?

It gives clear context: the call is refused when the quote exceeds max_credits, and it explicitly routes follow-up to get_generation until success or failure. It stops short of naming the quote sibling as the way to discover cost before calling, so the alternative path is only 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 readOnlyHint=true, so safety is covered; the description's added value is explaining what the three balance components mean, notably that 'held' credits are tied to running generations. It does not discuss refresh/staleness or whether the balance is per-user or per-workspace. The idempotentHint=false annotation is slightly odd for a zero-argument read, but the description does not contradict it.

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 zero filler; the three balance categories and the credit-to-USD rate are the only facts an agent needs to interpret the numbers.

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, return formatting is already documented, and the description supplies the units and semantics ('1 credit = 0.01 USD') needed to read those values correctly. The only gap is a note on whether held credits fluctuate as generations run, which would matter for repeated calls.

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 no parameters, so the baseline applies. There is nothing for the description to disambiguate, and it does not waste words on nonexistent inputs.

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 identifies the exact resource ('the user's Arumi credits') and enumerates the three sub-balances it reports: available, held by running generations, and owed. It is clearly distinguishable from siblings like get_generation or quote. It stops short of an explicit verb ('retrieve/return'), but the resource is specific enough that an agent knows what it gets.

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 alternatives. An agent must infer on its own that this is the tool to call before generate to check whether credits suffice, and nothing warns about when the balance is stale or changes.

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, so safety is covered; the description adds the useful state-conditional detail that result links only exist after success. It does not cover whether repeated calls are safe (notably idempotentHint=false is left unexplained) or whether failures surface in the same shape. With an output schema present, further return-value detail would be redundant, so a 3 is fair.

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 clause with zero padding, and the highest-value facts are front-loaded. The telegraphic, semicolon-joined phrasing is terse to the point of reading as a note rather than a definition, 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?

Annotations and an existing output schema carry much of the burden for a one-parameter read tool, so little is strictly missing. The gaps that remain, chiefly the meaning and provenance of generation_id and the lack of routing versus list_generations, keep it at minimally 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 0% for the single required parameter, so generation_id is undocumented in both places. The description never says what a generation_id is or where it comes from (presumably the generate response), which is exactly the gap the description should fill at low coverage.

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 the resource ('a generation') and what the call surfaces (status, result links, charge), which is enough to tell it apart from list_generations, generate and get_model. It is written as a noun phrase rather than a verb, so the retrieval action is implied rather than stated, and 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?

There is no when-to-use guidance: nothing says whether this is for polling after generate, for inspecting a single result, or how it differs from list_generations. The clause 'once it has succeeded' hints at polling but leaves the alternative and the pre-condition unstated.

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, so safety is covered. The description adds only a restatement of the payload contents, not behavioral context such as whether the call fails for unknown models, whether reference files are omitted when absent, or any reason idempotentHint is false for what looks like a pure read.

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 clause with no wasted words, and the most important information (single model, its limits and settings) leads. The only flaw is that it is a sentence fragment rather than a complete statement of action.

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 does not need to enumerate return values, yet it spends its whole length doing so. For a one-parameter read tool this is roughly adequate, but it omits error behavior and the sibling relationship an agent needs to select it confidently.

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 the single parameter 'model' is documented in the schema as 'the model id from list_models'. The description adds no format, casing, or lookup-dependency detail beyond that, so the baseline 3 applies.

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

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

The description names the resource ('One model') and enumerates the content returned (prompt limit, reference files, settings with allowed values and defaults), so the subject matter is clear. However, it is a noun-phrase fragment with no verb, and it never distinguishes itself from the sibling list_models, leaving the agent to infer that this is the single-model detail lookup.

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 explicit when-to-use guidance. The adjacent list_models tool is only implicitly contrasted by the word 'One', and nothing states prerequisites such as needing a valid model id obtained from list_models or what happens on an unknown id.

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 idempotentHint=false, so the safety profile is covered. The description adds real scope context — results span generations made on the site and via any API key — but says nothing about pagination behavior, result ceilings, or how non-idempotency manifests (e.g., results shifting as new generations arrive).

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 sentence with no filler, and the ordering constraint is front-loaded before the scope qualifier. It is efficient, though the phrase "made on the site or through any of their keys" is the one part that could be tightened.

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 and the single parameter fully documented, the description only needs to carry scope and ordering, which it does. The main residual gap is not distinguishing this listing from get_generation, a low-complexity tool otherwise well covered by its structured fields.

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 limit parameter is fully documented in the schema including range and default. The description's "newest first" phrasing corroborates the ordering, but adds no syntax or format detail beyond what the schema already states, so the baseline 3 applies.

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

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

The description names the resource ("the user's latest generations") and the ordering ("newest first"), so an agent can tell it is a listing call rather than a single-item fetch. It does not name or contrast with a sibling such as get_generation, and the verb is implicit in the name 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?

Usage is only implied: "latest generations" suggests this is the browse/recent-activity entry point, while get_generation presumably fetches one by id. There is no explicit statement of when to prefer this tool over get_generation or how it relates to generate, leaving the choice 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 readOnlyHint=true, so the agent knows this is a safe read; the description's added value is that results are restricted to models the calling user can actually generate with and are organized by kind. It says nothing about result volume, ordering, pagination, or what happens when the filter is omitted. With the safety profile already covered by annotations, a 3 is appropriate.

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, with the resource statement front-loaded and the sibling disambiguation second. The first sentence is an elliptical fragment that reads slightly awkwardly, which keeps it just short of a 5.

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

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

For a zero-required-parameter, read-only listing tool with an output schema (so return shape needn't be explained), the definition covers purpose and sibling routing adequately. The remaining gap is that an agent cannot tell from the description whether calling with no modality returns all models or errors — a small but real omission.

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 modality parameter already documents its allowed values, so the description's parenthetical list of kinds merely repeats the schema. It does not say that modality is optional or that omitting it returns every kind — the one piece of parameter behavior the schema leaves implicit. Baseline 3 for a fully documented single-parameter schema.

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 identifies the resource (the set of generation models) and its scoping (models the user can generate with) plus the filter dimension (image, video, audio, text), and it explicitly contrasts with the sibling get_model, which returns a single model's inputs and settings. The only weakness is that it is written as a noun phrase with no verb, so the listing action is implied 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 second sentence routes the agent: use this tool to survey available models, use get_model when you need one model's inputs and settings. That is a real when-to-use/when-to-use-the-alternative rule. It stops short of explicit exclusions (e.g., that this tool does not return pricing or per-model settings), so a 4 rather than 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?

readOnlyHint=true already tells the agent nothing is mutated, and the description confirms the no-side-effect, no-generation nature plus the unit of return (credits). However, it leaves idempotentHint=false unexplained — an agent may wonder why a supposedly pure price lookup is non-idempotent (presumably pricing can change between calls) — and says nothing about whether the quote expires or must be reused.

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 clauses, front-loaded with what it returns and immediately followed by the caller's obligation. No filler, nothing to cut.

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 is conceptually simple, an output schema covers the return shape, and the schema documents all four parameters, so the description is close to sufficient. The remaining gap is behavioral: it doesn't say how stale or binding a returned quote is, which matters given idempotentHint=false.

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 nested reference slot ordering, so the schema carries the parameter burden. The description only implies that model/prompt/parameters drive the price and never says whether references affect cost, adding little beyond the schema.

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 operation — costing a generation in credits — and its key defining property, 'without making it', which separates it from the generate sibling. An agent can tell immediately this is a price-preview call, not a job submission.

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 imperative 'Tell the user before generating' gives a concrete trigger: call this prior to generation and surface the number. It implies the alternative (generate) without naming it explicitly, and gives no guidance on when a quote would be unnecessary.

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