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

Annotations already carry destructive and idempotent hints; the description adds the financial consequence (not charged) and the exact behavior for already-finished jobs (left as is), which are not present in structured data. No contradiction with annotations.

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; the primary action and scope are front-loaded, and the second sentence adds the two behavioral caveats that matter. Every clause earns its place.

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 single-parameter destructive tool, the description covers the behavior, the no-charge outcome, and the finished-job edge case, while annotations cover idempotency and destructiveness. It doesn't mention how to obtain a job_id (e.g., from check_job), but that is a minor omission given the schema already names the parameter.

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% – job_id is already described as 'The job to stop.' The description echoes that semantics but does not add format, source, or validation guidance, so it stays at the baseline for high schema 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 a specific action ('Stop') on a specific resource ('a queued or running job'), and distinguishes itself from siblings like check_job by describing the state targeted and the post-cancellation behavior (not charged, finished jobs unchanged).

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?

Clearly says when the tool applies (queued or running) and when it has no effect (already finished), giving the agent an explicit condition. It does not name the sibling check_job as a status-check alternative, so it falls just short of full alternative routing.

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 discloses the key side effect ('save its results') and the conditional behavior ('if it has finished'), which goes beyond the annotations (readOnlyHint=false, destructiveHint=false). It doesn't mention waiting behavior, but annotations lower the bar for extra 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 sentences with no filler; the purpose and usage context are front-loaded. Every word earns its place.

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

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

The tool has no output schema, yet the description does not explain what the call returns or how to interpret the outcome (e.g., what happens if the job is still running after wait_seconds, or what a successful save response looks like). This is a significant gap for an async job tool and leaves the agent uncertain about response handling.

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

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

Schema description coverage is 100%, so all three parameters are already documented. The description adds no parameter-specific detail beyond the general 'save its results' phrasing, so the baseline of 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 clearly states the action ('look a job up by id' and 'save its results') and the conditional ('if it has finished'), making the tool's purpose unambiguous. It also distinguishes from siblings like cancel_job by describing a result-saving, not cancellation, operation.

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 an explicit trigger condition: 'Use after a tool answered before its job was done.' This tells the agent when to invoke it. It doesn't name alternatives or exclusions, but the context is clear enough to select this tool over siblings.

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 convey readOnlyHint=false and destructiveHint=false, but the description adds meaningful behaviors: the operation is free, does not start a job, files are retained until kept_until, and the estimate can exceed actual charges for recordings. No contradiction with annotations; the description enriches the behavioral 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 sentences with no redundancy: the first front-loads the core purpose, the second gives actionable reuse guidance, and the third covers a pricing caveat. Every sentence earns its place.

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?

Despite lacking an output schema, the description mentions all key return elements (estimate, file_id, kept_until) and how to use them. For a one-parameter tool with these annotations, this is sufficient; minor omissions like error handling are not critical.

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

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

The schema already fully documents path as an absolute path on this machine (100% coverage). The description adds that the path refers to a local file to be uploaded, which is a minor semantic clarification beyond the schema, but it does not add format or constraint details.

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 clearly states the tool's function: upload a local file and return the maximum credit cost without starting a job. It distinguishes itself from siblings by positioning as a precursor that returns a file_id for reuse with translate_file or transcribe_recording, making its role 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 explicitly instructs the agent to pass the returned file_id to translate_file or transcribe_recording to avoid double upload, giving strong contextual guidance. However, it does not explicitly state when not to use it (e.g., if a file_id is already available), so it lacks formal 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 convey readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds context about where credits are purchased and that the balance is consistent across platforms, which is helpful beyond annotations. It does not disclose response format, caching, or potential delays, but for this simple read operation the added context is adequate.

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 no filler. The primary meaning ('how many credits the account has') is front-loaded, and the additional context about pricing and shared balance is concise and relevant.

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 balance checker, this description is nearly complete: it states what the tool returns and clarifies that the balance is account-wide across platforms. Without an output schema, a minor gap is that it does not specify the unit or exact return type beyond 'how many credits', but the meaning is still clear.

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 has zero parameters, so the schema is trivially complete (coverage 100%). The description correctly avoids inventing parameters; with 0 params, it only needs to clarify the returned meaning, which it does.

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 the tool's core function – telling the agent how many credits the account has. It is clear and unambiguous, but lacks an explicit verb like 'retrieve' or 'get' and does not directly distinguish itself from siblings such as estimate_cost or check_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?

The description implies when to use the tool (whenever you need the account's credit count), and the note that the same balance serves the website and this server adds useful context. However, it offers no explicit when-to-use/alternatives guidance or exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description is not required to restate safety. It adds meaningful behavioral context beyond the annotations: the data is read from the live API and needs no authentication key, which informs how an agent should rely on the results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no repetition of the title or schema. The core information — what is returned and the main use case — is front-loaded, and the auth detail earns its place by removing a potential barrier to invocation.

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 optional-parameter list tool with no required inputs and no output schema, the description covers purpose, source, authentication, and intended use. The only missing piece is a precise description of the response shape, but the schema and context signals make the tool safely callable without it.

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

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

Schema description coverage is 100%, so the schema already fully documents the kind and matching parameters. The description doesn't add parameter-specific semantics, but under the baseline rule this is sufficient.

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 clear verb and resource: the tool lists the language codes and names Equalang accepts, read live from the API. It also gives a concrete task — turning a language's name into its code — which distinguishes it from the unrelated sibling tools like translate_file or check_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?

Provides a clear use case: use it to convert a language name into its code. It does not list explicit alternatives or exclusions, but none of the siblings serve this listing purpose, and the live-API detail implies when current data is needed.

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 only mark readOnly=false, openWorld=true, and destructive=false, so they do not disclose cost. The description adds that the operation consumes the user's credits, requires prior cost disclosure and agreement, and is billed only for recognized speech (not silence/music). This is exactly the kind of behavioral context agents need.

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, each with a distinct job: purpose, alternative, billing nuance, and mandatory cost consent. The format list is long but necessary; there is no filler or repetition.

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?

Even without an output schema, the definition covers what an agent needs to invoke correctly: supported file types, the save behavior, the cost/consent workflow, and a pointer to `estimate_cost`. Parameter behaviors like `wait_seconds` and temporary-link fallback are already fully described in the schema, so the description doesn't need to repeat them.

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 baseline is 3. The description adds value by listing the supported audio/video extensions for `source`, which the schema does not enumerate, and by characterizing the output as timed text, which clarifies `output_formats`. It doesn't add much for the other parameters, but enough to exceed baseline.

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 opens with a specific action ('Write down what is said') on a clear resource ('audio or video file') and states the output ('timed text...save it'). It also names the sibling it is not ('For a translation...use translate_file'), so an agent can distinguish transcription from translation without opening schemas.

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 explicitly routes translation requests to translate_file and directs the agent to estimate_cost before running, with the condition that user agreement must be obtained first. This gives clear when-to-use guidance and a prerequisite, leaving no ambiguity about the intended workflow.

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, the description discloses that the tool consumes user credits, requires prior agreement, saves the result, preserves layout, and returns paths rather than contents. This is critical behavioral information that the annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then supported types, then output behavior, then cost warning. Every sentence carries information not already in the structured schema, and the file-type list earns its place because it constrains valid source inputs.

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 an 8-parameter tool with no output schema, the description covers the most critical operational details: cost, output format, and file support. It could have been more explicit about the source/file_id requirement and what to do when a job_id is returned, though the schema descriptions and sibling tools such as check_job and cancel_job partially cover that.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by listing the accepted file extensions for source and clarifying the behavior for recordings. This helps an agent validate source inputs and understand how output_formats and bilingual apply.

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 opens with a specific verb-and-resource statement: 'Translate a whole file into another language and save the result.' It enumerates the supported file categories and even clarifies that recordings return as translated subtitles, which clearly separates this from text-only or transcription-only 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 explicit operational guidance: cost must be stated and approved first, and estimate_cost is named as the source of the number. It also tells the agent what the response will contain (paths, never contents). However, it does not explicitly tell the agent when to prefer translate_text or transcribe_recording instead, so it falls just short of full 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?

Beyond the annotations (readOnlyHint false, destructiveHint false, openWorldHint true), the description discloses charging ('Charged by length, a small amount; the answer says how much'), sentence-based splitting by Equalang, and ordering guarantees ('answered in order'). It also clarifies Limits (50 texts, 5000 chars each, 20000 total, 100000 for text), which are not in the annotations.

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 core action, then input modes, constraints, and the alternative tool. Every clause carries operational guidance; no filler or redundancy. The structure flows logically from what to use to how to use it and when not to.

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

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

Given the tool's multimodal inputs, limits, and cost behavior, the description covers all essentials: purpose, input selection, constraints, splitting behavior, cost disclosure, and file-related routing. With annotations and full schema coverage, nothing critical is missing for an agent to call it correctly.

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?

Although the schema has 100% coverage, the description adds critical semantics: the mutual exclusivity of text and texts, per-item and aggregate character limits, the instruction not to split long text because Equalang cuts at sentences, and that the response includes the cost. These details go well beyond the schema properties.

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 ('Translate plain text and answer with the translation') and explicitly contrasts with translate_file for files. It also distinguishes the two input modes (text vs texts), so an agent knows exactly what this tool does and how it differs from 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 explicitly tells when to use 'texts' (separate strings like labels/messages) versus 'text' (one long article/chapter), and when to use the alternative translate_file for anything file-like. It also mentions the cost implication, which helps an agent decide based on trade-offs.

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