ChiefLab

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

No annotations provided, so description carries full burden. It discloses key behaviors: alias nature, IDE-native approval path, autoExecute behavior, legacy id alias, and the execution plan fallback. Could be more explicit about side effects (state modification) and permissions, but overall informative.

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 long but information-dense. Every sentence adds value, but structure could be improved with sections or bullet points. P74 markers add necessary versioning context but clutter 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?

Covers the functional flow well: getting actionId, calling approve, autoExecute vs manual fallback. However, lacks detailed description of the response structure (no output schema), leaving the agent uncertain about returned fields beyond brief mentions of executionPlan and proof ledger.

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 descriptions, but the description adds significant value beyond schema: explains the context of each parameter, P74 features, and the relationship to launch response. Provides guidance on when each parameter is required (e.g., platforms for autoExecute on social).

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 is an alias for chiefmo_approve_action and explicitly defines the verb 'approve' and the resource 'ChiefMO publish/send action'. It distinguishes from siblings like chieflab_execute_approved_action by explaining the autoExecute path.

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 specific when-to-use scenarios (e.g., user says 'approve <channel>', 'ship it') and context for looking up actionId. It differentiates between simple approve and autoExecute, but does not explicitly list conditions where this tool should not be used versus 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?

Describes it as an alias with same handler and response shape as chieflab_status, recovers loops with literal user commands. Discloses behavioral nuance about not blindly resuming unrelated loops. Without annotations, this is adequate for a read-like initialization 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 efficient sentences conveying purpose, usage, and an important exception. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, behavior, and an edge case. Relies on alias to chieflab_status for response shape, which is acceptable given sibling tool. Three optional parameters are well-documented 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 already provides full descriptions for all 3 optional parameters (100% coverage). The description adds no new parameter detail beyond what schema offers, but the usage guidance on comparing recovered loops adds marginal context. 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?

Clearly states it is an alias of chieflab_status and specifies its role as the first tool on an existing workspace session to recover open business loops. Distinguishes from siblings by its unique initialization 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?

Explicitly says 'Use as the FIRST tool' and specifies condition (workspace with existing activity). Also provides a critical when-not-to-use scenario: if recovered loop is unrelated to user's goal, start fresh instead of resuming.

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 the burden. It describes the output as a plain-English paragraph and implies a read operation, but does not explicitly state it is read-only, safe, or free of side effects. Lacks clarity on mutability and permissions.

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 three sentences, front-loaded with usage triggers, then output content, then sibling reference. No wasted words; highly efficient and 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 absence of output schema, the description explains the return value in detail (launch count, channels, etc.). However, it does not address edge cases like empty brains or required parameters, and the workspaceId is assumed but not explicitly noted as likely required.

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 50% (tenantId is described in schema, workspaceId is not). The description adds no parameter meaning beyond the schema, and the purpose of tenantId vs workspaceId is not clarified. For two parameters, more guidance would help the agent.

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 a plain-English paragraph summarizing what the per-workspace brain has accumulated' and lists specific content like launch count, top channels, etc. It distinguishes from sibling chieflab_brain_read by mentioning it provides raw structured data, making the purpose specific and differentiated.

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 'USE WHEN the user asks...' with example queries and pairs with an alternative tool for raw data. This gives clear context on when to use and when not to, satisfying the dimension fully.

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 fully discloses the filtering conditions (measurementDueAt <= now and measuredAt unset) and the returned fields. No annotations exist, and the description provides complete behavioral context for a read-only query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the usage directive, and includes return fields and pairing. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explicitly lists return fields and filtering criteria. It covers pairing and use case, making it fully complete for a query tool with optional 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?

Both parameters are optional and described in the schema (coverage 100%). The description does not add significant meaning beyond the schema, only stating they are optional filters. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'measurement queue inspector' to list actions ready for 24h readback. It differentiates from siblings by specifying it works regardless of execution method and pairs with chiefmo_post_launch_review.

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 WHEN the agent wants to know which executed actions are ready for their 24h readback' and contrasts with the cron-triggered tool, providing clear guidance on when to use this foreground tool vs waiting.

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 states the return values (pending/connected/failed) and implies read-only behavior via 'returns status', but does not explicitly declare side effects, error handling, or permissions. Since annotations are absent, the description mostly carries the burden, which it does adequately but not exhaustively.

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 immediately convey the use case and output format without any wasted words 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?

The description explains the return status values, compensating for the lack of output schema, but fails to document both input parameters properly. For a simple 2-parameter tool, this omission reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description only mentions 'connectionId' in passing without defining it, and completely omits 'workspaceId'. No parameter descriptions are added, leaving the agent uncertain about the optional workspaceId parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks connector status after an OAuth flow, specifies the resource (connector status) and verb (confirm/check), and distinguishes from siblings by providing a specific use case and example 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 'USE WHEN' followed by a precise condition (user just completed OAuth flow), and provides example user queries, leaving no ambiguity about when to invoke this 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?

No annotations provided, so description carries full burden. It explains that OAuth providers return an authorizeUrl and API-key providers return instructions. Could mention that it modifies workspace configuration, but adequately covers key behaviors.

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, front-loaded with the verb 'Connect', no redundant information. Every sentence 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 tool has one parameter and no output schema, the description explains the return behavior for different provider types and sets user expectations about errors. Complete for a connector 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?

Only one parameter with 100% schema coverage. Description adds context by listing specific providers and categorizing them (OAuth vs API-key), going beyond the schema's simple enumeration.

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 connects a third-party provider to the workspace, lists specific providers, and distinguishes between OAuth and API-key types. This is a specific verb+resource, and it differs from siblings like chieflab_set_provider_key.

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: 'USE WHEN the user wants to wire up publishing, email sending, or analytics readback.' Also explains outcomes for provider types and warns that without this, other tools return errors.

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 must carry the full burden. It reveals that the default response is summary-sized and that 'full' is for debug/export, providing some behavioral context. However, it does not disclose whether the tool is destructive, what authentication is needed, or any rate limits, leaving gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-organized paragraph. It front-loads the main action, then provides usage conditions, default behavior, and a caution. Every sentence adds relevant information 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, the description mentions that the response includes 'reviewUrl + action ids' but does not detail the full response structure or potential errors. For a tool that can surface multiple action types, more completeness would help the agent handle outcomes.

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 clarifying the usage of 'runId' (links to previous tools), the optional nature of 'workspaceId', and the distinction between 'responseShape' and 'includeFullArtifacts' with a caution about the latter. This 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?

Description clearly states the verb 'Resume', the resource 'ChiefLab launch loop', and the identifier 'runId'. It distinguishes itself from sibling tools like chieflab_launch_product and chieflab_get_users_after_build by specifying it is for continuing an existing loop, not starting one.

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 'USE WHEN' and lists the preceding tools, giving clear context. It also provides guidance on when to use the default 'summary' vs 'full' response, which helps the agent make correct decisions.

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 present; description fully details behavior: status='awaiting_approval', inline draft body, executionMatrix, and that it uses same approve/revise/reject flow as other cards.

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?

Front-loaded with a clear one-line summary, then expands systematically. Every sentence adds essential info 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?

No output schema, but description explains what is created (action entry with status, draft, matrix). Also ties into sibling tools for approval and execution, making the overall process clear.

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 value by explaining runId chains launches, channel grounds suggestion, metrics is same as suggest function. WorkspaceId noted as optional.

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 verb 'turn' and resource 'Next Move suggestion' into 'approval-gated draft action'. Distinguishes from sibling tools like chieflab_suggest_next_move and chieflab_approve_action.

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 precondition: call after chieflab_suggest_next_move when suggestion kind is not 'wait' or 'noop'. Also describes the reviewer flow and closure of the loop.

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 explains the behavioral flow: creates an open work request, then once an offer is submitted, the requester reviews and accepts via chieflab_accept_offer (which creates an approval-gated action for the spend). It does not disclose potential side effects, authorization needs, or timeouts, but the core lifecycle is 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?

The description is well-structured, starting with 'USE WHEN' to front-load the use case, then explaining the workflow and parameter hints. Every sentence serves a purpose without being overly verbose. It could be slightly more concise, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, nested objects, no output schema), the description covers the tool's purpose, when to use, and workflow. It lacks return value description, but for a creation tool without output schema, the description is fairly complete. It explains the lifecycle and parameter usage well.

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 86%, so the schema already documents most parameters. The description adds value for 'brief' (suggesting specificity improves offers) and 'capabilityNeeded' (advising to search first). This is helpful but not substantial beyond the schema. 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's purpose: 'USE WHEN your operator hits a gap... Creates an open work request.' It uses a specific verb ('create') and resource ('work request'), distinguishes the tool's function from siblings by describing the workflow and mentioning the dependent tool chieflab_accept_offer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'USE WHEN your operator hits a gap it can't fulfill itself and wants to route the work to another operator.' It also advises calling chieflab_search_capabilities first if unsure about the capability slug. However, it does not explicitly state when not to use this tool or 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?

Discloses routing behavior, sanity gate execution, result capture, proof writing, and followup scheduling. With no annotations, the description carries the full burden and covers most side effects, though it could explicitly mention whether the operation is irreversible or if it modifies the action's status.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with 'P71 — closed-loop executor wrapper' and structured logically (purpose, conditions, internal steps, special cases). It is verbose but each sentence adds necessary detail for an AI agent; 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?

Given the complexity (6 parameters, no output schema, missing annotations), the description is comprehensive. It explains the workflow, routing, sanity gate, proof writing, followup, and edge cases for manual_handoff and blocked actions. It could be improved by describing the return shape more explicitly, but overall it is very 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%, so baseline is 3. The description adds some value by explaining when parameters are required (e.g., platforms required for social unless default mapping, recipients for email unless stored) and that mediaUrls are uploaded to CDN. However, the schema descriptions already provide good detail, so the added meaning is moderate.

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 is a closed-loop executor wrapper for approved actions, routing to specific executors (chiefmo_publish_approved_post for social, chiefmo_send_approved_email for email) and distinguishing from manual_handoff and blocked actions. It precisely identifies the verb (execute) and resource (approved action) with scope (oauth_connector or api_key_connector modes).

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: 'USE WHEN chiefmo_approve_action just succeeded on an action whose executionMatrix.mode is oauth_connector or api_key_connector AND connectorReady is true.' Provides alternatives for manual_handoff (chieflab_record_manual_publish) and blocked actions (connector-wiring instruction).

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 authorization requirement (CHIEFLAB_ADMIN_TOKEN), refusal condition (already measured), and default parameter behavior. Missing details on return values or success/failure indicators, but for a force action this is adequate.

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 concise (4 sentences) and well-structured: purpose first, then use cases, constraints, and parameter details. Every sentence provides 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?

Given no output schema, the description lacks info on return values or error handling. However, it covers prerequisites, authorization, and edge cases (already measured, default time). Minor gap for a mutation 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 description adds meaning: explains proofId derives from specific sibling tools, adminToken must match env var, optional dueAt defaults to 'now - 60s'. This goes beyond schema annotations.

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 forces a measurement_due_at into the past for triggering cron, specifying the verb 'forces' and resource 'proof_ledger row'. It distinguishes itself from sibling tools by labeling it an 'admin escape hatch' and referencing related tools like chieflab_record_manual_publish.

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 usage guidance provided: 'USE WHEN smoke testing the launch → measure → next-move chain without waiting 24h, OR an ops user needs to retry a stuck measurement.' Also states it refuses if row already measured, giving clear when-not-to-use.

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

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

With no annotations, the description carries full burden. It states the tool returns a 'full machine-readable profile' and lists fields, implying it is read-only and non-destructive. However, it does not disclose authorization needs, side effects, or potential issues. Adequate for a simple get operation but could be more 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?

The description is extremely concise with only two sentences. It is front-loaded with the usage condition and clearly states the purpose. Every sentence adds value with 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?

Given the tool's simplicity (2 params, no output schema), the description is fairly complete: it explains when to use, what it does, and what to expect. It lacks detail on error handling or parameter validation, but overall it provides sufficient context for an agent.

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 0%, so the description must compensate. It mentions 'operatorId + capability' but does not define their format, constraints, or provide examples. The schema only specifies type string with no descriptions, leaving ambiguity about what values are valid.

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 resource 'capability', specifies the exact inputs (operatorId + capability), and lists the returned information (inputs, outputs, pricing, etc.). It distinguishes itself from sibling tools like chieflab_create_work_request by positioning itself as a pre-flight check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'USE WHEN you have a specific operatorId + capability.' It also notes the tool is a pre-flight check before chieflab_create_work_request, giving clear context. It does not explicitly mention when not to use or alternatives like search_capabilities, but the guidance is still 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?

No annotations are present, so the description bears full responsibility. It correctly indicates no destructive behavior (read-only) and outlines the return shape. However, it lacks details on authentication, rate limits, or edge cases that would raise 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?

Two sentences that efficiently convey purpose, return structure, and usage context. Every word earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one optional parameter and no output schema, the description covers all key aspects: what it does, what it returns, and when to use it. No omissions for its complexity level.

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 'workspaceId' is fully described in the schema (100% coverage). The description adds no additional semantics 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 uses a specific verb ('read') and identifies the resource ('workspace's stored company profile'), with a clear return structure. It distinguishes from the sibling 'chieflab_set_company_profile' by its read-only nature.

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: 'before launch to confirm what ChiefLab will ground in.' This provides actionable usage context, though it does not explicitly exclude other 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?

Describes read operation and return shape, but does not clarify behavior when workspaceId is omitted or discuss authorization or rate limits. No annotations provided.

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: first states purpose and return, second provides usage context. No redundant text, 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?

Covers purpose, return shape, and practical use case. Lacks explanation of returned fields and error conditions, but adequate for low-complexity 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 workspaceId described as optional. Description adds no new parameter details beyond what 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?

Clearly states verb 'read' and resource 'workspace's stored publishing target defaults'. Returns specific structure, distinguishing it from sibling setter 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 use before launch to check defaults, preventing blocking auto-execute. Mentions setting counterpart, but lacks explicit when-not-to-use.

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

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

With no annotations, the description carries the full burden. It details the tool's effects: creating launchPack, signed reviewUrl, approval-gated actions, 24h measurement, memory, next move, etc. It explains it's an agent-dependency tool. While it could be more explicit about side effects, the description is quite informative.

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 paragraph that is information-dense but well-structured, starting with purpose and usage. It could be broken into bullet points for readability, but the content is efficient and every sentence 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 tool's complexity (11 params, nested objects, no output schema), the description covers the overall process, outcomes (launchPack, etc.), and important context like gathering repoContext and response shape. It lacks explicit return value documentation but hints via responseShape parameter. 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 description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides (e.g., channels and outputMode have detailed schema descriptions). The description focuses on overall behavior rather than individual param details, so a 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 it is an alias for chiefmo_launch_product, specifies the exact scenario (after build/ship/deploy) and user queries that trigger its use, and distinguishes from siblings like chiefmo_diagnose_marketing. It provides a specific verb+resource: turning the product into a money/distribution loop.

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 'USE WHEN' conditions are given (after build, user asks 'get users', etc.). It instructs to gather repoContext first and provides a negative guideline ('do not use chiefmo_diagnose_marketing for a new product'). It also directs to route exactly like chiefmo_launch_product, clarifying sibling differentiation.

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?

Declares 'Cheap, no side effects,' assuring the agent about cost and safety. Describes return content (operator menu, workspace state, next action). No annotations exist, but description fully covers behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences pack essential information: purpose, priority, return values, and follow-up hints. No redundancy, front-loaded with key instruction.

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 with no output schema, the description is fully complete. It conveys what the tool does, when to use it, and what it returns.

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; baseline score of 4 is appropriate. Description adds no parameter info because none are 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 states the tool retrieves operator menu, workspace state, and next action. It explicitly identifies itself as the 'FIRST TOOL' and distinguishes from siblings like chieflab_launch_product and chieflab_post.

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 guidance: 'call before anything else when you don't know what ChiefLab does or where to start.' Also advises follow-up actions (chieflab_launch_product, chieflab_post).

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 must disclose behavioral traits. It only states returns events with filtering, but does not confirm read-only nature, side effects, permissions, or error behavior. This is insufficient for a safe tool invocation.

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 concise, front-loaded sentences with zero wasted words. Every sentence adds value: usage triggers, core functionality, and pairing advice.

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 moderate complexity (4 params, no output schema), the description does not explain the output structure, pagination behavior, or error handling. This leaves critical gaps for an agent to use the tool effectively.

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 75%, but the description adds no extra meaning beyond the schema for the three documented parameters. The workspaceId parameter lacks description in both schema and tool description, leaving a gap.

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 'returns' and resource 'engagement events' with example queries, clearly indicating what the tool does. It is distinct from siblings but does not explicitly differentiate from alternatives, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use (e.g., 'what came in from my launches?') and pairs with chieflab_draft_reply, providing clear context. However, it lacks explicit exclusions or alternative tools for unrelated 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?

With no annotations, the description must fully disclose behavior. It mentions approval-gating, composition of other tools, and a 24-hour measurement queue, but fails to state whether the tool is destructive, idempotent, or what operations it performs on data. Key traits like side effects and safety are omitted.

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 dense single paragraph that conveys necessary technical details. It is not overly long but lacks clear structure or bullet points, making it harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 params, nested objects, no output schema) and lack of annotations, the description is insufficient. It omits return value format, error conditions, prerequisites, and detailed behavioral boundaries, leaving significant gaps for an agent.

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 0% and the description does not explain any of the 10 parameters individually. While it alludes to concepts like 'repo-grounded positioning' and 'per-channel drafts', it does not map these to specific parameters, leaving their meaning unclear.

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 this is the primary launch orchestrator, specifying it as an end-to-end loop with repo-grounded positioning, per-channel drafts, and approval-gated publishing. However, it does not explicitly differentiate from sibling tools like chieflab_continue_launch_loop.

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 this is the main tool to use for launching a product (calls itself 'primary' and 'reference implementation'), but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name 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 provided, so description carries full burden. It states it returns 'kind + label' and implies it's a list operation (non-destructive). Lacks detail on side effects or auth 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 sentences, front-loaded with purpose, then usage, then return info. No 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?

Simple tool with no parameters; description covers purpose, usage, and output sufficiently. Could mention read-only nature, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema (100% coverage), so baseline is 4 per rule. Description correctly adds no param info 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?

Clearly states verb 'list' and resource 'specialist agents', and distinguishes from sibling tool chieflab_request_specialist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: when user asks about ChiefLab capabilities beyond launch posts or before calling chieflab_request_specialist. Could add when not to use but positive guidance is 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?

No annotations provided, so the description carries the burden. It discloses that the action flips to executed with metadata fields markedManuallyAt and executedManually=true, and the card disappears from Today's Loop. It does not mention irreversibility or permissions, but is otherwise 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?

Three sentences, front-loaded with purpose. Every sentence is informative and non-redundant. 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?

Three parameters, no output schema. The description explains the outcome (action executed, card disappears) and provides context for note parameter. It is complete 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 has 100% description coverage. The description adds context beyond schema: explains that the note is stored in metadata.markedManuallyNote for the brain to read later. This adds value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool marks a next-move action as completed when there's no URL. It uses a specific verb ('mark') and resource ('next-move action'). It also distinguishes from sibling tool chieflab_record_manual_publish.

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 when-to-use (when there's no URL to record, e.g., reply_to_commenters) and when-not-to-use (for moves with a URL, use chieflab_record_manual_publish). It explicitly names the alternative.

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 fully covers behavioral traits: it explains the internal process (parses item id, calls Firebase API), side effects (auto-creates next-move action), idempotency, and the lack of API key requirement. 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?

The description is a single dense paragraph that front-loads the primary action. It is efficient but could benefit from slight restructuring (e.g., bullet points for readability). No wasted sentences.

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 lack of output schema, the description should explain what the metadata.proof structure contains or what the return value is. It mentions side effects (creating a next-move action) but does not describe the outcome format, leaving a gap for an agent.

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 extra information about parameters (e.g., force is mentioned implicitly via 'Re-measure'), but it does not significantly improve 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 uses a clear verb-resource pair ('pull a Hacker News post's score + comments + top replies') and specifies the target (via publishedUrl). It distinguishes itself from sibling tools by focusing on HN measurement, unlike chieflab_measure_reddit for Reddit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use ('USE WHEN a published Hacker News action is ripe for 24h measurement') and explains the outcome-based behavior. It does not directly name alternatives or when-not-to-use, but the context is clear enough.

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 idempotency (unless force:true), auto-creation of next-move actions based on outcome (trending, engaged, downvoted), and that it uses the public Reddit API with no auth. This is comprehensive behavioral 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 a single paragraph of about 5 sentences. It is front-loaded with the main action and then logically proceeds to usage condition, technical detail, side effects, and idempotency. It is concise and informative, though slightly dense.

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 explains the core functionality and side effects well, but lacks explicit details about the return value or result format. Since there is no output schema, the description should ideally mention what the function returns or how the result is structured. It also omits error handling or edge cases.

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 beyond the schema: it explains that actionId must have a publishedUrl pointing to the Reddit post, and that force:true triggers a re-measurement. This adds meaningful value, justifying a score above 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 verb 'pull' and the resource 'Reddit post's score + comments + upvote ratio + top replies', and specifies it writes to metadata.proof. It also describes the side effect of creating next-move actions. The name and description distinguish it from its sibling 'chieflab_measure_hacker_news' as it is specific to Reddit.

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 a clear usage condition: 'USE WHEN a published Reddit action is ripe for 24h measurement.' It also explains that it parses subreddit and post id from the publishedUrl. However, it does not explicitly state when not to use it or mention alternative tools, but the context is sufficient for an AI agent to 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?

No annotations provided, but description fully discloses tool behavior: returns per-store object with fields kind, durable, tableExists, sampleQueryOk, rowCount, error, warning. Explains meaning of tableExists: false. 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?

Description is front-loaded with core purpose and usage scenarios, then return format. Concise for the information provided, though slightly dense.

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 core functionality, usage, and return format. However, missing parameter explanation, and output schema is absent. Adequate for a simple health check tool, but incomplete regarding the workspaceId parameter.

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 0%, so description must explain the single parameter 'workspaceId'. Description does not mention it at all, leaving the agent uncertain about its role or necessity. This is a significant gap.

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 verifies persistent stores (proof_ledger, publishing_targets, company_profiles) or confirms in-memory fallback. This specific verb+resource distinguishes it from sibling tools like chieflab_get_company_profile or chieflab_query_proof_ledger.

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 lists three scenarios: after SQL migrations, before launch, or when debugging data disappearance. Provides clear when-to-use guidance, though it does not explicitly state alternatives or when not to use.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool pulls engagement metrics (likes/comments/views/shares/follower delta) for posts in the launch run and returns per-account analytics, top posts, best-time-to-post, and a structured next-move recommendation. This provides good insight into its behavior, though it doesn't mention authorization 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 a single paragraph that front-loads the alias and use condition. It is informative and contains no fluff, but could be slightly more structured (e.g., breaking into when/inputs/outputs). However, it remains concise and effective for an AI agent.

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 4 parameters and no output schema, the description explains the return values (per-account analytics, top posts, best-time-to-post, next-move recommendation) and covers inputs and usage context. It is complete enough for an agent to understand what the tool produces and how to invoke it properly.

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% for all 4 parameters, each with adequate descriptions. The tool description adds value by explaining that runId comes from chiefmo_launch_product, accountIds defaults to all accounts in the launch, outputMode has two choices with default behavior, and lookbackDays defaults to 7 with max 90. This contextualizes the parameters 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's purpose: it performs a post-launch review by pulling 24h+ engagement metrics and recommending next steps. It distinguishes itself by specifying when to use (≥24h after chiefmo_publish_approved_post) and what it returns (analytics + recommendation). This aligns with a specific verb+resource: 'post_launch_review' and sets it apart from sibling tools like chieflab_suggest_next_move.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'USE WHEN ≥24h has passed since chiefmo_publish_approved_post fired and the user asks...' This provides clear usage context. It does not explicitly mention when not to use or alternatives, but the condition '≥24h' implies it should not be used earlier. This is sufficient for 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?

With no annotations provided, the description carries the full burden. It discloses the tool's behavior: it drafts a queue but does not execute without approval ('nothing fires without explicit human approval'). It mentions the return includes a signed reviewUrl and agentGuide block. However, it does not discuss error handling (e.g., invalid runId), rate limits, or authentication. Overall, it provides sufficient transparency for safe use.

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 paragraph that is well-structured. It starts with the alias and trigger condition, then explains the tool's function and output. It is detailed but not overly verbose. A bullet-point list could improve readability, but the current structure is adequate.

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 (all described) and no output schema. The description explains the return format ('draft queue + signed reviewUrl + the standard agentGuide block') and notes that actions land in awaiting_approval. This is sufficient for an agent to understand what to expect. It does not detail the structure of the draft queue or agentGuide block, but that is acceptable without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that the runId grounds the queue in 'this run's measurement + memory' and that horizon defaults to 'week (7-day mode)'. These contextual details help the agent select appropriate values.

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: 'turns one launch into a 7-day launch mode' by drafting a queue of follow-up actions. It specifies the trigger condition ('when the user has just published a launch...') and the output ('draft queue + signed reviewUrl + the standard agentGuide block'). The alias note ('chieflab_* alias of chiefmo_prepare_next_move') distinguishes it from sibling 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 usage conditions are provided: 'USE WHEN the user has just published a launch (or ≥24h post-launch) and asks 'what's next?', 'follow-up post?', 'iterate on this', 'plan day 2'. It describes the context (grounded in prior runId, brand voice, etc.) and that actions require human approval. No explicit when-not-to-use or alternative tools are mentioned, but the guidance is clear and actionable.

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 describes behavior: a strict approval gate that returns an error if not approved, and on success returns the live platform URL. It also mentions the underlying adapter (zernio) and that it's a money/external-system action. No missing critical details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured. It starts with the alias, then the purpose, then usage condition, approval gate behavior, and a warning. Every sentence provides useful information. It's not overly long but covers key points efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains both success return (live URL) and error return (reason and reviewUrl). It covers the 5 parameters, approval flow, and safety warnings. Could mention rate limits or idempotency, but overall is complete for a publish 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 baseline is 3. The description adds context beyond the schema: it explains 'content' is the final rendered text from the LLM, and tells where to get accountIds (chieflab_list_publish_accounts). This helps the agent understand parameter origins.

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 publishes approved social posts to a specific set of platforms (LinkedIn, X, etc.) and includes an alias note clarifying this is a renamed tool. The verb 'Publish' and resource 'social post' are specific, and the list of platforms distinguishes it from other publish 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?

The description explicitly says 'USE WHEN the user has approved a publishAction from chiefmo_launch_product' and warns 'never call this without an approved actionId'. While it doesn't name alternative tools for when the action is not approved, the condition is very clear. The warning about money/external-system action provides strong 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 provided, so the description must carry the burden. It discloses persistence behavior (Supabase vs. in-memory fallback) and outlines the return fields (artifact URLs, channels, execution modes, measurement state). It does not cover rate limits or auth details, but for a read-only query tool, this is sufficient.

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: the first introduces the tool, the second gives usage guidance and return context. No redundant words. Efficiently 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?

Covers usage, scope, persistence, and result fields. No output schema exists, so the description's mention of return fields helps. Missing details on error cases or empty results, but these are minor omissions for a query 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 parameters are already documented. However, the description adds value by summarizing the return content (artifact URLs, channels, etc.) and explaining the purpose of each parameter group (e.g., 'measurementDueOnly' described separately). This goes 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 states 'query the persistent proof ledger' and provides specific use-case examples ('what has ChiefLab actually shipped?', 'show me the launch history'). It clearly distinguishes this tool from siblings, none of which perform the same query function.

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 ('USE WHEN the user asks...'), but does not mention when not to use or list alternatives. The sibling tools do not include another proof ledger query, so the guidance is clear but could be more comprehensive.

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?

Since no annotations are provided, the description carries full burden. It discloses that it writes metrics, auto-classifies outcomes based on thresholds, and creates next-move actions. It mentions the force parameter for re-recording. However, it does not explicitly state whether the operation is destructive or if there are side effects beyond the force flag.

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 paragraph but dense with information. It front-loads the purpose and then details use case, behavior, and parameters. While not broken into sections, it is concise and contains minimal redundancy for the complexity involved.

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 mentions that it returns the metric schema for the channel. It covers all 4 parameters, including nested objects, and explains the auto-classification and next-move creation outcomes. It is complete for the tool's purpose.

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 channel-specific keys for metrics (e.g., x, linkedin, email) and clarifies that calling without metrics retrieves the schema. The force parameter's behavior is also explained.

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's a manual metric fallback for channels without public-API measurement (X, LinkedIn, etc.), distinguishing it from siblings like chieflab_measure_hacker_news and chieflab_measure_reddit. It specifies the verb 'record' and the resource 'manual metrics', with a specific use case.

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: 'USE WHEN a published action's channel doesn't have a public-JSON metrics endpoint (anything except hacker_news / reddit) AND the founder is ready to paste the visible numbers.' This clearly defines context and implies alternatives (automated tools for HN/Reddit).

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 carries the burden, disclosing all key behaviors: status flip, metadata settings, proof_asset persistence, and queuing of metrics readback. It clearly explains the tool's side effects and importance.

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 paragraph with a clear front-loaded usage condition. It lists actions efficiently, though some internal details (e.g., 'flips from approved to executed') could be trimmed. Still well-structured for the amount of 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?

Covers purpose, usage, and side effects well, but lacks description of return value or output, which is important since no output schema is provided. Also does not mention required permissions or prerequisites beyond referring to another 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 good descriptions. The description adds context (e.g., actionId from chieflab_use_manual_fallback, URL examples) but does not significantly enhance meaning beyond the schema. 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?

Clearly states the tool records a manual publish URL to maintain the measurement loop, distinguishing it from sibling tools like chieflab_publish_approved_post and chieflab_use_manual_fallback by specifying the precise post-fallback scenario.

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 uses 'USE WHEN' to specify the condition (after manual fallback and posting). Clearly describes the need (to feed back URL for closed loop) and consequence (lost measurement without it), 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?

No annotations are provided, so the description carries the full burden. It discloses key behaviors: pulls the existing brief for the actionId, merges the instruction, returns an updated brief for the LLM to render, and explains the multi-turn flow (revision increments, original brief preserved in history). This provides rich behavioral context beyond a simple function call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the usage trigger ('USE WHEN') and is concise at 4-5 sentences. Every sentence adds value: usage context, workflow steps, and behavioral notes on multi-turn coherence. 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 explains the full flow (pull, merge, return, render, commit) and post-conditions (increment revision, preserve history). However, it does not mention error cases or prerequisites (e.g., that the draft must already be published). Given no output schema, this is a minor gap.

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 75%, but the description adds significant meaning: it explains that instruction should be plain-English ('shorter', 'more casual'), body is optional if already rendered, and actionId comes from chiefmo_launch_product. This goes beyond the schema's descriptions and clarifies 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 explicitly states the tool is for redrafting a published draft when the user requests changes like 'make this more casual' or 'shorter'. It clearly identifies the verb (redraft) and resource (published draft), distinguishing it from sibling tools like 'chieflab_regenerate_visual_asset' which handles visuals.

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 starts with 'USE WHEN' and lists specific user phrases (e.g., 'make this more casual', 'shorter') that trigger this tool. It also provides follow-up steps (call chieflab_record_rendered_copy) but does not explicitly state when not to use it or exclude 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 provided, the description fully discloses the tool's behavior: it reads the original brief, calls produceVisualAsset, returns an asset shape, and does not persist. It also explains that providing assetId allows in-place swapping.

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 front-loaded purpose and usage, no extraneous words. Every sentence 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 12 parameters, no output schema, and no annotations, the description fully covers the tool's operation, return value, and decision points, making it complete for correct 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?

The description adds significant context beyond the schema, including default values for style and fidelity, explanation of how assetId is reused, and clarification that caller override for model defaults to the brief's selection. Schema coverage is 100% but description enriches 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 regenerates a single visual asset with different style/fidelity/headline, and specifies the exact use case (when a reviewer hits 'Regenerate'). It also distinguishes from siblings like chieflab_review_visual_asset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'USE WHEN a reviewer hits 'Regenerate' on a launch image' and notes that it does NOT auto-persist back to the run, providing clear guidance on when to use and what the caller must do afterward.

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 specialists are currently deterministic stubs (with future LLM-backed versions transparently replacing them) and that each request creates an approval-gated action. This provides useful behavioral context beyond the schema.

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 fairly long and contains some redundancy with the schema (e.g., listing kind-specific brief fields). While it is front-loaded with the main purpose, it could be more concise. A score of 3 reflects adequate but not excellent conciseness.

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 5 parameters, nested objects, and no output schema, the description provides good context: it explains the workflow (creates approval-gated action), mentions grounding via runId, and hints at the return value (structured briefs/plans/drafts). However, it does not explicitly describe the return format or the role of workspaceId, which prevents a perfect score.

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 some extra context (e.g., explaining the purpose of autoCreateAction and runId), but largely restates the schema's descriptions, especially for the 'brief' object. The added value is moderate, so a 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's verb ('delegate to a specialist agent') and specifies the resource (specialist tasks). It explicitly lists the kinds of tasks it handles (design, video, research, outreach, seo, analytics), distinguishing it from sibling tools like 'chieflab_list_specialists' which only lists specialists.

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 WHEN the launch needs more than copy' and enumerates the specific kinds of requests. While it does not provide explicit when-not-to-use or alternatives, the context is clear and sufficient for the agent to decide when to invoke this 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 the burden. It discloses that the tool returns whether the channel is ready or still blocked with the up-to-date connect path, implying a non-destructive check. However, it doesn't mention if there are any side effects or rate limits, which would improve 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 two sentences plus a usage note, front-loading the purpose and return value. No wasted words; every sentence 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 check tool with 2 parameters, the description covers purpose, usage, and return behavior. It lacks explicit output schema details but names sibling actions for follow-up. The workspaceId parameter is not addressed, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 50% of parameters (only actionId has description). The tool description adds meaning to actionId via the example 'from chiefmo_launch_product' but does not explain workspaceId at all. This is insufficient compensation for the low 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 the tool re-checks a blocked publishAction's connector readiness, with specific verb 're-check' and resource 'blocked publishAction'. It distinguishes from sibling tools by naming the related publish/send actions that follow, making its role 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 explicitly states when to use: 'USE WHEN the user has just connected a missing provider and the agent needs to know if the action can fire.' It also indicates what to do after (re-fire chiefmo_publish_approved_post or chiefmo_send_approved_email), providing clear 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?

With no annotations provided, the description carries full burden. It discloses that the tool reads the run's visualAssets list, updates the matching asset's status, persists to run metadata, and affects future loads and channel-media render. However, it lacks details on permissions, idempotency, or potential side effects like notifications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph. It front-loads the core action and context, then explains mechanics and companion tool. Every sentence adds essential information with no redundancy or 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 tool has 5 parameters with full schema coverage, but no output schema. The description explains the persistence effect but does not describe the tool's return value or response format. For a complete understanding, an agent would benefit from knowing what the tool returns (e.g., success message, updated asset object).

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 specifying that assetId comes from launchPack.channels[channel].media[*].assetId, that decision updates the status field, and that reason is stored for audit and brain memory. This context enriches 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's action (approve or reject a visual asset), specifies the types of assets (LinkedIn graphic, X image, etc.), and explicitly distinguishes it from the sibling tool chieflab_regenerate_visual_asset by noting the companion writes the decision while regeneration produces an updated shape without persisting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit context: 'USE WHEN a reviewer hits Approve or Reject on a launch image in the Launch Room.' It also mentions the companion tool for regeneration. However, it does not explicitly state when not to use this tool or list alternative tools for other actions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns active capability records ranked by recency, but omits details such as read-only nature, any side effects, or pagination. This is adequate but could be more 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 extremely concise: a single paragraph of about 50 words. It front-loads the usage context with 'USE WHEN' and provides examples and pairing advice. Every sentence adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description mentions returns but does not specify fields or behavior when no parameters are provided. With 100% schema coverage and no required params, it is minimally complete but lacks details on default output or paging.

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 descriptions already explain each parameter (tags as overlap filter, limit with default 25, capability as exact match). The description adds no new meaning beyond restating these, 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's purpose: searching for capabilities when an operator lacks one. It gives concrete examples and mentions returning active capabilities ranked by recency. However, it does not explicitly differentiate from sibling search tools like chieflab_list_specialists, so clarity is high but not perfect.

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 starts with 'USE WHEN' and specifies the context: when an operator needs a capability outside its scope. It also recommends pairing with chieflab_create_work_request for further action. No explicit exclusions are provided, but the guidance is clear and actionable.

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 action is irreversible ('once sent cannot be unsent') and involves money/external-system, and mentions the adapter and domain verification. However, it lacks details on failure modes or confirmation steps.

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 and front-loaded with the main action. It efficiently packs alias clarification, usage condition, prerequisites, and behavioral note into a single paragraph without unnecessary verbiage.

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 external and irreversible nature, the description covers key aspects: purpose, usage condition, prerequisites, and a critical behavioral warning. It references a sibling for shape, which adds completeness. Minor gap in error handling details.

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 high (86%). The description adds value beyond the schema by emphasizing the domain verification requirement for `from` and the recipient limit for `to`, which are not fully captured in 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 'Send an approved launch email' with specific verb and resource, and distinguishes from sibling tools like chieflab_publish_approved_post by noting it is for email send actions after approval from chiefmo_launch_product.

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 WHEN the user has approved an email publishAction from chiefmo_launch_product' and provides prerequisites like domain verification and checking chieflab_list_email_senders. It does not explicitly state when not to use, but the context is clear enough.

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 behavioral traits: it is a write operation that persists data, supports partial updates and null removal, and grounds subsequent launches. It also explains the historical context (P88) and the effect on launches.

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 well-structured: a concise one-line summary followed by context and usage details. Every sentence adds value. It is somewhat long but appropriate for the complexity; could be slightly trimmed without losing clarity.

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 the tool being a mutation, the description does not explain return values or success/failure indicators. It adequately describes inputs and effects but leaves agents guessing about the response, which is a gap.

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 parameters have schema descriptions (100% coverage), but the description adds significant extra meaning: it lists the specific fields the profile object may contain and how updates/removals work, which is not in the schema. This enriches the agent's understanding beyond the input 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 sets the workspace's persistent company profile. It uses specific verbs ('set') and resources ('company profile') and provides context about its role in the ChiefLab pipeline, distinguishing it implicitly from the sibling tool 'chieflab_get_company_profile'.

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 explains how to use the tool: 'Pass partial maps to update specific fields; pass null for a field to remove it.' It implies when to use it (once to store company facts). However, it does not explicitly state when not to use it or mention the alternative get tool, but the sibling context makes it 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 exist, so the description carries full burden. It discloses that keys are stored encrypted at rest and never leave the workspace. It also clarifies the financial implication (direct payment vs margin). The description does not mention whether storing overwrites an existing key, but overall it provides good behavioral context for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four efficient sentences with no fluff: action, benefit, provider list, security and removal. Every sentence adds unique value and is front-loaded with 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?

With no output schema, the description covers key behavioral aspects (encryption, workspace scope, removal alternative). It does not explicitly state return values or success confirmation, but for a simple store operation this is arguably sufficient. Slightly more detail on expected outcomes would make it a 5.

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 descriptions for all 3 parameters. The description adds value by listing all providers with examples (e.g., Gemini key starting with AIza), explaining optional workspaceId default behavior, and providing context (BYOK benefit) that clarifies why to use optional fields. This goes 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 stores a provider API key for the workspace, distinguishes between BYOK (no markup) and ChiefLab's key (with margin), and explicitly names sibling tool 'chieflab_revoke_provider_key' for removal. The verb 'store' and resource 'provider key' are specific and unambiguous, differentiating it from other chieflab 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?

The description explains when to use this tool (to bring your own key and avoid markup) and lists supported providers. It implicitly describes the alternative (using ChiefLab's key without this tool). More explicit exclusions or context-specific guidance would push to 5, but it is clear enough for an agent to 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?

No annotations are provided, so the description fully carries the behavioral disclosure burden. It reveals that storage may be in-memory (Vercel function lifetime) or persistent depending on wiring, and states the return format includes storage location. This is comprehensive and honest.

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 wasted words. It starts with a clear purpose (P79 — set...), then explains the 'why', then details parameter behavior, then storage and return. Front-loaded 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?

Given no output schema, the description adequately explains the return value (merged channelTargets + storage location). It covers purpose, parameter semantics, storage behavior, and usage nuance. No gaps for the tool's 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%, but the description adds value beyond schema by explaining that partial maps update specific channels (not in schema) and describing the return value format. The schema already mentions null removal, so description complements 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 verb 'set' and resource 'publishing target defaults' with scope 'per-workspace'. It explains why the tool exists (to avoid passing IDs on every call) and distinguishes it from the sibling 'chieflab_get_publishing_targets' (which retrieves).

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 says 'One-time setup per workspace' and implies this tool is for initial configuration or updates. It mentions partial maps and removal via null, guiding usage. However, it does not explicitly state when not to use it or compare to alternative tools, though context from sibling names suggests get_publishing_targets for reading.

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 the description fully discloses behavior: creates workspace, returns apiKey inline, delivery URL expires in 1 hour, single-use, IP-rate-limited. No login form. All critical traits covered.

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 packed with necessary info and well-structured with PREFERRED/FALLBACK labels. Slightly verbose but 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?

No output schema, but description explains return values (apiKey, deliveryUrl) and behavior (expiry, rate limit). Also covers error recovery and integration steps. Fully complete for a signup 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 baseline 3. The description does not add extra meaning beyond the schema; it just repeats optionality and defaults. No added value, but no deduction.

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 creates a workspace and returns an API key, and specifies the exact condition for use (no key, 401 error). It distinguishes itself from sibling tools by being the signup 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?

Provides explicit when-to-use condition (401 error, no key). Offers preferred and fallback flows with step-by-step instructions (write to MCP config, restart runtime, retry). Altogether clear 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 the full burden. It discloses that the tool flips action status to 'rejected' with metadata.skipReason and that the next-move generator reads skip reasons to avoid similar suggestions. This adds meaningful behavioral context beyond what would be inferred from the schema, though it omits details like reversibility or permissions.

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 wasted words. The first sentence states the purpose and the second explains the impact (brain learning). Each sentence earns its place, and 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?

Given no output schema, the description adequately explains the tool's effect (flipping action status, capturing reason) and how it integrates with the next-move generator. It could mention the return value or confirmation message, but the behavioral description is sufficient for an agent to understand the tool's role.

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 role of the 'reason' parameter: it helps the brain learn which moves to avoid. This goes beyond the schema's description, which only says 'Why the founder is skipping this.' The description also clarifies the outcome (flip to rejected with metadata.skipReason).

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 'rejects' and resource 'next-move recommendation', clearly distinguishing from siblings like approve or execute. It states exactly what the tool does: preventing a recommendation from being executed while capturing a skip reason.

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: when a founder rejects a recommendation. It provides context by stating the purpose (capturing reason for brain to learn) and effect on future suggestions. However, it does not explicitly say when not to use or 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?

Despite no annotations, the description fully discloses behavior: it recovers workspace state, is stateful and re-summonable, aggregates multiple data sources, and explains return structure and logic for comparing against current context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph with key info upfront. Informative but could be broken into shorter sentences or bullet points for easier scanning. Still efficient with no superfluous 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?

Complete for a session recovery tool: explains purpose, when to use, output structure, parameter usage, and stateful nature. No output schema, but description compensates with detail. Handles edge cases like lost conversation.

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 how to use currentRepoContext/projectName to compare recovered loops, and implies workspaceId usage, going 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 explicitly states the tool's purpose: 'SESSION-RECOVERY · FIRST CALL when a session starts...' and details what it returns (bootCard with specific fields). It distinguishes itself from sibling tools by emphasizing its role as the initial session recovery call.

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?

Clear when to use: 'FIRST CALL when a session starts and the user mentions launch / users / growth / ...' and when not: 'if the open loop is unrelated, start a fresh launch instead of resuming stale work.' Provides context for parameter usage.

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?

Despite no annotations, the description fully discloses behavioral traits: it is a 'Pure-function; same input → same output, no LLM,' meaning deterministic and side-effect-free. It also describes the output structure in detail (kind, priority, reasoning, draftBrief, measurementGroundingFacts), so the agent knows exactly what to expect.

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 well-structured and front-loaded: starts with the identifier 'P75 — Next Move Engine' and immediate usage condition. Every sentence adds necessary information without redundancy. It efficiently covers purpose, trigger, behavior, output format, and pairing with another tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and lack of output schema, the description provides a comprehensive view: input conditions, deterministic nature, output structure, and relationship to sibling tools. No gaps remain for an agent to understand when and how to use this tool effectively.

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 semantics of each parameter beyond the schema: runId 'grounds the suggestion' to actual product/market/audience, channel lists examples, and metrics 'accepts synonyms' like engagement/openRate. This extra context justifies a score above 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 tool's purpose: 'Next Move Engine' that suggests what the operator should do next after measurement. It specifies the trigger condition (measurement just came in) and distinguishes from sibling tools like chieflab_create_next_move_action by mentioning the pairing relationship. The verb 'suggest' and the resource 'next move' are specific and 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?

Explicit usage guidance: 'USE WHEN measurement just came in' with specific references to automatic firing of chieflab_post_launch_review or manual user call. It also tells what to do after obtaining the suggestion: 'Pair with chieflab_create_next_move_action to turn the suggestion into an approval-gated draft,' which provides clear next-step 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool returns paste-ready title+body, a checklist, measurement template, and optional upgradePath. It also states the prerequisite that the originating publishAction must already be approved on the reviewUrl. This transparency helps the agent understand side effects and 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?

The description is a single dense paragraph, but it front-loads the most important information ('USE WHEN...'). Every sentence adds value, though breaking it into bullet points or short sentences would improve readability. No extraneous content, but structure could be optimized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, multiple return components), the description is complete. It explains what the tool returns, the approval prerequisite, and how it fits into the broader workflow (ties to chiefmo_launch_product and chieflab_connect_provider). No gaps are evident.

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 the schema: it explains the origin of actionId from chiefmo_launch_product, lists channel options, and describes how subreddit and discordCommunity affect the brief. However, the description could be slightly more concise for 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?

The description clearly states the tool's purpose: to use a manual fallback when a launch action has a manualFallback brief. It specifies exactly when to use it (manual-only channels or automated channels without wired connectors) and distinguishes it from other tools like connecting a provider later. The verb 'use' and resource 'manual fallback brief' 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 provides explicit usage guidance: 'USE WHEN any launch action carries a manualFallback brief...' It details both scenarios (no automated provider or connector not wired), mentions the upgradePath for later automation, and notes the approval gate requirement. This helps the agent decide when to invoke this tool versus 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?

Describes the return object in detail, clarifies ambiguous fields (e.g., toolsDiscovered), specifies error behavior (nextStep on false ok), and explains parameter inference. Given no annotations, it provides substantial behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: starts with purpose, then usage, return fields, clarifications, and error handling. All sentences are necessary given the complexity of the return object.

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 purpose, usage, return structure with field explanations, and error recovery. Without an output schema, it provides enough detail for correct agent 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 schema already documents the single parameter with 100% coverage. The description restates the parameter's optionality and inference without adding new meaning 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 'POST-INSTALL HEALTH CHECK' and specifies the exact timing (call once after wiring ChiefLab). It distinguishes from sibling tools by its unique post-install role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call this exactly once after the agent has wired ChiefLab into the runtime' and references a bootstrap protocol. Provides clear context, though does not mention alternatives or when not to use.

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