Compute Logprobs

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only that the operation targets a base model or checkpoint; it does not describe return behavior, latency, or other operational traits beyond the annotation.

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 is a single, front-loaded sentence with no wasted words. However, for a tool with a deeply nested input, the brevity underspecifies the callable structure rather than being optimally concise.

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 a complex nested schema and many parameters, but the description omits key input semantics such as the renderer, the messages/token_ids distinction, and how model vs checkpoint_path should be supplied. An output schema exists, so return values need not be covered, but the input side is incomplete.

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 has a single complex request object with 0% description coverage. The description only vaguely maps to target (base model or checkpoint) and prompt token log probabilities, leaving prompt.messages vs prompt.token_ids, renderer, and nested message structures unexplained.

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: compute prompt token log probabilities. It also scopes the target as a base model or checkpoint, but it does not explicitly differentiate from siblings such as evaluate or sample.

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 purpose, but the description provides no explicit when-to-use guidance, prerequisites, or alternatives. It does not say when to choose this over evaluate, sample, or other inference-related tools.

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