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

The readOnlyHint=true annotation is consistent with a 'Check' description. Beyond annotations, the description adds real domain context by naming the two balance categories (available vs. held) and the credit-to-IDR conversion rate, which no structured field provides.

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 resource first and the unit definition second. Every clause earns its place, and there is 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?

For a zero-parameter, read-only tool with no output schema, the description covers what is checked and the unit of measure. Minor remaining gap: what 'held' credits represent concretely (e.g., reserved by pending jobs), but nothing essential to invoking it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it does not waste space inventing parameter discussion.

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 ('Check available and held Yorai credits') and even defines the credit unit. It is unambiguous and no sibling in the yorai_* family covers balances, though the description never explicitly contrasts itself with them.

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 a pre-flight check before quoting or creating jobs, but the description never says when to call it or that it is the sole balance source. There are no explicit alternatives or exclusions to state.

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; it discloses the state mutation, the credit-hold release side effect, and the 409 failure mode for running jobs. It omits idempotency behavior (what happens if the job is already cancelled or completed) and what the call returns.

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 primary action plus its side effect is front-loaded before the constraint. Every clause carries 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 one-parameter tool with no annotations and no output schema, the description covers purpose, constraint, and error code, but never says what a successful cancellation returns or how to interpret the result. The single parameter is also left unexplained, which is a meaningful gap given 0% schema coverage.

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 0% — the single `id` parameter has no description at all. The description implies the id identifies 'a queued job' but never states the identifier type, format, or where an agent obtains it, leaving the only parameter under-specified.

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 ('Cancel') and resource ('a queued job') plus the side effect ('release its credit hold'), which no sibling tool does. An agent can immediately distinguish it from yorai_create_job, yorai_get_job, and yorai_list_jobs.

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 bounds usage to queued jobs and names the when-not case ('Running jobs cannot be cancelled') with the resulting status code 409. It stops short of naming an alternative tool or describing prerequisites (auth/ownership), but there is no real sibling alternative for cancellation.

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 add real behavioral facts: it consumes credits, does not stream, and returns OpenAI chat.completion format. It omits permissions/auth requirements, rate limits, and failure modes, so a calling agent still lacks several operational details.

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 action and followed by the key constraints and cost note. Nothing is wasted and no filler precedes the substance.

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 4-parameter inference call with no annotations and no output schema, the description covers format, cost, and non-streaming behavior but leaves the parameter semantics undocumented and gives no sense of return shape beyond a format name.

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 compensate and largely does not. It hints that a model is selected from the Yorai catalog (implying the default-model behavior) but says nothing about messages structure, max_tokens, or temperature ranges.

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: run a text chat model from the Yorai catalog. The parenthetical narrows the scope (no streaming, text only) and distinguishes it from job/file-oriented siblings, though it doesn't name an alternative for streaming or multimodal needs.

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 constraint list (chat completions, no streaming, text only), which tells an agent what this tool is not for. But there is no explicit guidance on when to use it versus siblings such as yorai_quote, yorai_create_job, or yorai_list_models for model discovery.

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?

Discloses traits the annotations cannot express: the call spends credits, the server quotes a hold first and refuses if it exceeds max_credits, and the response is a job handle requiring polling. The idempotency_key retry instruction is consistent with (and explains) idempotentHint=false, since repeat calls do create new charges unless a key is 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?

Four sentences, front-loaded with the cost warning in caps, then the guardrail, return shape, and retry rule. No filler; each sentence changes agent 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?

No output schema exists, yet the description says it returns the job and points to yorai_get_job for results. The nested input object is correctly deferred to yorai_get_model and yorai_upload_file, covering everything needed to invoke it safely.

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 67%; the description adds the key semantic the schema lacks — purpose and retry behavior of idempotency_key — and clarifies the max_credits guardrail beyond its schema text. webhook_url remains unexplained in both places, leaving one 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 ("Start an image/video/audio generation") and immediately signals the financial side effect with "SPENDS CREDITS." It is distinguishable from listing/reading siblings and names yorai_get_job as the follow-up step.

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: call this to start generation, then poll yorai_get_job, and reuse idempotency_key on ambiguous retries. It stops short of explicitly contrasting with yorai_quote for cost pre-checking, so the alternative-path guidance is implied rather than stated.

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 must carry the behavioral load, and it does disclose two important traits: the file lands on the machine running the MCP server (not the caller's machine) and the destination defaults come from YORAI_DOWNLOAD_DIR or ~/Downloads/yorai. It omits overwrite behavior when filename collides, permission requirements, and whether the saved path is returned.

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 action, and each carries information (destination machine, retention limit, default directory). 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?

A no-annotation, no-output-schema tool with three undocumented parameters needs more than this: the description is silent on the return value (e.g. the written path), filename semantics, and collision handling, leaving the agent to guess on a filesystem-mutating operation.

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 0%, so all three parameters are undocumented in the schema. The description only gestures at 'id' (ambiguously, as a job output id) and explains save_dir indirectly through the default folder sentence; 'filename' is never mentioned at all.

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: saving a Yorai file to disk on the MCP server host, which implicitly contrasts with the sibling yorai_upload_file. The parenthetical '(e.g. a job output id)' muddies what 'id' refers to, but the core action 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?

It mentions the 14-day purge of results, which hints at urgency but never states when to call this versus alternatives or what prerequisites exist (e.g. must the job have completed first?). No exclusions or routing guidance is 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?

The description is consistent with readOnlyHint=true and adds behavior the annotations cannot convey: the status state machine (queued, running, succeeded, failed) and the long-polling semantics of wait_seconds. It omits edge cases such as unknown or expired job ids and whether outputs are partial while running.

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 purpose, then the polling control, then the status vocabulary. No filler, and each sentence adds information the agent actually 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?

There is no output schema, but the description indicates the return carries status and outputs and enumerates the possible statuses, which is enough to interpret a response. The remaining gap is that 'outputs' is never characterized, so the agent cannot anticipate the payload shape.

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 both parameters. It explains wait_seconds well, including the polling cutoff, but says nothing about id: where the agent obtains one (presumably from yorai_create_job or yorai_list_jobs) or whether it is a job identifier versus another resource type.

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: getting a single job's status and outputs. That singular retrieval is clearly distinct from yorai_list_jobs and yorai_create_job, though the description never names those siblings to make the routing explicit.

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 concrete use guidance for wait_seconds: poll until the job finishes or the wait ends, with the 55-second cap. It stops short of telling the agent when to prefer a get over yorai_list_jobs, and names no exclusions or prerequisites.

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 declares the safety profile, so the description's burden is lighter. It adds real value by disclosing the contents of the response (generation types, limits, linkage rules, prices), which tells the agent what it can rely on after the call.

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 payload description front-loaded and the call-ordering advice second. No filler; every clause carries 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?

With no output schema, the description compensates by listing the fields the model record contains, which is what the agent needs to decide to call it. The remaining gap is the unexplained slug parameter, which keeps it from a 5.

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 sole parameter 'slug' is undocumented in both schema and description. The description only implies a model identifier via 'one model'; it never states what a slug looks like or where to obtain it (e.g., from yorai_list_models), leaving the agent to guess.

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 (get) and resource (one model) and enumerates exactly what comes back: generation types, input names/options/limits, linkage rules, and prices. The phrase 'one model' implicitly separates it from the sibling yorai_list_models, though the sibling is not named.

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 says to call it 'before quoting or creating a job,' which ties it to yorai_quote and yorai_create_job in the workflow. No when-not guidance, but the ordering rule is concrete and actionable.

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 declares this a safe read, so the description only needs to add context, and it does add result ordering and a continuation mechanism. However, 'recent' is never bounded and no return shape is given. The bigger issue is that it references 'next_cursor' while the schema parameter is named 'cursor', which can send the agent looking for a token that doesn't exist by that name.

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, front-loaded sentences with no filler: purpose first, then pagination. It's efficiently sized, though the terseness is part of why key semantics are missing.

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 read-only list tool with annotations covering safety and no output schema, the description is nearly adequate. But the undefined 'recent' window and the cursor naming mismatch leave gaps an agent would need to guess around.

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 carries the full burden for both parameters, yet it never explains 'limit' (default 20, max 100) and its only cursor guidance uses a name ('next_cursor') that does not match the schema property 'cursor'. An agent could pass a wrong key or miss the cap entirely.

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 recent jobs') plus ordering ('newest first'), which clearly separates it from yorai_get_job, yorai_create_job, and yorai_cancel_job. It doesn't name a sibling 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 pagination hint ('Use next_cursor for more') tells the agent how to continue a listing, implying this is the enumeration tool. But there is no explicit when-to-use/when-not guidance versus yorai_get_job or any statement of scope (e.g., which account or workspace's jobs are listed).

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 annotations already cover read-only semantics, so the bar is lower. The description adds useful context that it returns the starting price, which is not stated in the schema and is not obvious from the name alone.

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 uses two tight sentences with no filler, and the main capability is front-loaded before the filtering detail.

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

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

The description is complete for a filtered-list tool: it names the resource, the returned price, and the filters. However, it does not mention pagination or whether results are limited, which leaves a gap for an agent that expects a long list.

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

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

The description adds the allowed category values and supplies type examples that extend beyond the short property hints. Schema coverage is 75%, and the description usefully clarifies the two vaguely documented parameters (type and provider).

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: 'List models in the Yorai catalog with their starting price.' It is immediately distinguishable from siblings such as yorai_get_model (single model) and yorai_quote (pricing calculation).

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 tells the agent to filter by category (chat, image, video, audio), type, or provider slug, which gives clear usage context. It does not name an explicit alternative, but does state that filtering is the intended path over fetching individual models.

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 is consistent with the description, and the description adds real context beyond it: no credits are held, the call is free, and it returns credits/upTo/line items. It does not mention error behavior for invalid model/input or rate limits, 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?

Two short sentences: the first states what it does and its non-effects, the second names the return shape and the cost. Zero waste and front-loaded.

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 usefully names the returned fields (credits, upTo, line items), and the nested input object is well documented in the schema. Minor gap: no note on how the optional `type` disambiguates or on failure modes for an invalid model/input combo.

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%, with per-field guidance including cross-references to yorai_get_model and yorai_upload_file, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already says.

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?

"Price a request without starting a job or holding credits" gives a specific verb (price/quote) and resource, and explicitly delimits it against the create-job sibling. An agent can tell this apart from yorai_create_job without opening either 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?

The phrase "without starting a job or holding credits" makes the pre-flight dry-run use case clear and implicitly points to yorai_create_job as the alternative. It stops short of an explicit "use this before creating a job" instruction or exclusion of other siblings, but the context is unambiguous.

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 does real work: per-media size caps, video duration bounds, accepted MIME types, and the key behavioral fact that a URL is fetched server-side while a path resolves on the MCP host machine. It omits auth needs, dedup/overwrite behavior, and failure modes, keeping it short of 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?

Two sentences, both front-loaded with the decision-relevant information (what's accepted, then how to supply it). No filler and no restatement of the name or title.

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?

Covers the return value (file ID) despite no output schema, plus all format and size gates an agent needs to avoid a failed call. The unexplained filename parameter and the absence of any error or auth behavior are the only real 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 coverage is 0%, so the description must compensate, and it does for the two decision-critical parameters: url is a public https URL the server downloads, path is local to the MCP server host. The third parameter, filename, is never explained, so the agent must guess its purpose.

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?

Names a specific verb (upload) and resource (file) and states exactly what comes back — a file ID usable as job input. The supported media classes and constraints make it unmistakable against siblings like yorai_download_file or yorai_create_job.

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?

"and get a file ID for job inputs" implicitly positions it as a precursor to create_job, and the second sentence tells the agent it must supply either a URL or a local path. There is no explicit when-not or named alternative, but with only one sibling in the opposite direction (download) the routing risk is low.

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