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

The description goes well beyond the annotations, disclosing that sign-in is required, that a free preview is included with further scoring limited to eligible accounts, that the attempt is saved to Fiveable progress, that the call returns a pending job requiring polling, and that requestId should be reused for retries. This covers auth, quota, side effects, async return behavior, and idempotency guidance—exactly the kind of behavioral context 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?

Five sentences, each carrying distinct information: core purpose, photo transcription workflow, prompt image rationale, auth/eligibility, and async result/retry behavior. The most important scoping information is front-loaded in the first sentence, and no sentence is 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?

Given the tool's complexity—11 parameters, 6 required, image arrays, an output schema, and a multi-step transcription workflow—the description covers the critical non-schema aspects: when transcription confirmation is required, auth and eligibility, persistence of the attempt, return type, and polling/retry. The output schema presumably documents the return value shape, so the description need not repeat it. The only minor omission is whether pasted (non-photo) submissions also require transcription confirmation, but the schema's const true on transcriptionConfirmed and the workflow description make this inferable.

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 91%, so the input schema already documents most parameter meanings. The description reinforces the transcription-confirmation requirement and the requestId retry rule, but these are already present in the schema. It adds little genuinely new per-parameter semantics beyond the schema, so 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 first sentence, 'Scores a student's existing FRQ even when it did not come from Fiveable,' is a specific verb+resource statement that clearly distinguishes this tool from the sibling score_frq_response. The title reinforces the purpose: 'Score an uploaded or pasted FRQ.' An agent can immediately identify what this tool does and how it differs from the standard FRQ scoring tool.

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 explicit workflow instructions: if the student attached photos, the host AI must first transcribe the prompt and response, show the transcription for confirmation, then call this tool. It also directs the agent to poll get_scoring_result for the result and reuse requestId for retries. However, it never names the alternative tool score_frq_response directly or states an explicit 'use the other tool when the FRQ came from Fiveable,' leaving that distinction implied by 'even when it did not come from Fiveable.'

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