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 only describes the creation action ('Create a capital account') but does not disclose any behavioral traits such as side effects, authorization needs, or what happens to existing data. The schema indicates name uniqueness, but this is not mentioned in the description.

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. It is front-loaded with the purpose and examples, with no wasted or 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?

For a simple creation tool with 3 parameters and no output schema, the description covers the purpose but lacks usage guidelines and behavioral transparency. Given no annotations, it is somewhat incomplete but still functional.

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 coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema; it only provides example account types. Baseline score 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 'Create a capital account' and gives specific examples (bank account, credit card, wallet). This distinguishes the tool from sibling tools that create other entities like add_category or add_contact, and from operations like remove_account or list_accounts.

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 implicit usage context through the examples, but does not explicitly state when to use this tool versus alternatives, such as when to use add_transaction or transfer_between_accounts. No when-not guidance is given.

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 provided. Description is minimal and does not disclose behavioral traits like uniqueness enforcement (though schema mentions it), idempotency, or permission requirements.

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?

Extremely concise single sentence, but could include more context without being verbose. Front-loaded with the essential 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 no output schema and no annotations, the description lacks completeness. It does not specify what the tool returns (e.g., created category object) or any side effects.

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 coverage is 100%, so baseline is 3. Description adds no additional meaning beyond the schema; it just restates the type enum.

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?

Description clearly states the tool creates a category specifically for income or expense, distinguishing it from sibling tools like add_account or add_contact.

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 guidance on when to use this tool versus alternatives such as remove_category or list_categories. No prerequisites or exclusion criteria mentioned.

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 exist, so the description must disclose effects. It only says 'Add a contact person' without mentioning side effects, required existing customer, duplicate handling, or success/failure behavior. This is insufficient.

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 sentences, no redundancy, front-loaded purpose, and each sentence adds value. Perfectly 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?

With 7 parameters, 3 required, and no output schema, the description provides only basic purpose. Missing guidelines, behavioral details, and any explanation beyond schema. Moderately incomplete but not critically lacking.

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 coverage is 100%, and the tool description adds no extra meaning beyond the schema's parameter descriptions. Baseline is 3 as schema covers parameters adequately.

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 states 'Add a contact person to a customer organization' with a clear verb, resource, and context. It further explains what contacts are, distinguishing it from other 'add_*' tools like add_account or add_customer.

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?

There is no guidance on when to use this tool versus alternatives such as search_contacts, update_contact, or other add tools. No when-to-use, when-not-to-use, or prerequisite information is provided.

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 full burden. It discloses that a conflict response is returned if similar customers exist and that skip_duplicate_check bypasses this. This provides good transparency for a creation tool, though it does not specify the success response or error handling beyond conflicts.

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 long, front-loads the purpose, and contains no unnecessary words. Every sentence adds essential 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 12 parameters (1 required) and no output schema, the description covers the primary use case, conflict behavior, and retry mechanism. It does not describe return values or error handling beyond conflicts, but this is sufficient for a creation 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the conflict resolution context for skip_duplicate_check but does not elaborate on other parameters beyond what the schema already provides. The conflict handling is the main added insight.

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 'Create a new customer record' and defines customers as organizations or individuals. It distinguishes from sibling tools by detailing the unique conflict detection and skip_duplicate_check behavior.

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 clearly states when to use this tool (to create a new customer) and provides guidance on handling conflicts, including how to bypass duplicate checks on retry. It does not explicitly compare with sibling tools but the context is clear.

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. It discloses that the tool creates a row with default access (no financial access, not an owner) and requires owner role. This is good, though it could mention behavior on duplicate user_ids or error conditions.

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?

Three sentences, front-loaded with the main action, followed by essential guidance. No extraneous 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?

For a tool with 3 parameters, full schema coverage, and no output schema, the description provides sufficient context: purpose, defaults, prerequisites, and pointers to related tools.

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 baseline is 3. The description adds context about default access (implicitly tying to the financial_access parameter) but does not elaborate on individual parameters beyond what the schema provides.

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 'Add a team member to the company' and specifies the creation of a company_members row with default access. It distinguishes from siblings by explicitly mentioning alternative tools for granting financial access (set_financial_access) and owner status (set_member_owner).

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?

Provides explicit guidance on when to use this tool (adding a member) and when to use alternatives ('Use set_financial_access...', 'Use set_member_owner...'). Also specifies the required role ('Requires owner role.'), giving clear usage context.

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?

Given no annotations, the description carries the full burden. It discloses that steps support {{placeholder}} syntax and are ordered, but it does not mention side effects (e.g., immediate creation, error behaviors, or interactions with playbook runs). Moderate transparency but lacks detail about post-creation effects.

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 three sentences, front-loaded with the core purpose. It is concise and avoids redundancy, providing necessary information without clutter.

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 13 parameters (4 required) and no output schema or annotations, the description covers high-level concepts (types, ordering, placeholders) but misses details like error handling, the deprecated assignee parameter, and state prerequisites. It is adequate but not comprehensive.

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%, providing solid baseline (score 3). The description adds value beyond the schema by clarifying ordering semantics ('append by using a value higher than existing steps') and the distinction between step types. This extra context moves the score to 4.

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: 'Add an ordered step to a playbook.' It distinguishes between two types (native_task and external_action) and mentions ordering by order_index. This differentiates it from sibling tools like update_playbook_step and remove_playbook_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 explains when to use each step type (native_task for tasks created in Founders OS, external_action for AI-instruction steps) and how ordering works. It does not explicitly state prerequisites (e.g., playbook must exist) or when not to use it, but the context is clear enough for typical 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 does not change status, which is key behavioral info, but does not mention other aspects like note appending behavior, authentication requirements, 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 two sentences, front-loaded with the action, and every word is necessary and 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?

For a simple add operation with two required parameters and no output schema, the description adequately covers purpose and usage context, though it omits details like character limits or overwrite behavior.

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 baseline is 3. The description adds no extra meaning beyond the schema definitions for 'task_id' and 'note'.

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 ('Add a progress note to a task') and explicitly distinguishes from siblings by specifying 'without changing its status', which differentiates it from tools like 'complete_task' or 'update_task'.

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 usage context ('useful for logging updates, blockers, or partial progress mid-task'), implying when to use it, but does not explicitly exclude scenarios or name alternative 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?

Mentions automatic balance update, which is beyond annotations (none provided). However, lacks details on permissions, error conditions, or return 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?

Two sentences with no redundant information. Efficiently communicates core purpose and a key usage 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?

With 8 parameters, no output schema, and no annotations, the description is too minimal. Does not address behavior for tags, customer_id, exclude_from_reports, or success/error responses.

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?

Adds clarity beyond schema by explaining sign derivation from category type. Schema already covers 100% of parameters, but description adds meaningful context for amount usage.

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?

Clearly states 'Record an income or expense transaction' with specific verb and resource. Distinguishes from siblings like 'add_account' or 'transfer_between_accounts' by focusing on transaction recording.

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?

Provides guidance on providing positive amount and sign derived from category, but does not explicitly state when to use this tool vs alternatives or any exclusions.

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. It discloses a critical behavioral trait: assigning replaces the current owner because a task has exactly one assignee ('one neck to grab'). It also explains how to unassign using an empty string. This goes beyond basic purpose to explain side effects. Lacks info on authorization (who can assign), but that's common and acceptable.

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 long, each earning its place. First sentence delivers the core action and options; second explains the design rationale and alternative usage. No fluff, perfectly 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?

Given the simple 2-parameter schema and absence of output schema, the description covers the essential aspects: what the tool does, how to specify assignees, and the behavioral consequence (replacement). It could optionally mention the return value (e.g., confirmation or updated task), but that is not required with no output schema, and the context signals indicate simplicity.

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% coverage with descriptions for both parameters. The description adds significant value by explaining the FOUNDERS_OS_USER_ID format, acceptable AI agent references ('@claude', '@gpt'), and the empty string for unassignment. It also reinforces the replace behavior, which is not fully captured in the schema alone.

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 action 'Assign or reassign a task' to a specific resource (task). It distinguishes from sibling tools like update_task by focusing solely on the assignee field, and it clarifies the one-assignee design, making the tool's 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 clear context on when to use the tool: to assign, reassign, or unassign a task. It also offers alternatives by suggesting others involved should be mentioned via @person tags or in the description, effectively guiding the agent away from misuse. However, it doesn't explicitly state when not to use it (e.g., for changing task fields other than assignee), which would have sealed a 5.

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 fully convey behavior. It mentions snapshots content and persistence beyond cache, but does not disclose authentication requirements or idempotency.

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 sentences, no redundancy. The first sentence states the purpose, the second provides usage instructions. Every word is necessary.

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 write tool with 2 parameters and no output schema, the description sufficiently covers input sourcing and persistent behavior. It could mention potential error cases or idempotency.

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 coverage is 100%, so baseline is 3. The description adds value by clarifying that 'feed_url' comes from 'get_feed_items' and that 'item_index' is 1-based, which is not in 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 specific verb 'Save' and specifies the resource 'feed item'. It clearly states the tool's purpose and distinguishes it from siblings like 'remove_bookmark' and 'list_bookmarks'.

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?

It explicitly instructs to use 'feed_url' and 'item_index' from 'get_feed_items', providing clear context. However, it does not state when not to use the tool or mention alternative 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?

Without annotations, the description fully bears the burden. It clearly states the tool is read-only ('does not write anything itself') and describes that it returns a procedure for the agent to execute, along with memory call and continuity info. This discloses the key behavioral trait of non-mutation.

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 moderately long but every sentence serves a purpose: stating the trigger, listing the returned procedure components, and explaining how to handle uncertain parameters. It front-loads the core purpose and usage, making it easy to scan. Slightly verbose but not wasteful.

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 no output schema, the description adequately explains what is returned (procedure steps, memory call, previous checkpoint). It covers all parameters with necessary context. While exact format details are omitted, the description provides enough for an agent to understand the tool's role and output.

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?

All four parameters have descriptions in the schema, but the description adds significant context: defaults for scope, detailed explanation of author vs 'anyone' with use-case rationale, instruction to ask user if project omitted, and timezone purpose. This goes beyond the schema's enums and short descriptions.

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 defines the tool as an end-of-session bookend paired with get_session_start, specifying its triggered by user phrases like 'checkpoint' and listing the exact steps it returns. This distinguishes it from sibling tools, particularly get_session_start, by its role as a session closer.

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?

Explicit guidance on when to call (user phrases) and what the agent must do after receiving the procedure (execute steps, ask for project tag if omitted). It also clarifies that the tool does not write anything itself, setting clear expectations for agent action. No direct alternative comparisons are needed given its unique purpose.

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 behaviors: marking done, optional notes, memory storage, unblocking tasks, conflict responses, and deprecated force parameter. It lacks details on idempotency (completing an already done task) and permissions, but covers the main actions well.

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 concise (4-5 sentences) and front-loads the primary action. Every sentence provides useful information without redundancy. The structure is logical: main action, optional features, special behaviors, and conflict handling.

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 no output schema, the description mentions that unblocked_tasks is returned conditionally. It covers the main use cases and conflict resolution thoroughly. Missing details like the exact response format for a successful completion or error messages, but overall adequate for selection and invocation.

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 coverage is 100%, but the description adds significant value beyond the schema. It explains the 'conflict' response context, clarifies the interaction between force and resolution, and advises AI agents to always provide completion_note. This enriches understanding of parameter usage.

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: 'Mark a task as done.' It includes optional actions like logging a note and storing as memory. The sibling list includes update_task and remove_task, and the description distinguishes itself by focusing on completion-specific behavior such as conflict handling and unblocking tasks.

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 guidance on when to use the tool (to complete a task) and how to handle conflicts ('if the task is blocked...') with options like force=true or resolution parameter. It does not explicitly state when not to use it or compare to alternatives, but the context is sufficient for selection.

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 provided, so description must cover behavior. It only states creation and definition of a playbook, but does not disclose side effects, authentication needs, idempotency, or error conditions. The mention of adding steps afterwards is mildly helpful but insufficient 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?

Two concise sentences front-loading purpose and then providing context and next steps. No unnecessary words 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?

Given no output schema and no annotations, the description is moderately complete. It explains what a playbook is and the creation workflow, but lacks details about initial state, reversibility, or permissions. Adequate for a simple creation tool but could be more informative.

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?

Input schema has 100% coverage with descriptions for all three parameters. The description does not add any additional meaning beyond what the schema already provides, so baseline score 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?

Clearly states 'Create a new reusable playbook template' with a specific verb and resource. Differentiates from sibling tools like add_playbook_step by noting that steps are added separately after creation.

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?

Implies usage by describing the workflow: create playbook first, then add steps. But does not explicitly state when to use this tool versus alternatives like run_playbook or update_playbook, nor does it provide prerequisites or exclusions.

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?

Discloses key behavioral traits: auto-creates a tag, returns conflict on duplicate slug, and requires confirmation. No annotations exist, so description carries full burden; it does well.

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?

Concise with 4-5 sentences, each contributing unique value: purpose, side effects, usage guidance, examples, confirmation. Well-structured and 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?

With no output schema and 3 parameters, description covers purpose, side effects, usage triggers, and confirmation behavior. Missing return value details but adequate for the tool's simplicity.

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 coverage is 100%, so baseline 3. Description adds context that 'name' leads to slug-based conflict, but does not elaborate on 'status' or 'description' beyond schema. Meets minimum but adds limited extra meaning.

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?

Clearly states 'Register a new project' with specific verb and resource. Distinguishes from sibling tools like create_tag or create_task by focusing on project creation. Includes side effects and conflict behavior.

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?

Provides explicit when-to-use scenarios with example triggers ('I'm starting a new project called X') and instruction to always confirm. Does not explicitly state when-not-to-use, but conflict description implies pre-existing projects are not suitable.

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?

Discloses error behavior on duplicate slug, but no annotations are present. Missing details on success response, permissions, or side effects. Basic but not fully transparent.

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 concise sentences with no fluff. Front-loads the core 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?

Covers uniqueness constraint and error case. Lacks output schema and success behavior details, but acceptable for a simple creation tool with well-documented parameters.

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 coverage is 100%, so parameters are documented. Description adds context about slug uniqueness but introduces ambiguity: slug is not a schema parameter, implying it is derived from name. This may confuse agents.

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?

Clearly states it registers a new tag in the tag registry. The uniqueness constraint on slug distinguishes it from sibling tools like rename_tag and remove_tag.

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?

Implicitly indicates when to use (creating a new tag) and notes uniqueness constraint, but does not explicitly state when not to use or list 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?

With no annotations, the description carries full burden. It discloses scope defaults, assignment rules, linking behavior, and conflict response. It explains design rationale for single assignee. However, it doesn't mention auth requirements 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 relatively concise for its detail, front-loading the main purpose. Each sentence adds value, though it could be more structured. No wasted words.

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 description omits the full response structure (e.g., returned task object with ID). It only mentions 'conflict' field. For a create tool with no output schema, this is a gap. Parameter coverage is good, but output missing.

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 coverage is 100%, baseline 3. The description adds value by explaining the single-assignee philosophy, due_date_day validation, and blocked_by_task_id auto-status. It provides extra context 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 explicitly states 'Create a new task' and elaborates on scope, assignment, and linking. It uses a specific verb and resource, clearly distinguishing from siblings like update_task or assign_task.

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 guidance on when and how to use the tool, including scope options, assignment formats, linking, and conflict handling. It does not explicitly list alternatives but the context is clear.

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?

Discloses immutability ('immutable', 'Records cannot be modified or deleted') and lists covered domains. With no annotations, the description fully carries the burden and does so thoroughly.

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?

Concise, well-structured, and front-loaded. Every sentence adds value without 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 read-only tool with 9 parameters and no output schema, description covers purpose, behavior, and parameter context comprehensively. No 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 coverage is 100%, baseline 3. Description adds value by explaining domain categories and scope defaults, providing context beyond schema descriptions.

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?

Clearly states 'Read the immutable audit log for this company.' Verb 'read' and resource 'audit log' are specific. Does not explicitly differentiate from sibling read tools, but the resource is unique.

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?

Provides clear context on who can use each scope (owners vs members) and default behavior. No explicit when-not-to-use or alternatives, but no alternative exists for audit log.

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 carry the full burden. It discloses that related data is included but fails to mention any side effects, authentication needs, rate limits, or constraints on the returned data (e.g., recency of interactions, completeness of tasks).

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, information-dense sentence. It is concise, front-loaded with the action and resource, and contains no superfluous text.

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 retrieval tool with one parameter and no output schema, the description adequately conveys what the tool returns. However, it could be slightly more specific about the scope of 'recent interactions' and 'open tasks' to address completeness expectations.

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 coverage is 100% for the single parameter customer_id, which is fully described as 'Customer UUID' in the schema. The description does not add additional meaning beyond the schema, so the baseline score 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 ('Get') and resource ('a single customer'), and specifies the related data included (contacts, recent interactions, open tasks). It implicitly distinguishes from list_customers, which would return multiple customers without such detail.

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 usage for retrieving detailed customer info but does not explicitly state when to use this tool versus siblings like search_customers or list_customers, nor does it mention when not to use it. No alternatives are provided.

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 convey all behavioral traits. It discloses the presence of a 'render field with tiered rendering guidance' and instructs to check it before composing a reply. This is valuable context, though it does not address potential side effects or authentication requirements. Overall, it provides good transparency.

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 extremely concise: two sentences that front-load the main purpose and enumerate contents, then add a critical note about the render field. Every sentence serves a purpose with no repetition or 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 simplicity (two optional parameters, no output schema), the description adequately covers what the tool does and what the response contains. It mentions the key data fields and the special render field. It does not elaborate on response structure, but that is not required without an output schema. The description is complete for an agent to use 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?

The input schema covers 100% of parameters with clear descriptions. The description adds no additional meaning beyond what is already in the schema; it restates the window and timezone but not with extra detail. Score at baseline due to full schema coverage.

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 that the tool gets a CRM dashboard summary and enumerates the specific data included (total customers by type and phase, overdue tasks, recent interactions, upcoming tasks). The term 'dashboard summary' distinguishes it from sibling tools that focus on specific entities like get_customer or get_task.

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 usage when a broad overview of CRM metrics is needed, but it does not explicitly state when to avoid using it or suggest alternative tools. The context of sibling tools (e.g., get_feed_briefing, get_task_summary) provides indirect differentiation, but the description could be more explicit.

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?

Without annotations, the description discloses the behavior: it returns the entity record, open tasks, recent interactions, and linked transactions. It does not detail side effects, permissions, or recency timeframe, but the overall behavior is transparent enough for an agent.

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 sentences efficiently convey the tool's purpose and value. No extraneous words; every sentence earns its place.

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 no output schema, the description adequately explains what the tool returns and its overarching benefit. It could marginally benefit from mentioning output format or limitations (e.g., recency of interactions), but it is largely complete for agent decision-making.

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 coverage is 100% with both parameters fully described. The description adds no additional meaning beyond the schema, meeting the baseline expectation but not exceeding it.

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 gets a complete picture of an entity including its record, open tasks, recent interactions, and linked transactions. It specifies the verb and resource, and explicitly distinguishes from multiple separate calls, answering 'what's going on with X?'.

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 advises using this tool to replace multiple separate calls for a consolidated view, implying it should be used when a comprehensive snapshot is needed. While it does not list explicit when-not-to-use scenarios, the guidance is clear and contextually strong.

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 reveals that the tool returns one headline per tag, caps at 8, and includes a 'render field with tiered rendering guidance'. This goes beyond basic purpose to explain output behavior. It doesn't mention read-only nature but is implied.

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?

Four sentences, each adding unique value: core function, constraints, usage context, and response trait. No wasted words, front-loaded with purpose. Efficient and well-structured.

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 one optional parameter and no output schema, the description explains the output (headlines, capped, one per tag, render field). It could benefit from listing exact response fields, but the mention of 'render field' provides enough guidance for an AI agent to compose a reply. Sibling context is handled.

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 coverage is 100% with one optional parameter 'max_headlines'. The description adds meaning by stating 'capped at 8 total' and confirming the default, reinforcing the parameter's role in limiting output. It adds value beyond the schema's description.

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 verb ('Generate'), resource ('compact headline briefing from pinned feeds'), and constraints ('one headline per tag, capped at 8 total'). It distinguishes from siblings like 'get_feed_items' and 'get_session_start' by noting it is designed for the morning dashboard and only fetches pinned feeds.

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 'Designed to be included in get_session_start without slowing it down' and 'Only fetches pinned feeds', providing clear usage context. It implies when not to use (e.g., for non-pinned feeds or detailed feed reading), though it does not explicitly list alternative 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?

No annotations provided, so description carries full burden. It discloses that a numbered summary list is returned, but doesn't discuss edge cases like empty results or performance.

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 sentences: first states purpose and output, second gives usage guidance. Front-loaded and no excess. Every sentence earns its place.

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 3 params, no output schema, and no annotations, the description covers purpose, output details, and param usage. Could mention pagination (limit default) or empty list handling, but fairly complete.

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 covers all 3 params with descriptions. Description adds context: tag is for topic filtering, feed_id for specific feed, and implies default limit. Adds value beyond 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 tool fetches latest feed items, describes the return structure (numbered summary list with title, author, date, availability flag), and distinguishes from read_feed_item for full content.

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 tells when to use read_feed_item for full content. Explains filtering by feed_id or tag. No explicit when-not-to, but context is clear.

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 provided, so the description carries full burden. It discloses that it is a read operation and specifies permission roles, but does not describe the return value format or potential side effects, which 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 sentences with the purpose front-loaded. Every word earns its place, 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?

The description is comprehensive for a simple one-parameter tool, covering usage and permissions. It lacks detail on output, but given no output schema, the omission is acceptable.

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 coverage is 100% and the description restates the schema's explanation of the optional parameter. No additional meaning is added beyond what the schema provides, meeting the baseline.

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 it checks a user's financial access level, using a specific verb and resource. It implicitly distinguishes from sibling tools like set_financial_access and get_financial_summary by focusing on the check 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?

Provides explicit guidance: any user can check own access, owners can check others by passing target_user_id. No alternatives or when-not-to-use mentioned, but the role-based conditions are helpful.

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 full burden. It mentions a render field with tiered guidance, which adds behavioral context. However, it does not disclose side effects, auth requirements, or rate limits. The description 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?

The description is two sentences, front-loaded, and every sentence adds value. There is no fluff or repetition. It is an excellent example of concise documentation.

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 simple one-parameter schema and no output schema, the description covers the main purpose and a key behavioral note about the render field. It could be more complete by explaining the render field's content or error scenarios, but it is largely sufficient.

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 the single parameter 'timezone'. The tool description does not add any extra meaning beyond the schema, so it meets the baseline expectation but does not exceed it.

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 returns a financial snapshot (total assets, YTD income/expenses). It is specific and informative, but does not differentiate from sibling tools like get_pl_report or get_dashboard, which could also provide financial data.

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 guidance is provided on when to use this tool versus alternatives or when not to use it. The description only explains what it does, not the context for its 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 provided, so description fully discloses behavior: defaults, conflict handling on resume, render field in response. No contradictions.

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 paragraph with dense, valuable information. Slightly long but every sentence earns its place. Could be broken into bullets for readability.

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?

No output schema, but description mentions render field. Covers all necessary context: when to call, how to use each parameter, and response content. Complete for a retrieval 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?

Parameters have 100% schema coverage, but description adds significant value: explains default behavior, inference rules, and enumeration logic beyond schema descriptions.

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 verb 'retrieve' and resource 'checkpoint', specifying it's the caller's most recent checkpoint. It provides usage examples like 'what was my last checkpoint', distinguishing it from other tools.

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?

Explicit conditions for when to call, with example phrases. Detailed guidance on parameter usage: project only with resolvable context, author default, intent default, and disambiguation behavior.

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 states it 'fetches' data, implying read-only, but does not explicitly declare no side effects, permissions, or other behavioral traits. For a simple read tool, 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 sentences with no wasted words. The first defines the purpose, the second provides a usage guideline. Front-loads critical 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 a simple tool with one parameter and no output schema, the description covers what the tool returns (step list and connector requirements). It could mention the return format or confirm it's a single object, but it is largely complete.

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 coverage is 100% for the single parameter 'playbook_id'. The description does not add meaning beyond the schema, which already describes it as 'Playbook UUID or slug.'

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 verb 'fetch', the resource 'a single playbook', and what it includes ('full ordered step list and connector requirements'). This distinguishes it from siblings like list_playbooks (which fetches multiple) and get_playbook_run (a run, not the definition).

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 'Use before running to inspect what the playbook will do and which connectors it needs.' This provides clear context for when to use the tool. It does not name specific alternatives, but the context implies run_playbook for execution.

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 provided; description only states it fetches log and status. Does not disclose read-only nature, authentication requirements, or any side effects. Minimal behavioral insight beyond the name.

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 10-word sentence, no redundancy, directly states purpose. Efficient and 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 simple get-by-ID tool with one parameter and no output schema, the description is adequate but vague about the return format. Could hint at fields like status or steps.

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 coverage is 100% with description 'Playbook run UUID.' The tool description adds no additional meaning beyond what the schema already provides, so baseline of 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?

Description uses specific verb 'fetch' and resource 'execution log and status' for a playbook run. Clearly distinguishes from sibling tools like 'list_playbook_runs' (which lists runs) and 'get_playbook' (which fetches the playbook definition).

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 guidance on when to use this tool versus alternatives like 'list_playbook_runs'. No mention of prerequisites, context, or conditions that would help an agent decide.

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?

Without annotations, the description discloses key behaviors: exclusions, parameter interactions, unattributed bucket, and render field. It does not mention permissions, rate limits, or data freshness, but for a read tool the disclosure is substantial.

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 four sentences with no filler. It front-loads the main purpose, then adds critical nuances. Every sentence earns its place.

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 no output schema, the description explains the key output aspects (category breakdown, optional by-customer rollup, render field). It could detail the return fields more, but the render field guidance compensates. Adequate for the 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the interplay between customer_id and group_by_customer, and the unattributed bucket, which goes beyond the schema descriptions.

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 returns a profit & loss summary grouped by category for a date range. It uses specific verbs and resources, distinguishing it from generic list tools. Although a sibling 'get_financial_summary' exists, the description uniquely specifies grouping and report scope.

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 explains when to use customer_id vs group_by_customer and mentions the exclusion of certain transactions. It does not explicitly list when not to use the tool or contrast with siblings like get_financial_summary, but the context for parameter usage is clear.

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 describes the return structure well but does not explicitly state that the operation is read-only, nor does it cover authentication or rate limits. The grouping and recency detail is helpful.

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 one sentence, front-loaded with the primary action, and no redundant words. Every word adds 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 single parameter and no output schema, the description provides a detailed account of what is returned (project details, tag, tasks/customers with grouping). It is nearly complete, though it could mention any error conditions or limits.

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 single parameter 'project_id' has a brief description in the schema. The tool description adds no additional parameter semantics beyond the schema, which is already sufficient. Baseline of 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 states the tool retrieves a full project card including details, associated tag, and tasks/customers grouped by status. This distinguishes it from sibling tools like list_projects or get_project_history.

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 guidance on when to use this tool vs alternatives. While the purpose is clear, there is no mention of when not to use it or which other tools might be more appropriate for simpler queries.

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 provided, but description reveals behavioral traits: ordered newest-first, defaults to checkpoint entries, response includes a render field. It doesn't mention permissions or side effects, but as a read tool, the description is reasonably transparent.

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?

Concise yet comprehensive; every sentence adds essential information. Purpose is front-loaded, followed by usage, defaults, ordering, companion tool, and response guidance. No fluff 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?

Given no output schema, the description covers return format (render field), ordering, and default behavior. It distinguishes from a key sibling tool and provides enough context for correct invocation. Parameter documentation is complete via 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?

Schema coverage is 100%, but description adds value beyond schema by explaining the kind default and behavior, ordering, and the render field. This context helps the agent understand parameter implications without duplicating schema descriptions.

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 returns a chronological timeline of stored memories for a single project, with specific use cases like reviewing progress and assembling narratives. It distinguishes itself from sibling tool memory_recall by highlighting the chronological vs semantic difference.

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 ('review progress', 'answer where we left off') and contrasts with memory_recall ('chronological companion'). Provides defaults and options like kind='all'. Although it doesn't list all sibling tools, the guidance is sufficient for correct selection.

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 full burden. It discloses that the tool returns a list of tools to call (not data itself), mentions the rendering_contract and render fields, and warns about default behavior if client_capabilities is omitted. However, it does not specify any side effects or potential limitations.

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 somewhat lengthy but every sentence adds value. It fronts the purpose and usage, then covers parameters and response fields. Could be slightly more concise, but overall well-structured.

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 no output schema, the description explains return fields (rendering_contract, render) and parameter details well. It provides enough context for an agent to use the tool correctly, though it could mention if there are any error conditions or rate limits.

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 coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining that timezone is passed through to called tools, client_capabilities tiers mirror the rendering_contract ladder, and expected_contract_version is for version comparison. This enriches parameter understanding.

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 it returns today's date and a list of tools to call in parallel for a morning briefing. It distinguishes itself from siblings by noting it does not fetch data itself, making the purpose clear and unique.

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 usage instructions: use at the start of every session or when the user says 'start my day', 'catch me up', or similar. It also tells the user to read specific response fields (rendering_contract, render) before composing output.

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 full burden. It discloses the output includes days_stale, suggested triage action, and a render field with tiered rendering guidance. It does not mention auth or rate limits, but for a read-only tool this is acceptable.

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?

Three sentences front-load the purpose and key behavioral points. Every sentence adds value: what it returns, why use it, and a critical note about the render field. No unnecessary words.

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 description covers the output content and the render field, which is helpful for agent usage. With 3 well-described parameters and no output schema, it provides sufficient context for effective use, though some edge cases (e.g., empty results) are not addressed.

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 coverage is 100%, so baseline is 3. The description adds no new meaning beyond what the schema already provides (scope, timezone, max_age_days). The effect of max_age_days is implied but not explicitly tied to the 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 surfaces stuck, stale, and overdue tasks needing triage, specifying the three categories (untouched, blocked, overdue). This differentiates it from sibling tools like get_task or list_tasks, which serve broader task retrieval purposes.

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 usage for triaging tasks but does not explicitly state when to prefer this tool over alternatives or when not to use it. No guidance on prerequisites or exclusions, which is a gap given the number of 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?

No annotations provided, so description must disclose behaviors. It states the fetch includes linked entities and notes, but does not mention auth needs, rate limits, or any side effects. As a read operation, risks are low, but disclosure is minimal.

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 clearly states purpose and scope. No wasted words. Front-loaded with the verb 'Fetch'.

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?

No output schema exists, so description should explain return value. It mentions 'including all linked entities and notes' but lacks details on structure or fields. For a simple fetch, it is adequate but could be more complete.

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 has 100% coverage with description 'Task UUID.' The tool description adds no additional meaning beyond what the schema provides. 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?

Description clearly states 'Fetch a single task by ID' which is a specific verb+resource. It adds scope with 'including all linked entities and notes'. Distinguishes from sibling tools like list_tasks (multiple tasks) and get_task_summary (summary).

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 guidance on when to use this tool vs alternatives such as list_tasks or get_task_summary. Does not mention when not to use or provide any usage context.

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?

Discloses that response includes a 'render field with tiered rendering guidance', indicating non-trivial response structure. No explicit statement about side effects or read-only nature. Since no annotations are provided, the description could be more transparent about safety (e.g., read-only hint), but it is not misleading.

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?

Four sentences, each serving a distinct purpose: purpose definition, content listing, usage scenario, response handling. No filler or repetition. Front-loaded with key intent.

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 no output schema, the description adequately explains the summary content (sections) and the presence of a render field with usage guidance. Covers the tool's role as an orientation tool. Could mention data freshness or limitations, but is comprehensive enough for a summary 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?

Schema describes all 3 parameters with descriptions (100% coverage). The tool description does not add additional information about parameter meaning or usage beyond what the schema provides, so it meets the baseline without adding extra 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?

Description clearly states it returns a 'Dashboard-style summary of the task queue' with specific breakdowns (overdue, due today, upcoming, counts by status/assignee, AI tasks). Distinguishes from task listing tools like list_tasks by being a summary, and from get_task by covering multiple aspects. Explicitly mentions call at session start, reinforcing 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?

Provides explicit usage: 'Call at session start to orient on what needs attention.' Also instructs to check render field before composing reply. Does not mention when not to use or alternatives, but the clear recommendation suffices for typical scenarios.

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 carry the full burden. It states the tool returns a guide, but does not disclose any behavioral traits such as authentication requirements, rate limits, or side effects. Since it is a read-only operation returning a guide, the lack of detail is acceptable but could be improved.

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 long, front-loaded with the main action, and every sentence earns its place. It is concise and well-structured.

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 simplicity of the tool (no parameters, no annotations, no output schema), the description covers the purpose and usage context. However, it lacks specific details about the return format or structure, which would be helpful for 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?

The input schema has zero parameters, and schema coverage is 100%. The description does not need to add parameter meaning, and the baseline for 0 parameters is 4. It provides no parameter info, but none is necessary.

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 returns a detailed guide on using Founders OS, covering all six domains, surface tools, search protocols, workflows, and tips. It uses a specific verb ('Returns') and resource ('guide on how to use Founders OS'), and it is easily distinguished from sibling tools which are specific actions or queries.

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 when uncertain about how to approach a task,' providing clear guidance on when to use the tool. However, it does not mention when not to use it or suggest alternatives, though no other guide tool exists among siblings.

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?

Discloses semver-aware comparison, channel awareness, registry query behavior, and all status fields. No annotations provided, so description carries full burden and does well. Minor omission: no mention of network dependency.

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?

Description is a single dense paragraph; could be improved with bullet points for readability. Contents are relevant and front-loaded with primary 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?

Tool has 0 required parameters and no output schema. Description covers all relevant output fields and logic. No gaps noted.

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 coverage is 100% with a clear description of the single parameter. The description echoes the schema without adding new detail. 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?

Description clearly states 'Returns the running version of @ourthinktank/founders-os' and lists all returned fields. Unique among siblings; no other version 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?

Explicitly advises 'Call at session start' and provides guidance on how to interpret results (relay update steps). No alternative tools exist, so no when-not needed.

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 fully discloses behavior: it groups tasks by first tag, includes completion notes as quotes, optionally formats as LinkedIn draft, and includes a render field with tiered rendering guidance. No destructive actions are implied, and the description clearly communicates output handling instructions.

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 three sentences long, front-loading core purpose and behavior in the first two sentences. Every sentence adds value: purpose, key features, usage scenarios, and a critical note about the render field. No fluff or 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?

Given the tool has no required parameters and no output schema, the description adequately covers purpose, behavior, optional formatting, usage scenarios, and output guidance (render field). It is complete enough for an AI agent to understand what the tool does and how to use its response.

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 baseline is 3. The description adds global context (e.g., grouping behavior, LinkedIn option) but does not enhance per-parameter meaning beyond the schema's own descriptions. The schema already clearly defines each parameter, so the description provides minimal additional value for parameter understanding.

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: 'Completed-task retrospective for a given week.' It specifies the verb (get), resource (completed tasks for a week), and key behaviors (groups by first tag, includes notes, optional LinkedIn format). It distinguishes from siblings like get_task_summary and get_stuck_list by emphasizing the retrospective and weekly scope.

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 context for when to use the tool: 'Useful for weekly reviews, standup prep, and public updates.' However, it does not explicitly exclude alternatives or contrast with similar tools. The mention of checking the render field is a usage hint but lacks when-not-to-use guidance.

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 discloses that already subscribed feeds are skipped and a subset are pinned for the morning briefing, but does not mention whether the operation is reversible, any permission needs, or side effects like 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?

Two sentences, 25 words, front-loaded with the main action. Every sentence adds value: first states purpose, second adds behavioral details (skipping, pinning). 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 tool with no parameters and no output schema, the description covers the key aspects: what the tool does, what it skips, and what happens afterwards. It could mention that the list is predefined and not configurable, but overall it is sufficient.

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 no parameters, and schema coverage is 100%. The description does not need to add parameter details, and the baseline for 0 parameters is 4. The description is consistent with 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 tool imports a curated starter feed list covering multiple topics, and distinguishes itself from sibling tools like subscribe_feed (individual subscriptions) and refresh_feeds (updating existing). The verb 'import' and resource 'starter feed list' are specific.

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 use for initial setup (starter feed list) but lacks explicit guidance on when to use versus alternatives or when not to use. No mention of prerequisites or context like 'use when setting up a new account'.

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 discloses that duplicate links are silently ignored, which is a key behavioral trait. But it does not cover error conditions, side effects, or permission needs.

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?

Description is two sentences, front-loaded with purpose, and contains no unnecessary words. Highly 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?

For a simple tool with three parameters and no output schema, the description covers purpose and duplicate behavior. It lacks details on success response or error handling, but is largely complete.

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?

Input schema provides descriptions for all three parameters (100% coverage), so the description adds little extra parameter meaning. Baseline score 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?

Description clearly states the action 'Link a task to any FounderOS entity' and lists specific entity types, distinguishing it from sibling tools like unlink_task.

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?

Description mentions that a task can have multiple links and duplicates are silently ignored, providing context for usage. However, it does not explicitly state when not to use this tool or mention alternatives like unlink_task.

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 present, so the description must carry the behavioral burden. It implies a read-only operation but does not disclose whether archived accounts are included by default (handled by parameter), pagination, or idempotency. Adequate but not comprehensive.

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 that is front-loaded with the action and resource. No unnecessary words; every part adds 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?

For a simple list tool with 4 parameters and no output schema, the description is adequate but lacks details on return format, pagination, or error handling. The mention of 'current balances' partially compensates for missing 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?

Schema coverage is 100%, so baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides. The mention of 'current balances' is relevant to the tool's output but not to parameter semantics.

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 verb 'list', the resource 'capital accounts', and includes 'current balances' for specificity. It distinguishes from sibling list_* tools by naming a unique resource.

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 guidance is provided on when to use this tool versus alternatives like list_categories or list_transactions. The description does not mention any context or exclusion criteria.

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?

The description discloses that results are sorted newest first and lists the returned fields (title, summary, source feed, link). With no annotations, these details help agents understand the tool's behavior. However, it does not mention pagination behavior beyond the schema parameters.

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, no fluff. The key behavior and return fields are front-loaded. Every word adds 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 no output schema, the description adequately specifies return fields. It covers sorting and resource type. Could optionally mention user scope (e.g., 'your bookmarks'), but not essential 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?

Schema coverage is 100%, so the parameter descriptions are already provided. The description adds value by confirming the ordering context for pagination ('newest first'), which helps agents understand how offset works. No additional detail needed.

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 identifies the action ('list'), the resource ('saved feed item bookmarks'), and the ordering ('newest first'). It distinguishes from sibling tools like bookmark_item (create) and remove_bookmark (delete).

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 the tool is used to view bookmarks but does not explicitly state when to use it over alternatives or when not to use it. No exclusions or context about prerequisites are provided.

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 carry the full burden. It only says 'list,' which is inherently safe, but it does not disclose any behavioral traits (e.g., performance, authorization, rate limits) that would help an agent assess consequences.

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 sentence with no wasted words. It is appropriately concise, though it lacks depth.

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 no output schema and no annotations, the description is incomplete. It does not explain the return format, pagination, or what fields each category contains. For a listing tool, this information is crucial for proper invocation.

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% coverage with detailed descriptions for all 5 parameters. The tool description adds no additional parameter information beyond the schema, so baseline score 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 'List all financial categories' – a specific verb and resource. It also mentions optional filtering by type. However, it does not differentiate from sibling list tools (e.g., list_accounts, list_tags), which could cause ambiguity.

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 guidance is provided on when to use this tool versus alternatives. There are many sibling list tools, and the description does not specify when list_categories is the appropriate choice or when to avoid it.

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 provided, so description must cover behavior. It mentions paginated results, summary info, and a render field with tiered rendering guidance—helpful beyond a simple list. No contradictions.

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?

Three sentences: purpose, behavior (pagination/summary), and a notable rendering detail. No wasted words, front-loaded with the key action.

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?

No output schema, so description should explain returns. It conveys paginated results with summary info and a render field, sufficient for an agent. Could be more specific about summary fields but overall complete.

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 baseline is 3. The description adds minimal parameter info beyond 'optional filters', relying on the schema to detail each 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?

Clearly states 'List customers with optional filters', specifying verb and resource. Among many sibling list tools, this is distinctively about customers, aided by the tool name itself.

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 guidance on when to use this tool versus alternatives (e.g., search_customers, get_customer). The description implies it's for listing with filters, but no exclusions or alternative references.

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?

Discloses that items are soft-deleted, recoverable trash, and lists returned fields. Explains defaults and filtering. Does not mention authentication or rate limits, but for a read-only list operation, the description provides sufficient behavioral context beyond the absent annotations.

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?

Every sentence serves a purpose: main action, return data, defaults, usage, further guidance (render field). No fluff, well-structured with front-loaded purpose and progressive 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?

Fully covers all 4 parameters, explains return fields, ties to sibling tools (restore_item, purge_item), and mentions render field for rendering guidance. Adequate for a tool with no output schema and no 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 coverage is 100% with parameter descriptions. The description adds value by explaining defaults (days=7, include_demo=false), the effect of entity_type, and usage patterns (pass days to widen window). This enriches the agent's understanding beyond the schema alone.

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 lists recently soft-deleted items for the current company, specifying the purpose (user picks one to restore or permanently delete). It distinguishes from other list tools by targeting trash items and mentions what is returned (type, label, deletion time, auto-purge date).

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 describes when to use (list trash for recovery/permanent deletion) and default behavior (7 days, demo hidden). Provides guidance on how to adjust (days, entity_type, include_demo) and presents proper usage of results (present by label, not id, check render field). Context from siblings shows this is the only list-deleted tool, with restore/purge as next steps.

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 bears the full burden. It describes two modes and mentions prepending shared presentation rules when loading a demo. It does not disclose authorization or error handling, but the read-only nature and low risk mitigate this.

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 concise: three sentences that front-load the purpose, detail behaviors, and provide usage guidance. No superfluous content.

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 low complexity (one parameter, no output schema), the description fully covers what the tool does, the two modes, and the expected returns. It is complete for its scope.

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 coverage is 100% and the schema already describes the single optional parameter 'name'. The description reinforces the behavior but adds minimal new semantic information beyond what the schema provides.

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 defines the tool's purpose: returning interactive demo walkthroughs. It specifies two distinct behaviors (list all demos or load a specific demo) and distinguishes it from all sibling tools, none of which relate to demos.

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 call the tool: 'when a user asks about demos, wants to explore features, or is onboarding.' No alternatives are mentioned, but no sibling tools exist for demos, so the guidance is 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?

No annotations are provided, so the description must carry the full burden. It fails to mention default status filtering (non-done tasks), pagination via limit parameter, or result ordering. The behavior is under-disclosed.

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 with no fluff. However, it could front-load key information like default filtering, and is slightly too brief given the tool's complexity.

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 4 parameters, no output schema, and no annotations. The description's single sentence does not explain filtering, limits, or response structure, leaving the agent without sufficient context for correct invocation.

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 coverage is 100%, so every parameter is documented. The description adds no additional meaning beyond what the schema provides, meriting the baseline score of 3.

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 lists tasks linked to a specific entity, distinguishing it from general list_tasks and single get_task. However, it says 'all tasks' but the schema shows a default filter excluding 'done' tasks, causing minor inaccuracy.

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 guidance on when to use this tool versus siblings like list_tasks or get_task. The description implies entity-specific task retrieval but lacks any 'when not to use' or alternative suggestions.

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?

Without annotations, the description carries full burden but only mentions return structure. It does not explicitly state that the operation is read-only, requires no special permissions, or has no side effects. The agent cannot fully assess safety or behavioral impact.

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 sentences convey purpose, scope, and return value with no redundancy. Every piece of information is essential and 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?

No output schema is present, so the description should thoroughly explain return structure. It mentions 'feed metadata' and 'per-user tags and pinned status' but omits specific fields, pagination, ordering, or size limits. This is minimally 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?

Schema coverage is 100%, and the description reiterates the filtering options (tag and pinned_only) without adding new constraints or format details. It meets baseline but does not enhance understanding 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 clearly states the tool lists subscribed RSS feeds with optional filters, distinguishing it from siblings like list_accounts or list_bookmarks. The verb 'list' and specific resource 'RSS feeds' make 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 implies usage for listing feeds with optional filters but does not explicitly state when to use this tool versus alternatives like get_feed_briefing or get_feed_items. No exclusions or context for when not to use are provided.

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 implies a safe read operation ('Get interaction history') and mentions optional filters, but lacks disclosure on pagination, ordering, or error behavior. 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?

Single sentence that front-loads the core purpose and key features. No redundant words; every part earns its place.

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 7 parameters, no output schema, and no annotations, the description is too brief. It does not explain return structure, pagination, ordering, or what happens with invalid inputs. Incomplete for an effective tool usage.

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 baseline is 3. The description summarizes that there are optional date range and type filters, which is already evident from the schema. It adds minimal new meaning beyond the individual parameter descriptions.

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 verb 'Get' and the resource 'interaction history for a customer', and mentions optional filters. It distinguishes from sibling tools like log_interaction and remove_interaction by implying a read operation, but does not explicitly differentiate from other list tools.

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 guidance on when to use this tool versus alternatives (e.g., list_demos or other list tools). No context for when not to use or prerequisites.

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 full burden. It specifies the output (members with owner status and financial access level) and the access condition (any member), but lacks details on pagination or return format.

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 concise sentences with no wasted words. The key information 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 zero-parameter tool without an output schema, the description provides all necessary context: what data is returned and who can access it.

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?

No parameters exist, so the baseline is 4. The description adds value by explaining what the output contains, which compensates for the lack of parameters.

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 lists all team members with specific attributes (owner status, financial access level), distinguishing it from sibling tools like list_accounts or list_customers.

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 that any member can call this tool, but does not explicitly state when not to use it or mention 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 must carry the full burden. It only says 'List execution history' without details on behavior: no mention of read-only nature, ordering, pagination, or performance. The description is too vague to disclose important behavioral traits.

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 concise sentence with clear front-loading. No wasted words. Perfectly appropriate length for the information conveyed.

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 low complexity, the description omits crucial context: no mention of return format, ordering, or that this is a read operation. With no output schema, the description should be more informative. It is incomplete for tool selection.

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 coverage is 100%, so baseline is 3. The description merely restates that filtering is optional, adding no new meaning beyond the schema's per-parameter descriptions. Thus, it stays at baseline.

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 'List playbook execution history', which is a specific verb ('list') and resource ('playbook execution history'). It distinguishes from siblings like 'get_playbook_run' (single run) and 'list_playbooks' (playbooks), but does not explicitly name alternatives, so it misses the top score.

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 guidance on when to use or not use this tool vs. alternatives like get_playbook_run. There is no mention of prerequisites or context. The phrase 'Optionally filter by playbook or customer' hints at use cases but does not provide explicit usage rules.

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 full burden for behavioral disclosure. It states that archived playbooks are hidden by default, which is a key behavior. It also lists the returned fields, giving some structure. However, it does not mention pagination, ordering, or any rate limits, leaving minor gaps for a list 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?

Two concise sentences clearly convey purpose and a key behavioral detail. Every word adds value; there is 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 list tool with one optional parameter and no output schema, the description is mostly complete. It explains what is returned and the default filtering. Minor omissions: does not mention if the list is paginated or if there is a limit, but for typical small-scale playbooks this is acceptable.

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 coverage is 100%, and the parameter 'include_archived' is already well described in the schema. The description reinforces the default behavior but does not add new semantic information beyond what the schema provides, meeting the baseline.

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 ('List all defined playbooks') and the resource ('for this company'), and specifies the returned fields (name, slug, description, step count). This distinguishes it from sibling tools like get_playbook (single), create_playbook, or list_playbook_runs.

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 is for listing playbooks and mentions the archived filtering default. However, it does not explicitly contrast with alternatives like get_playbook (for a single playbook) or list_playbook_runs (for runs), nor does it provide guidance on when not to use it.

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 provided, so the description carries the full burden. It discloses that the tool returns task counts per project and flags #-prefixed tags without corresponding project records, going beyond a simple list. No contradictions.

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 sentences, no fluff. Front-loaded with the core action, then concisely adds key details. Every sentence earns its place.

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 no output schema, the description adequately covers return values (task counts, flagged tags) and default/optional filtering behavior. For a list tool with two params, this is complete and sufficient for an agent to understand usage.

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 coverage is 100% but the description adds value by explaining the default for 'status' (active) and the effect of 'include_all' (return all statuses). This clarifies behavior beyond the schema's enum and boolean definitions.

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 'List registered projects' with specific verb and resource. It distinguishes itself by mentioning default 'active projects only' and additional return data (task counts, flagged tags), setting it apart from sibling tools like get_project or list_playbooks.

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 explains default behavior (active projects only) and the effect of optional parameters (status filter, include_all). It does not explicitly state when not to use this tool or name alternatives, but the context is clear enough for a listing tool.

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 full burden. It implies a read-only operation and lists return fields, but offers no additional behavioral details like rate limits or authentication needs.

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 concise sentences: one describing what the tool does and returns, the other providing usage guidance. No filler, front-loaded with key 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?

For a simple list tool with two optional parameters and no output schema, the description covers purpose, return fields, and usage. It could mention filtering options, but schema covers those.

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 coverage is 100% for both parameters (scope, include_archived). The description adds no meaning 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 description clearly states the tool lists all registered tags for the current company and specifies the returned fields (name, slug, color, description). This distinguishes it from sibling tools like create_tag or remove_tag.

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 advises using this tool to see available tags before tagging tasks or customers, providing a clear use case. However, it does not mention when not to use it or alternatives like preview_tags.

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 the response includes a render field with tiered guidance, but does not mention pagination, performance, or read-only nature (though implied). Adequate but could be richer.

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 concise with five sentences, each serving a purpose. It front-loads the core purpose and adds specific guidance without 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?

Given no output schema and 15 parameters, the description covers default behavior, important filters, and response features. It lacks details on ordering or full response structure, but is largely sufficient for a 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?

Schema coverage is 100% with parameter descriptions. The description adds value by providing usage patterns (e.g., assigned_to='@claude') beyond the schema, helping the agent select parameters effectively.

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 'List tasks with rich filtering' and provides specific use cases (scope, entity_type+entity_id, assigned_to). However, it does not differentiate from the sibling tool 'list_entity_tasks', which may overlap in functionality.

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 guidance for common scenarios (omitting scope, filtering by entity, using '@claude' for AI queue). It does not mention when NOT to use this tool or compare with alternatives, but the provided context is actionable.

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