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

Annotations already declare readOnlyHint=true, and the description reinforces the key trait: no model invocation, so no cost or side effects from the call itself. It does not mention how faithful the estimate is versus the real generate_text count, but with annotations carrying the safety profile this is a solid addition rather than a gap.

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 core verb first and the crucial non-execution caveat attached. Nothing extraneous, nothing buried.

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 utility with a fully described schema and no output schema, the description covers purpose and behavior adequately. The one missing piece is what the response looks like (a token count integer, or a breakdown per input channel), which would matter when images and instructions are supplied.

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 five parameters (model, prompt, images, webSearch, instructions) are already documented in the schema. The description adds only the framing that the count mirrors a generate_text request, which is marginal but useful for interpreting webSearch and instructions. 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?

Specific verb (count) plus resource (input tokens) plus the exact consumer it is modeling (a generate_text request), and the qualifier 'without running the model' separates it cleanly from the sibling generate_text. An agent can tell immediately what this does and what it does not do.

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?

'without running the model' implicitly frames the use case: estimating token/cost load before invoking generate_text. That is clear context, but there is no explicit when-not guidance or pointer to a sibling alternative for other counting needs (e.g. embeddings or moderation inputs).

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 only declare readOnlyHint=true, and the description adds nothing beyond that. It says nothing about cost per token, which model is appropriate, batch size limits, whether embeddings are deterministic, or how many vectors come back for an array input — all real concerns for an embedding 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?

A single front-loaded sentence with no filler. It is terse to the point of under-specification, but nothing in it 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?

There is no output schema, so the description should explain what comes back (embedding vectors, one per input, fixed dimensionality). It also gives no guidance on model selection even though 'model' is required. For a required-parameter tool with no output contract, this leaves meaningful 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 100%, so both 'input' and 'model' are already documented. The description's phrase 'one or more pieces of text' echoes the schema's anyOf without adding format, size, or model-choice guidance, so 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?

States a specific verb+resource ('Get vector embeddings') and notes it accepts one or many texts, which is enough to distinguish it from all siblings (text/image/audio generation). It stops short of naming why an agent would pick this over, say, generate_text, but the resource 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?

There is no statement of when to use this tool, when not to, or what the alternatives are. The agent is left to infer that this is for semantic search / similarity / clustering use cases rather than text generation.

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, and the description adds real value by disclosing the return shape: per-input flagged status plus per-category flags and scores. With no output schema, this return-format disclosure is important. It stops short of covering rate limits, model availability, or error 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?

Two sentences, zero waste, with the action front-loaded and the return shape immediately following. Nothing extraneous and nothing padded.

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 read-only tool with no output schema, the description covers purpose and return values well. The main remaining gap is the required 'model' parameter — no example or guidance on valid model names is given anywhere.

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 both parameters are already documented. The description adds only a slight hint that input may be batched ('for each input'), which is already conveyed by the anyOf array in the schema. 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?

States a specific verb+resource ('check text for potentially harmful content using an OpenAI moderation model') and distinguishes itself from siblings like create_embeddings or generate_text by naming the moderation task. It does not explicitly name alternatives, but the purpose is unmistakable.

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 — the agent can infer this is the tool for safety/moderation checks — but there is no explicit when-to-use or when-not-to-use guidance, and no advice on how to pick the model parameter, which is required.

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 only declare readOnlyHint=false and destructiveHint=true; the description adds genuinely useful context by disclosing that results are written to disk and returned as file paths by default, with the client result-size limit as the rationale for that default. It stops short of warning that writing to outputPath may overwrite an existing file, which is the specific behavior the destructiveHint implies.

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, with the core action stated first and the return-mode caveat second. Every clause carries information the agent needs 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?

With 8 parameters, full schema coverage and no output schema, the description covers purpose and output form adequately. The remaining gap is file-side-effect semantics (overwrite behavior on outputPath, where temp files land), which matters for a tool flagged destructive.

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 schema already explains returnAs, outputPath, model compatibility and size constraints in detail. The description's returnAs explanation mostly restates the schema's own rationale, so it adds little beyond structured fields – 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?

States a specific verb ('Edit or combine') and resource ('existing images') plus the underlying capability (text prompt + OpenAI image model). It implicitly distinguishes itself from the sibling generate_image (which creates new images), but never names that 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?

Usage is only implied by the word 'existing' – an agent must infer that this tool is for transforming supplied images rather than creating new ones, and that generate_image is the alternative. No explicit when-to-use / when-not-to-use 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?

With readOnlyHint=false and destructiveHint=true already declared, the description still adds real context: by default the image is written to disk and a file path is returned, and base64 inline data risks exceeding an MCP client's result size limit. What it does not disclose is why the operation is destructive — e.g. whether writing to outputPath overwrites an existing file — which is the one behavioral fact an agent most needs before calling 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?

Two sentences, no waste, and the default return behavior is front-loaded immediately after the purpose statement. Every clause carries information an agent would otherwise have to open the schema to find.

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, so the description correctly takes on the burden of describing return values, covering both the file-path and base64 forms. It is nearly complete for a 6-parameter generation tool, with only overwrite/error semantics left unaddressed.

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 explains prompt, model, size, n, returnAs and outputPath in detail. The description restates the returnAs default and the path-vs-inline tradeoff but adds no syntax, format, or constraint information beyond the structured fields, so 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 states a specific verb and resource ("Generate an image from a text prompt using an OpenAI image model"), which separates it from generate_text and generate_speech. It stops short of explicitly contrasting with the closest sibling, edit_image, so an agent must infer the generate-vs-edit boundary from the phrase "from a text prompt".

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 tool's nature — call it when you need a new image from a text description — but no when-to-use or when-not conditions and no alternative tools are named. The only routing guidance offered is internal to the tool (path vs base64), not across tools.

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 only flag readOnlyHint=false and destructiveHint=true; the description adds the important behavior that a file is written to disk and that inline base64 payloads can exceed MCP client result-size limits. It does not cover API key/auth requirements or file cleanup, but the side-effect of disk writing is disclosed, consistent with destructiveHint=true rather than contradicting 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?

Two sentences, no padding, and the default-return-behavior fact is placed first because it is what an agent most needs to know before parsing a result. 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 usefully explains what comes back (a file path by default, inline audio otherwise), which is the critical missing piece. It could say more about cost/latency or that the saved file persists, but for an 8-param tool with full schema coverage this is largely complete.

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 eight parameters are already documented in detail, including voice enumeration, speed range, format enum, and the outputPath/returnAs interaction. The description only restates the returnAs semantics, adding no syntax or constraints beyond the schema, so 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 states a specific verb and resource ('Convert text to spoken audio') plus the backing engine (OpenAI TTS model). This is unmistakable against siblings like generate_text, transcribe_audio, or generate_image, none of which produce synthesized speech.

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 an explicit rule for the returnAs decision (default path, use base64 for inline), which is genuinely useful. But it offers no guidance on model selection, voice choice, or when to prefer this over sibling tools such as transcribe_audio in a round-trip workflow. Usage is implied rather than fully framed.

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 a prompt-and-reply tool, and the description confirms the return is a text reply, but it adds little beyond the schema — web search citation behavior and image format support are already documented in the parameter descriptions.

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, front-loaded with the core action and immediately covering the vision variant. 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 states the return is the model's text reply. For a five-parameter tool it is nearly complete, missing only model-choice or error-behavior context.

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 five parameters are already well documented in the schema. The description reinforces the images/model constraint but adds no syntax, defaults, or format details beyond what the schema provides.

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 ('Send a prompt to an OpenAI model and return its text reply') and notes vision capability when images are passed. This implicitly separates it from siblings like generate_image and generate_speech, though it never names 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?

The image sentence gives a conditional hint (use a vision-capable model when passing images), but there is no explicit when-to-use guidance or exclusion pointing to alternatives such as generate_image for image output or count_tokens for token accounting.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context about which models are returned ('configured models unless a tool allows any model'), but it remains vague about what 'configured' means and does not describe the response shape in detail.

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 only two sentences and front-loads the core purpose. The second sentence adds useful scoping but is slightly ambiguous rather than tightly precise.

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 listing tool with no output schema, the description is mostly complete: it states what is listed and the conditional scoping. It could say more about the response format, but nothing critical for invocation 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?

There are zero parameters, so this dimension gets the baseline score of 4. The description adds no parameter details because none are needed.

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 uses a specific verb and resource ('List available OpenAI models') and clarifies the returned scope ('configured models unless a tool allows any model'). There are no sibling tools to differentiate from, so this is clear without needing extra routing language.

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 the tool is relevant by explaining that it returns configured models unless a calling tool allows any model. It does not explicitly state when to use or avoid the tool, but the usage context is reasonably inferable.

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 a transcription operation, and the description adds that an external OpenAI model performs the work, hinting at API cost/dependency. However, it discloses nothing about file size or duration limits, remote URL fetching behavior, latency, or error modes, so behavioral burden mostly falls on the schema.

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 or redundancy. It is efficient, though its brevity means nothing is prioritized or expanded where the operation is non-trivial.

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 five-parameter tool wrapping an external paid API with no output schema, the description omits practical constraints an agent needs: input size/duration limits, whether remote URLs are fetched, expected latency, and cost implications. The schema covers parameter details, but operational context 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?

Schema description coverage is 100%, so file formats, model, format enum, prompt, and language are all documented in the schema itself. The description adds no parameter-level meaning beyond naming the model provider, which is the baseline for fully covered schemas.

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 ('Transcribe spoken audio to text') plus the underlying engine ('OpenAI speech-to-text model'). It is reasonably distinguishable from sibling translate_audio by the verb 'transcribe', though it never explicitly contrasts the two.

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 use this tool versus translate_audio or generate_speech, and no preconditions such as file size limits, supported duration, or cost/auth implications of calling an OpenAI model. The agent must infer usage entirely from the name and schema.

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 declare readOnlyHint=true, so the safety profile is already covered. The description adds a genuinely useful non-obvious trait beyond the annotations: output may occasionally return untranslated in the original language, which an agent would otherwise not anticipate and would need to validate.

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 earning their place: the first declares the operation, the second flags the reliability caveat. The core purpose is front-loaded with no filler or restatement of the 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?

With no output schema, the description carries return-value burden, and it does partly cover this by noting the possible untranslated output; the format parameter further documents output shapes. Missing only minor context like the language of the prompt or model selection guidance.

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 file, model, format, and prompt are already fully documented, establishing the baseline of 3. The description contributes no additional parameter meaning such as model choice or prompt behavior, so it neither compensates nor detracts.

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 (translate) plus resource (spoken audio) and the resulting artifact (English text), which inherently separates it from transcribe_audio's language-preserving behavior. It stops short of naming that sibling explicitly, so the differentiation must be inferred from the target language.

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 'into English text' phrasing implies the use case (foreign-language audio needing an English rendering), but there is no explicit statement of when to pick this over transcribe_audio, nor any prerequisites. 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.