RunAPI Gemini TTS MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The phrase 'look up' implies a read-only operation, which is helpful, but the description does not add further context such as rate limits, caching, or whether it accesses live pricing data. It is adequate but minimal.

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 a single sentence that directly communicates the tool's purpose. Every word earns its place, and there is no redundant or filler content. It is efficient 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?

This is a simple lookup tool with no output schema and no annotations. The description clarifies the core purpose, and the schema covers parameters. While it does not describe the return format, that omission is acceptable for such a straightforward operation. It is complete enough for the tool's low complexity, though it could mention that it returns pricing data.

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 baseline is 3. The description itself does not add parameter details, but the schema fully documents both 'model' and 'action' parameters, their defaults, and allowed values. No additional compensation is 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 clearly states the tool's function: looking up RunAPI pricing for a specific model line (gemini-tts). The verb 'look up' is specific, the resource (RunAPI pricing) is named, and the scope is defined, distinguishing it from sibling tools like text_to_speech (which generates audio) and get_task (which fetches task status).

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 that the tool is used when pricing information is needed, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. Sibling tools are not mentioned or contrasted, so guidance is only implicit.

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 are absent, so the description alone must convey behavior. 'Fetch' indicates a read-only operation, which is accurately reflected in the description. However, it does not disclose behavior for missing tasks, whether it blocks until completion, or any authentication/rate-limit requirements.

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 a single, front-loaded sentence that states the action and resource without extra verbiage. Every word contributes to the meaning.

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

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

Given the tool's simplicity (2 parameters, no output schema) and the clear schema, the description provides adequate context for a getter. It lacks explicit usage guidelines or notes about polling, but the minimal scope is acceptable; a small enhancement would be to mention it is for async task retrieval.

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?

Both parameters (action and task_id) are fully described in the JSON schema with 100% coverage. The description adds no additional semantic detail beyond the schema, so the baseline score 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 uses the specific verb 'Fetch' and identifies the resource as 'the current status and latest result payload for a gemini-tts task.' This clearly differentiates it from siblings like text_to_speech (task creation) and login/check_pricing.

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 provides no explicit guidance on when to use this tool versus siblings, such as 'use after starting an asynchronous text_to_speech task' or 'poll this endpoint for completion.' The context implies it is the retrieval counterpart to text_to_speech, but nothing in the description states this.

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 key behaviors: it opens a browser, uses PKCE, and saves an API key to a specific path. However, it omits the conditional behavior that the browser flow may be skipped unless 'force' is true, which is only revealed in the parameter description. No contradiction exists.

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 a single, front-loaded sentence that states the action, method, and outcome with no unnecessary words. It earns its place entirely.

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 simplicity (one optional parameter, no output schema), the description is complete enough for most use cases. It explains what, how, and where. The main gap is not stating that this is a prerequisite for other tools, but that is reasonably inferred.

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% because the only parameter 'force' has a clear description. The tool description itself adds no parameter-level detail, so it relies on 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?

The description clearly states the tool's purpose: 'Authenticate RunAPI' via a specific method (browser PKCE login) and a specific side effect (saving the API key to a config file). This is a specific verb+resource that clearly distinguishes it from the unrelated sibling tools.

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 usage (you need to authenticate before using RunAPI tools), but it does not explicitly state when to use it, when not to use it, or mention any alternatives. Since the sibling tools are unrelated, there's no direct competition, but the guidance is implicit rather than explicit.

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 transparency burden. It discloses that the tool returns a task id, status, and output URLs, suggesting asynchronous behavior, but does not mention authentication requirements, potential costs, or how to handle task completion. This is moderate but incomplete disclosure.

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 a single sentence, concise and front-loaded with the core action. It avoids redundancy and every word contributes to understanding the tool's purpose and basic output.

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 having 10 parameters and a complex schema with required speakers and dialogue_turns, the description gives no overview of the asynchronous task workflow, how to structure a request, or how to associate dialogue turns with speakers. The minimal single-sentence description is insufficient for a tool of this complexity.

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 80%, so the schema already explains most parameters. The description adds no additional parameter context, such as how to structure speakers or dialogue_turns, beyond what the schema provides. Baseline 3 is appropriate.

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 it creates a Gemini TTS task on RunAPI, using the specific verb 'Create' and naming the resource. This distinguishes it from siblings like get_task and check_pricing, which have different purposes.

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 usage for creating TTS tasks but provides no explicit guidance on when to use this tool versus alternatives, such as get_task for retrieving results or check_pricing for cost information. It lacks exclusions or direct references to sibling tools.

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