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

With no annotations, the description carries the transparency burden. It discloses the returned data types (agents, statuses, unread counts, recent messages) and implies a read-only operation, but does not state whether it affects message read state or how 'recent' is bounded. This is adequate but not thorough.

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 short, front-loaded sentences. The first states the action and key content; the second gives usage guidance. No filler or repetition.

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 no-parameter read-only overview tool, the description covers the essential information: what it returns and when to use it. The ambiguity around 'recent messages' is minor given the tool's simple nature and the lack of an output schema.

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 tool has zero parameters, so the baseline is 4. The description adds value by explaining what the returned board contains, which is sufficient since there is nothing to configure.

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 ('Get') and identifies the exact resource ('the full orchestration board'), then enumerates its contents: agents, statuses, unread counts, and recent messages. This clearly differentiates it from siblings like list_agents or get_thread, which cover narrower slices.

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?

Explicitly says 'Use this for a birds-eye view,' giving a clear use case. It does not mention when not to use it or alternatives, but the context is sufficient for a simple retrieval tool with no parameters.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only operation that returns all messages in a thread, but it does not mention return format, ordering, pagination, error behavior, or authentication requirements. For a simple retrieval tool this is adequate, but not rich.

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 clear sentence with no filler, placeholder, or redundant information. It immediately states the action and the required input.

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 one-parameter retrieval tool, the description covers the essential purpose and input. It doesn't detail return value shape, but the absence of an output schema and the straightforward nature of the operation make this acceptable. Could mention whether 'all messages' includes metadata or ordering, but overall it is complete enough for basic use.

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 fully documents the single parameter thread_id with a description, and schema coverage is 100%. The tool description adds only the phrase 'by thread ID,' which reinforces the parameter's role but doesn't provide additional semantic detail beyond what the schema already states. 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 uses the verb 'Get' with the specific resource 'all messages in a conversation thread' and identifies the input mechanism 'by thread ID.' It distinguishes itself from siblings like read_messages by focusing on a single thread rather than general message retrieval.

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 this tool should be used when you have a thread ID and want all messages in that thread, but it does not explicitly state when to prefer get_thread over read_messages or provide any exclusion criteria. The context is understandable but not explicitly contrasted with alternatives.

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?

No annotations are provided, so the description carries the burden. 'List' implies a non-mutating read, but it does not explicitly state safety, ordering, or permission requirements. Minimal behavioral disclosure beyond the operation.

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?

Single sentence, under 15 words, front-loaded with verb. 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?

Description specifies the return fields (status, role, last seen time), compensating for lack of output schema. However, it doesn't mention whether the list is ordered or if there are any filters. Overall adequate for a simple list tool.

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 tool has zero parameters, so baseline 4 applies. The description adds no parameter-specific info because none exist.

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 'List' with resource 'registered agents' and enumerates returned fields (status, role, last seen time), clearly distinguishing it from sibling tools like register_agent or send_message.

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 explicit when-to-use or alternative tools are mentioned. Usage is implied: use when you need an overview of all agents. The description doesn't exclude alternatives or specify when not to use.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns unread messages addressed to this agent, which is helpful, but it does not state potential side effects (e.g., whether messages are marked as read) or behavior like blocking. This leaves some ambiguity.

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 two sentences, front-loaded with purpose and followed by usage guidance. Every word earns its place, with no redundancy or fluff.

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 one-parameter tool with no output schema, the description covers purpose, when to use, and return type. It omits potential side effects, which is a minor gap, but overall it provides adequate context for an agent to use the tool correctly.

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 description adds no extra parameter semantics beyond the schema's 'The polling agent's name'. Baseline 3 applies because the schema fully documents the single parameter.

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 checks for new instructions or messages, using a specific verb ('check') and resource, and adds 'Returns unread messages addressed to this agent', which distinguishes it from the sibling read_messages tool. This makes the purpose 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?

The description explicitly instructs agents to call this between tasks to see if priorities have changed, providing clear when-to-use context. It does not explicitly mention alternatives like read_messages, but the guidance is actionable and sufficient.

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 transparency burden. It discloses the side effect of marking messages as read and specifies the two categories of messages returned (addressed to this agent or broadcast). However, it does not mention behavior like pagination, what happens with no messages, or any permissions/rate limits, so it is adequate but not rich.

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 two short sentences with no filler. The key information (read, scope, side effect) 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?

For a tool with 4 parameters and no output schema, the description covers the core behavior and side effect, but lacks guidance on output format, pagination, or when to use versus alternatives. Given the simplicity, it is mostly complete but has minor 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 the baseline is 3. The description does not add much beyond the schema; the mention of 'addressed to this agent or broadcast to all' clarifies the agent_name context but doesn't detail the other parameters. The schema already describes type, since, and unread_only.

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 'Read' and identifies the resource 'messages' and the target 'for an agent'. It also clarifies the scope (addressed to this agent or broadcast to all), which distinguishes it from sibling tools like send_message and poll.

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 some context by stating what the tool does, but it does not explicitly mention when to prefer this tool over alternatives such as poll or get_thread, nor does it mention any exclusions or prerequisites. Usage is implied rather than explicitly guided.

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?

No annotations are provided, so the description must disclose behavioral traits itself. It reveals only the ordering constraint ('Call this first') but does not mention side effects, idempotency, error behavior, or any registration limits. This is thin coverage for a tool that creates a session-scoped registration.

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 short sentences, front-loaded with the core purpose and the critical usage instruction. Every word earns its place with no redundancy.

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 registration action with well-documented parameters, the description covers purpose and timing. No output schema exists, but the description does not explain what the tool returns; however, this is a minor gap for a straightforward registration tool, and the overall context is adequate.

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 covers all 4 parameters with descriptions and examples, including the optional 'current_task'. The description adds no additional parameter-level meaning, but the schema already provides the necessary semantics, so the baseline of 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 the action ('Register this agent') and the resource ('with the message board'), making it distinct from sibling tools like send_message or read_messages. It also adds the critical context that this is the first call in a session.

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 explicitly says 'Call this first when starting a session,' providing clear when-to-use guidance. It does not mention alternatives or exclusions, but the instruction is sufficiently directive for the intended use case.

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 provided, the description carries the full burden of behavioral disclosure. It states that messages are persisted in the shared portal database, which is a key side effect. However, it does not elaborate on delivery semantics, return values, or how broadcast vs. direct messaging behaves differently, leaving some ambiguity.

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, concise sentence that is front-loaded with the core action. Every word earns its place, and there is no redundant 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?

Given the tool has 6 parameters and no output schema, the description provides the essential context (send, recipient, persistence) but omits details about return values or how this tool relates to threading (given sibling get_thread). It is adequate but not comprehensive for a tool with 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?

The schema covers all 6 parameters with descriptions, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides; it only mentions broadcast ('all' recipient) and persistence, which are already implied by the schema.

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 action (send a message) and the target (another agent or broadcast to all agents), distinguishing it from sibling tools like read_messages and poll. It is specific and uses a clear verb-resource structure.

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 clear context for when to use the tool: for sending messages either to a specific agent or as a broadcast. It does not explicitly exclude alternatives, but the distinct purpose from sibling tools (e.g., read_messages, update_status) makes the usage context apparent.

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 provided, the description carries the burden of behavioral disclosure. It conveys that the tool mutates status and current task, but does not mention whether omitting current_task clears an existing value, what happens on invalid status (though enum covers it), or any other side effects. This is a minimal but adequate level of transparency for a simple status update.

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 two sentences, front-loaded with the core purpose, and each sentence earns its place. The second sentence provides usage triggers without redundancy. No waste or unnecessary detail.

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, the description covers purpose, usage triggers, and the parameters are fully documented in the schema. It does not explain return values or error cases, but no output schema exists and the tool is low-complexity. Slight gap: could clarify the effect of not providing current_task, but the description is reasonably complete for selecting and invoking this tool.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description mentions 'status and current task' but does not add semantic nuance beyond the schema, such as interdependencies or formatting requirements. It neither helps nor hurts beyond the schema.

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 ('Update') and clearly identifies the resource ('this agent's status and current task'), which distinguishes it from sibling tools like send_message or register_agent. The purpose is unambiguous and directly maps to the tool's name.

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 explicitly states when to call the tool: 'when starting a new task, getting blocked, or completing work.' This gives concrete trigger scenarios and implies a clear workflow context, making the usage guidance actionable.

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