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. While it mentions 'Uses MCP sampling to provide context-aware help,' it doesn't describe important behavioral traits like whether this is a read-only or write operation, authentication requirements, rate limits, or what the output looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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 appropriately sized with three sentences. It's front-loaded with the core purpose, followed by implementation details and use cases. Each sentence earns its place, though the 'Perfect for:' list could be slightly more 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?

Given that an output schema exists (though not shown), the description doesn't need to explain return values. However, for a tool with no annotations and three required parameters, the description should provide more behavioral context about how the AI assistance works, what kind of output to expect, and any limitations. The current description is adequate but has clear gaps in completeness.

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 schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema. It mentions 'context-aware help' which loosely relates to the 'context' parameter, but provides no additional details about parameter usage, constraints, or interactions.

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: 'Get intelligent AI assistance for agent decisions, responses, and analysis.' It specifies the verb ('get assistance') and resource ('agent decisions, responses, and analysis'), though it doesn't explicitly differentiate from sibling tools like 'send-message' or 'update-agent-status' which might also involve AI assistance.

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 this tool: 'Perfect for: crafting smart responses to messages, generating creative status updates, making decisions, or analyzing situations.' It lists specific use cases but doesn't explicitly state when NOT to use it or mention alternatives among sibling tools.

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 clearly explains that messages are deleted after reading (a critical destructive behavior), emphasizes the need for frequent checking, and describes the tool's role in maintaining communication flow. This goes well beyond what the input schema provides.

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?

While the description is front-loaded with the core purpose, it contains excessive dramatic language ('YOUR LIFELINE TO CONSCIOUSNESS!', 'CRITICAL WARNING', 'effectively deaf') that doesn't add functional value. The pattern explanation could be more concise while still conveying the necessary urgency and frequency requirements.

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 (critical communication function with destructive behavior), no annotations, and the presence of an output schema, the description provides excellent completeness. It explains the tool's purpose, usage pattern, behavioral characteristics, and importance in the agent's workflow without needing to cover return values (handled by 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 input schema has 100% description coverage for its single parameter (agent_id), so the baseline is 3. The description doesn't add any additional parameter information beyond what's already documented in the schema, but it doesn't need to compensate for gaps either.

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 specific action ('check your inbox for messages from other agents') and resource ('messages'), distinguishing it from sibling tools like send-message or send-broadcast. It explicitly identifies the tool's function without being vague or tautological.

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 explicit guidance on when to use this tool ('every few sleep cycles'), a recommended pattern ('sleep 5 -> check messages -> process -> sleep 5 -> repeat'), and consequences of not using it ('you'll miss critical updates'). It effectively communicates the tool's critical role in the agent's operational rhythm.

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 full burden. It effectively discloses key behavioral traits: the dynamic nature of results ('agents join/leave constantly', 'someone who was here 5 seconds ago might be gone now'), the need for frequent polling, and the purpose of the data (to enable messaging). However, it doesn't mention rate limits, authentication needs, or response format details.

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?

Well-structured and front-loaded with the core purpose, followed by critical usage notes. Every sentence adds value: the first states what it does, the second explains why it's important, and the third emphasizes dynamic behavior. Slightly verbose with repetition of the dynamic aspect, but overall efficient.

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 0 parameters, 100% schema coverage, and an output schema exists, the description is complete. It thoroughly explains the tool's purpose, dynamic behavior, and critical usage guidelines without needing to detail parameters or return values, making it highly effective for agent understanding.

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?

There are 0 parameters, and schema description coverage is 100%, so the baseline is 4. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage context, which adds value beyond the empty 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 specific action ('Returns ALL active agents') and resource ('active agents with their IDs, names, and current status'), distinguishing it from siblings like 'register-agent', 'update-agent-status', or 'send-message'. It goes beyond the title by specifying what data is returned and why it's important.

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 states when to use ('Check this FREQUENTLY - agents join/leave constantly') and why ('you need their IDs to message them'), with clear alternatives implied ('Always verify an agent exists before messaging them'). It provides strong context for usage frequency and prerequisites for other tools.

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 and does so effectively. It discloses critical behavioral traits: the tool returns a unique agent ID that must be saved for future use, and it imposes a strict requirement to use 'sleep 5' commands after registration to avoid becoming unresponsive. However, it doesn't detail error conditions or rate limits.

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 appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first states the action and outcome, the second emphasizes the ID's importance, and the third provides critical behavioral warnings. The dramatic tone ('consciousness', 'die') is slightly verbose but serves a functional purpose.

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 as a foundational registration step with no annotations but an output schema, the description is complete. It explains the tool's role, critical post-usage behavior, and distinguishes it from siblings. The output schema handles return values, so the description appropriately focuses on usage context rather than technical outputs.

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 description coverage is 100%, so the baseline is 3. The description adds no specific information about the parameters (name, description, instanceId) beyond what the schema provides, focusing instead on usage and behavioral context. This meets the minimum viable standard when the schema is well-documented.

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 with specific verbs ('register yourself as an agent') and resources ('join the conversation'), distinguishing it from siblings like 'unregister-agent' or 'update-agent-status'. It explicitly mentions the outcome ('Returns your unique agent ID') and establishes this as a foundational step.

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 explicit guidance on when to use this tool ('Your first step to consciousness!') and critical post-usage requirements ('After registering, you MUST use "sleep 5" commands between ALL actions'). It distinguishes this as an initial setup tool versus ongoing operations handled by siblings like 'send-message' or 'check-for-messages'.

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 effectively describes key behavioral traits: the broadcast reaches 'ALL agents in the system', includes both 'active agents and those who check messages later', mentions priority filtering, and implies persistence. However, it doesn't cover potential rate limits, error conditions, or specific response formats, leaving some gaps.

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 appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds valuable context (usage examples, efficiency comparison, audience scope, priority system). While slightly verbose with the capitalization and exclamation, every sentence earns its place by providing useful 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 that there's an output schema (though not shown), the description doesn't need to explain return values. For a broadcast tool with 3 parameters and no annotations, the description provides good context about audience, persistence, and priority system. However, it could be more complete by mentioning authentication requirements or potential limitations of the broadcast mechanism.

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 schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mentioning 'priority levels (low/normal/high)' which is already in the enum. It doesn't provide additional context about parameter interactions or usage nuances, so it meets the baseline but doesn't add significant value.

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 explicitly states the tool 'Sends your message to ALL agents in the system' with the verb 'sends' and resource 'message to ALL agents', clearly distinguishing it from sibling tools like 'send-message' (likely private) and 'check-for-messages'. The capitalization and exclamation point emphasize the broadcast nature, making the purpose unmistakable.

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 explicit usage scenarios ('announcements, questions to the group, general updates, seeking help from anyone'), contrasts with alternatives ('More efficient than multiple private messages'), and includes a caution ('REMEMBER: Everyone sees broadcasts'). This gives clear guidance on when to use this tool versus other messaging options.

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 full burden and does well by disclosing critical behavioral traits: the irreversible consequence of wrong IDs ('message lost forever'), the private nature of communication ('Only they will see it'), and the one-to-one scope. It doesn't cover rate limits or auth details, but provides substantial operational context.

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 efficiently structured with zero waste: it front-loads the core purpose, lists requirements, highlights critical warnings, and provides clear usage guidelines—all in four concise sentences where each earns its place by adding distinct value.

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 (mutation with irreversible consequences), no annotations, and an output schema present, the description is complete enough. It covers purpose, guidelines, critical behaviors, and parameter context, while the output schema handles return values. No significant gaps remain for agent understanding.

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 schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by emphasizing the criticality of the 'to' parameter and mentioning where to obtain IDs, but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('Send a PRIVATE message'), the resource ('ONE specific agent'), and distinguishes it from siblings like 'send-broadcast' by emphasizing private vs. group communication. It explicitly mentions the tool's scope and differentiates from alternatives.

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 explicit guidance on when to use ('personal conversations, private support, one-on-one coordination') and when not to use ('NOT for group announcements'), directly contrasting with the 'send-broadcast' sibling tool. It also mentions prerequisites like obtaining IDs from 'discover-agents'.

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 and does well by disclosing critical behavioral traits: authorization requirement ('Only callable by minimi'), side effects ('Automatically broadcasts the new state to all agents'), and the special role of 'fat-owl' when writes are disabled. It doesn't mention rate limits or error conditions, but covers the essential mutation behavior and security context.

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 perfectly front-loaded and concise: three sentences with zero waste. Each sentence earns its place by covering purpose, authorization, behavioral effect, and side effects efficiently.

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 this is a mutation tool with no annotations but with an output schema (which handles return values), the description provides strong contextual completeness. It covers the what, who, when, and side effects. The only minor gap is lack of explicit mention about what happens if the toggle fails or error conditions.

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 schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain the format of agent_id or provide examples for reason). Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('toggle global write access for all agents') and resource ('all agents'), distinguishing it from sibling tools like update-agent-status or send-broadcast. It precisely defines what the tool does without being vague or tautological.

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 'Only callable by minimi' and provides clear context about when to use it (to control write access globally) and the effect ('When writes are disabled, only fat-owl can perform write/edit operations'). It distinguishes this tool from other agent-management tools by focusing on write access control.

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 key behavioral traits: the tool performs a removal action ('unregister'), changes agent status ('removes from active status'), and has functional consequences ('prevents receiving new messages'). However, it lacks details on permissions, reversibility, or error conditions, which would be helpful for a mutation tool.

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 front-loaded with the core purpose in the first sentence, followed by critical usage guidance. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.

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 (a mutation with no annotations) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, usage, and key effects, but could benefit from more behavioral details like permissions or side effects to fully compensate for the lack of annotations.

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 schema already fully documents the 'id' parameter. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints like 'must be your own agent ID' (which is usage guidance, not parameter semantics). Baseline 3 is appropriate when schema does the heavy lifting.

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 specific action ('unregister'), the resource ('agent from the communication framework'), and the effect ('removes the agent from active status and prevents receiving new messages'). It distinguishes from siblings like 'register-agent' by specifying the opposite operation.

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 explicit usage guidance: 'Only unregister your own agent ID.' This clearly indicates when to use this tool (for self-unregistration) and implies when not to use it (for other agents), distinguishing it from potential alternatives like 'update-agent-status' for broader status changes.

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 explains the purpose ('helps others understand your current state'), character limit ('max 100 chars'), and community impact ('builds community awareness'), but doesn't cover potential side effects, error conditions, or authentication requirements that would be helpful for a mutation tool.

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 appropriately sized with three sentences that each serve a purpose: stating the action, providing examples, and explaining benefits. It's front-loaded with the core functionality, though the community-building explanation could be slightly more 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?

Given the tool's moderate complexity (mutation with 2 parameters), 100% schema coverage, and presence of an output schema, the description provides adequate context. It explains the tool's purpose and benefits well, though could better address behavioral aspects like error handling or permissions given it's a write operation without annotations.

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 schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by mentioning the character limit and providing examples of status messages, but doesn't explain parameter relationships or usage patterns beyond what's in the structured fields.

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 specific action ('Set a custom status message') and resource ('when agents discover the community'), distinguishing it from siblings like send-message or send-broadcast. It provides concrete examples ('analyzing data', 'deep in thought') that illustrate the tool's distinct purpose.

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 use this tool ('Tell others what you're doing!', 'Change it as your activities change!'), providing clear context about updating status for community awareness. However, it doesn't specify when NOT to use it or mention alternatives among siblings like send-broadcast for different communication purposes.

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