get_brand_identity_generation_status

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

The annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that the job is async, which is useful context. However, it does not disclose potential error scenarios, possible status values, or behavior if the jobId is invalid. For a simple status check, this may be adequate but not exceptional.

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, well-structured sentence that immediately conveys the purpose. It is concise with no filler, and the key information (check status, async, brand identity, generation job) is 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?

Despite the tool's simplicity, the description lacks information about the return value. Since there is no output schema, the agent would benefit from knowing what the status response includes (e.g., field names like 'status', 'progress', 'error'). The description also does not indicate that this is a polling tool to be used after submission of a generation job.

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 input schema has 100% description coverage (jobId includes a description). The tool description does not add any additional meaning beyond the schema, so it meets the baseline 3. No extra context is provided about how to obtain or format the jobId.

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 'Check the status of an async brand identity generation job' precisely states the action (checking status) and the resource (an async brand identity generation job). The sibling tools include generate_brand_identity (which starts the job) and get_brand_identity (which retrieves a brand identity), so this tool is clearly differentiated as a status polling mechanism.

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 does not provide explicit when-to-use or when-not-to-use guidance. It is implied that this tool is used after submitting an async brand identity generation job, but no alternatives or prerequisites are mentioned. The sibling tool generate_brand_identity is a natural predecessor, but this relationship is not stated.

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