ChiefLab

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

No annotations provided, so description carries burden. It explains the effect (allows executor to fire) and mentions alias. Could disclose more about side effects but adequate for a simple action.

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

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

Four sentences, front-loaded with alias and purpose. Slightly verbose in first sentence but each sentence adds unique guidance. Could be tightened slightly.

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

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

For a tool with no annotations, no output schema, and simple parameters, description covers when, how, and what parameters to use. Includes alias clarification and workflow steps.

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

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

Schema covers 100% of parameters; description adds value by specifying preferred parameter (actionId over legacy id) and provides context on how to obtain actionId from launch response.

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 approves a ChiefMO publish/send action, using specific verbs 'Approve' and 'fire'. It distinguishes from related tools like publish_approved_post and send_approved_email by describing the approval step.

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

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

Explicitly states when to use: when user says 'approve <channel>', 'approve all', 'ship it', etc. Provides step-by-step instructions and notes when not to use (no need for reviewUrl).

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 same response shape and handler as chieflab_status, implying it is read-only (status-like). However, 'recovers' could imply mutation; more explicit safety info (e.g., non-destructive) would improve clarity.

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

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

Two sentences efficiently convey purpose and usage. Front-loaded with key info. Slightly verbose with 'same response shape...same handler' but acceptable.

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

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

For a tool that is an alias with one optional parameter and no output schema, the description covers the essential use case and behavior. Could mention if any side effects occur, but as a status-like tool, it's sufficiently complete.

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

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

Input schema has one optional parameter with 100% description coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states it is an alias of chieflab_status, with a specific purpose: to be used as the first tool when an agent session starts on an active workspace, recovering business loops. This distinguishes it from siblings like chieflab_status through naming and usage context.

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: 'as the FIRST tool when an agent session starts on a workspace that already has activity'. Also specifies that it recovers open business loops. While it doesn't explicitly mention when not to use, the context implies it's for sessions with prior activity.

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 describes the output format and content but does not disclose whether the tool has side effects, permissions required, or behavior when the brain is empty. It implies a read-only operation but lacks explicit safety guarantees.

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 long, front-loaded with usage context, and each sentence adds value. No redundant or filler wording.

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 adequately explains the tool's purpose and output, but lacks parameter documentation and behavioral details. For a simple summary tool, it is minimally complete, but the missing parameter semantics and absence of preconditions reduce completeness.

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

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

The schema covers only 1 of 2 parameters with a description (tenantId), and the description adds no parameter-specific meaning. It mentions 'per-workspace brain' implying workspaceId is important, but does not explain tenantId or the relationship between the two.

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 specifies exact user queries that trigger this tool and clearly states it returns a plain-English summary of accumulated brand memory, including specific content categories. It distinguishes from sibling chieflab_brain_read by indicating that tool provides raw structured data.

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

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

The description explicitly lists trigger phrases ('what do you remember about my brand?', etc.) and advises pairing with chieflab_brain_read for raw data. It does not explicitly state when not to use, but the 'USE WHEN' pattern provides clear 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 provided, so description carries full burden. It reveals filtering criteria (measurementDueAt <= now, measuredAt unset), return fields, and relationship to cron tool. Does not mention permissions or destructiveness, but mutation is not implied. Adequate 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?

Description is a single paragraph, front-loaded with purpose. Contains multiple specific details without excessive verbosity. Could be slightly more structured but is concise.

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

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

Given no output schema, description lists return fields (actionId, runId, etc.). Explains condition for queue inclusion and relates to sibling tool. Covers both native connector and manual paste. Complete for agent understanding.

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

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

Schema coverage is 100% with descriptions for both optional parameters. Description adds no further detail beyond the schema. Baseline of 3 is appropriate.

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

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

Description clearly states 'measurement queue inspector' and specifies when to use: to know which executed actions are ready for 24h readback. It distinguishes from sibling tool chiefmo_post_launch_review by explaining their relationship.

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 the agent wants to know which executed actions are ready for 24h readback'. It pairs with another tool and explains the cron automation context. Lacks explicit '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 are provided, so the description carries full burden. It discloses the return value format and that it's a read operation for checking status. However, it does not mention error handling, authentication requirements, or what happens if the connectionId is invalid, leaving some behavioral 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 sentence with a clear usage prefix and example. No unnecessary words, front-loaded with key information.

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

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

Given no output schema and few parameters, the description covers the essential purpose and usage. It lacks details on error cases or edge behaviors, but for a simple status check it is largely sufficient.

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

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

Schema has two parameters with 0% description coverage. The description mentions 'for the given connectionId' but does not explain workspaceId at all. Given the low coverage, the description should provide more clarity on workspaceId's role and usage.

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

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

The description clearly states the tool checks connector OAuth status, gives example queries, and lists possible return values. It distinguishes itself from siblings like chieflab_connect_connector and chieflab_connector_setup_steps by focusing on post-OAuth confirmation.

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 begins with 'USE WHEN' and provides specific user queries that trigger this tool. It does not mention when not to use or alternatives, but the context 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 provided, so description carries full burden. Discloses that for OAuth providers it returns an authorizeUrl for the user, and for API-key providers it returns instructions for a separate set-key tool. Implies the tool is a prerequisite for other actions. Reasonably transparent, though could mention if it modifies workspace state permanently.

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, starts with the main action, then usage guidance, then behavioral specifics. All sentences earn their place. No fluff. Could be slightly more concise by splitting into bullet points, but appropriate for current format.

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

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

No output schema, so description explains the two possible return types. Covers error scenario ('configure first' errors). Lists all provider options. Sufficient for an agent to use this tool correctly. Minor omission: doesn't specify if the tool checks connectivity or just saves configuration.

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

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

Schema coverage is 100% with a description for 'provider' parameter. The description adds value by grouping providers into OAuth vs API-key categories and explaining the behavioral difference, which helps the agent choose the right response path. This goes beyond the simple enum list in the schema.

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

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

Clearly states 'Connect a third-party provider to this workspace' and lists specific providers (Zernio, Resend, GA4, etc.). Distinguishes from siblings by describing the overall purpose, though could explicitly contrast with chieflab_connect_connector. The USEWHEN clause helps clarify scope.

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

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

Provides explicit use-case statement ('USE WHEN the user wants to wire up publishing, email sending, or analytics readback'). Categorizes providers by auth type (OAuth vs API-key) and tells agent what to do with the response. Also warns about prerequisite errors for other tools.

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

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

No annotations are provided, so description carries full burden. It mentions statefulness but does not disclose whether the tool has side effects, is read-only, or any other behavioral traits. Basic context is given but lacks depth.

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

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

Description is a single paragraph but packs necessary information efficiently. Front-loaded with clear action. Slight room for improvement in structure (e.g., bullet points) but not overly long.

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 of a launch loop resumption tool and absence of output schema or annotations, the description provides a reasonable overview but lacks details on return values, error conditions, and exact behavioral 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%, so baseline is 3. Description does not add additional meaning beyond the schema; it merely restates the schema description for runId.

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 resumes a launch loop from a runId, with specific verb and resource. It distinguishes from siblings by indicating it's the next step after chieflab_get_users_after_build or 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?

Explicitly states when to use: after certain prior tools, and what the tool can do (surface reviewUrl, execute approved action, etc.). Also provides rationale for existence (stateless agents).

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It effectively explains that the tool creates a draft action with status 'awaiting_approval', includes the suggested draft body inline and an executionMatrix, and that the result appears in approval interfaces. While it doesn't cover error conditions or side effects, it sufficiently conveys the immediate outcome.

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 well-structured, with the core purpose front-loaded in the first sentence. It uses efficient language without redundancy, covering conditions, outcome, and workflow in a compact paragraph that is easy to parse.

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

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

Given the tool's complexity (4 parameters, one nested) and the lack of output schema, the description provides sufficient information about what the tool does and produces. It explains the resulting actionStore entry, its status, and the review process. However, it omits details about error handling or the exact structure of the executionMatrix, which would enhance completeness.

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

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

The input schema has 100% description coverage, providing a baseline of 3. The description adds value by explaining the runId parameter's role in chaining ('so the brain can compound launch → measure → next-move chains') and explicitly noting that the metrics object is the same as passed to chieflab_suggest_next_move. This additional context enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose: turning a Next Move suggestion into an approval-gated draft action. It specifies the condition for use (suggestion's kind not 'wait' or 'noop') and the outcome (actionStore entry with status='awaiting_approval'), effectively distinguishing it from sibling tools like chieflab_approve_action and chieflab_execute_approved_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?

The description explicitly states when to use this tool: 'USE WHEN you've called chieflab_suggest_next_move and the suggestion's kind is not 'wait' or 'noop'.' It also contextualizes the tool within the broader loop: 'Closes the loop: launch → measure → next move → approve → execute → repeat.' This provides clear guidance on the tool's role and prerequisites.

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

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

No annotations are provided, so the description carries full burden. It explains that a work request is created and can be offered on, but does not disclose details like permission requirements, rate limits, or any side effects. Adequate for a creation tool but not comprehensive.

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

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

The description is concise, with four sentences that front-load the usage condition. Every sentence adds value without redundancy.

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

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

The description explains the workflow (create request, then offer, accept) but does not specify the tool's return value (e.g., the created request ID). Given no output schema, a bit more detail on the response would be helpful.

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%) with detailed parameter descriptions, so the description adds limited value for parameters. It provides context for the tool's purpose but does not explain parameter semantics 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 begins with a clear 'USE WHEN' statement, specifying the condition (operator hits a gap) and providing concrete examples. It differentiates from siblings by outlining the workflow and mentioning 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 gives explicit conditions for use ('USE WHEN your operator hits a gap') and mentions the subsequent step (accept offer). It lacks an explicit 'do not use' guideline, but the 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 description carries full burden. It details internal steps: sanity gate re-classifies body, captures executor result, writes metadata.proof shape, schedules 24h followup. It mentions uniform return shape. Lacks explicit statement about mutability, but overall 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?

Description is long but information-dense. It front-loads the core purpose but includes many details in a single paragraph. Could be more concise by splitting into clear steps or using bullet points. Adequate but not exemplary.

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 6 parameters, no output schema, and no annotations, the description covers preconditions, internal workflow, return shape, and edge cases (manual, blocked). It explains the uniform return shape without output schema. Minor gap: no explicit error behavior, but still quite 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%. The description contextualizes parameters (e.g., mediaUrls for social, platforms required for social, recipients for email) but does not add significant meaning beyond the schema's own descriptions. Baseline score of 3 applies.

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

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

The description clearly states it is a closed-loop executor wrapper that routes to appropriate native executors for social/email, runs sanity gates, captures results, writes standardized metadata, and schedules follow-up. It distinguishes from siblings by specifying the exact conditions (oauth_connector, api_key_connector) and handling manual_handoff/blocked actions.

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 chiefmo_approve_action just succeeded on an action whose executionMatrix.mode is oauth_connector or api_key_connector AND connectorReady is true.' Also provides guidance for manual_handoff (call chieflab_record_manual_publish) and blocked actions (returns 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 the forced update behavior, refusal condition (already measured), authentication requirement (admin token), and default timing. Could mention rollback or side effects, but adequately transparent 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?

Three concise, well-structured sentences. First sentence states purpose and context, second gives use cases, third adds constraints. No wasted words, front-loaded with key information.

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

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

Given no output schema, description explains core behavior (forces due date into past, refuses if already measured) and authentication. Lacks return value details but adequate for a simple forced-update tool with clear input semantics.

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

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

Schema covers all parameters with descriptions, but description adds valuable context: proofId origin sources, adminToken matching env var, dueAt default behavior (now - 60s). This goes beyond schema and enhances understanding.

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

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

Description explicitly states it's an admin escape hatch that forces a proof_ledger row's measurement_due_at into the past, clearly differentiating from siblings by specifying when to use and referencing related tools like chieflab_record_manual_publish or chieflab_execute_approved_action for getting proofId.

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 two use cases: smoke testing the launch-measure-next-move chain without waiting 24h, and retrying a stuck measurement. Also notes gated by admin token and refuses if already measured, providing clear guidance on when to invoke.

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

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

Without annotations, the description carries the full burden. It discloses what the tool returns (inputs, outputs, pricing, approval-required flag, endpoint) and labels it a 'Pre-flight check', strongly indicating a read‑only operation. However, it does not explicitly state that it is non‑destructive, idempotent, or whether authentication is required, leaving minor 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?

Two sentences, no wasted words. The first sentence immediately states the usage condition and what the tool returns ('full machine-readable profile'). The second sentence adds critical context about its role as a pre-flight check. Information is front‑loaded for quick parsing.

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

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

For a simple retrieval tool with only two string parameters and no output schema, the description covers all essential aspects: when to use, what inputs are needed, what the output contains, and how it fits into the larger workflow (pre‑flight for create_work_request). No critical omissions given the tool's low complexity.

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

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

The input schema has 0% description coverage, but the description explicitly names both parameters ('operatorId + capability') and explains that they together identify which capability to fetch. It adds meaning beyond the raw schema by clarifying their joint purpose, though it does not detail expected formats or constraints (e.g., string length).

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 that the tool retrieves the full machine-readable profile for a specific operatorId+capability pair. It names the exact components returned and positions itself as a pre-flight check before chieflab_create_work_request, clearly distinguishing it from sibling tools like search or match.

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 you have a specific operatorId + capability', providing a clear condition for use. It also names a specific tool (chieflab_create_work_request) as the next step, implicitly telling the agent when not to use this tool (if the goal is creation without checking the profile first) and offering an alternative path.

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 bears full burden. States it's a read operation (non-destructive) and returns specific data, but lacks details on authorization requirements or rate limits.

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

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

Two efficient sentences: first defines purpose and return structure, second provides usage context. No unnecessary words.

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

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

For a simple read tool with one optional parameter and no output schema, the description sufficiently covers purpose, return format, and when to use.

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

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

Schema already describes parameter as 'Optional workspace id.' with 100% coverage. Description adds no additional information about parameter behavior or constraints.

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

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

Description clearly states it reads the workspace's stored company profile and specifies return fields. Distinguishes from siblings like set_company_profile (write) and launch_product (uses this data).

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

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

Explicitly recommends using before launch to confirm grounding. Does not mention when not to use or alternatives, but context is clear given siblings.

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

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

Describes read-only operation and return format, sufficient given no annotations. No side effects or special permissions noted.

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

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

Concise single sentence with example usage, but includes cryptic reference 'P79' that adds no 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?

Covers purpose, return format, and usage context; no output schema needed. Adequate for a simple read 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 provides 100% coverage for optional workspaceId parameter. Description adds no extra info beyond schema, so baseline 3.

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

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

Description states 'read the workspace's stored publishing target defaults' with clear verb and resource, and returns specific structure. It is distinct from sibling chieflab_set_publishing_targets.

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?

Indicates it is 'useful before launch' and suggests alternative action when targets missing, providing context for use vs. other tools.

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

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

Although no annotations are provided, the description details the tool's behavior: it sets up a launchPack with approval-gated actions, measurement, memory, etc. It also mentions prerequisites ('Gather repoContext first'). The description effectively communicates the tool's role as an 'agent-dependency tool' without contradicting any annotations.

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

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

The description is front-loaded with the core purpose and structured logically: alias declaration, use cases, what the tool does, prerequisites, and routing. While somewhat verbose, every sentence adds value and is necessary for agent understanding. The length is justified by the tool's complexity.

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

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

Given the absence of output schema and annotations, the description provides a comprehensive overview including the tool's role, output artifacts (launchPack, reviewUrl), lifecycle details (24h measurement, next move), and explicit usage context. It leaves no ambiguity about when and how to invoke the tool.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal additional parameter guidance beyond the schema, except for clarifying the productUrl/productDescription alternative and emphasizing repoContext. The schema itself is already fairly descriptive.

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 'Outcome-named alias for chiefmo_launch_product' and specifies the exact scenarios (after build, when user asks for users/customers/money). It distinguishes itself from siblings by explicitly noting it should not be confused with chiefmo_diagnose_marketing.

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 criteria: 'USE WHEN a coding agent just built, shipped, or deployed something and the user asks...' along with specific user queries. It also gives routing instructions and a clear alternative ('do not use chiefmo_diagnose_marketing for a new product').

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?

States it has 'no side effects' and is 'cheap', which is good behavioral disclosure for a tool with no annotations. It describes what it returns, but could mention any prerequisites like workspace context being set.

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 concise sentences, front-loaded with the most important instruction ('FIRST TOOL'), and 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?

Despite lacking an output schema, the description explains what the tool returns (operator menu, workspace state, next action), which is sufficient for an initial help tool. No critical gaps.

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

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

No parameters exist, so the description naturally adds no param info. With 100% schema coverage for no params, a baseline of 4 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 the first tool to call when you don't know what ChiefLab does or where to start. It specifies the returns (operator menu, workspace state, next action) and distinguishes itself from sibling tools 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?

Explicitly says 'FIRST TOOL — call before anything else', providing clear when-to-use guidance. It also gives alternative next steps, making the usage context very clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes that it returns engagement events and lists filter options, but does not mention whether the operation is read-only, potential side effects, rate limits, or data size constraints. The description is insufficient for an agent to fully understand the tool's behavior.

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

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

The description is concise: two sentences that front-load usage scenarios and then specify behavior and filters. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (read operation with filters) and lack of output schema or annotations, the description covers basic purpose and usage. However, it omits details about return format, pagination, or max event limits (though limit param exists). It is adequate but not fully 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?

The input schema has 75% description coverage (workspaceId missing description). The description does not add meaning beyond what the schema already provides for limit, status, and sinceHours. It repeats the default 'new' filter but offers no additional context, like how status values behave or what happens if limit is exceeded.

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

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

The description clearly states the tool returns engagement events for the workspace ordered by recency, with example queries like 'what came in from my launches?' and 'what's in my inbox?'. It also names a sibling to pair with (chieflab_draft_reply), distinguishing it from other inbox 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' and provides several example user intents, giving clear context for when to invoke this tool. It also suggests pairing with chieflab_draft_reply, but does not specify when not to use it or provide exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It discloses internal composition (post, email under one runId), approval-gating, review URL generation, and 24h measurement queue. However, it does not mention authentication needs, rate limits, or destructive nature beyond implied mutations.

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 single-paragraph but front-loads the operator context. However, it is dense and uses spec-revision language ('Spec v0.1', 'spec-renamed alias') that may be verbose without aiding utility. Every sentence contributes but structure could be cleaner.

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 parameters, nested objects, no output schema, no annotations), the description explains the orchestration flow but lacks specifics on input requirements, error handling, prerequisites, or return value format. Leaves gaps for an AI agent to select and invoke correctly.

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

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

Schema description coverage is 0% despite 10 parameters (some nested). The description hints at channels (linkedin, x, etc.) and image briefs, but does not explicitly map to schema properties like goal, brand, productUrl, or idempotencyKey. High complexity with minimal compensation.

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

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

The description clearly identifies the tool as an end-to-end launch orchestrator with a specific verb and resource ('launch product'). It mentions composed sub-tools (chieflab-post, chieflab-email) and distinguishes from them, but the dense spec-wording may reduce immediate clarity.

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 states it is the 'primary' operator and a spec reference, but does not explicitly say when to use this tool vs. alternatives like chiefmo_launch_product or other launch-related siblings. It notes backwards compatibility with chiefmo_launch_product, leaving confusion about which to invoke.

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

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

The description discloses that the tool returns kind and label for each specialist, implying a non-modifying query. While no annotations are present, the description sufficiently indicates it is a read-only operation. It could be slightly more explicit about being non-destructive, but the verb 'list' strongly implies that.

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

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

The description is a single concise sentence that front-loads the key information (P87 — list) and includes usage conditions. Every word serves a purpose 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 parameters or output schema, the description is fully complete: it explains what the tool does, when to use it, and what it returns. It leaves no gaps for a tool of this 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?

There are no parameters, so the schema provides full coverage. The description does not need to add parameter details; it correctly focuses on the purpose and output.

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

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

The description clearly states the tool lists specialist agents ChiefLab can delegate to, specifying categories (design/video/research/outreach/seo/analytics). It distinguishes its purpose from the sibling tool chieflab_request_specialist by stating it should be called before that 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 tells when to use: when the user asks 'what can ChiefLab do beyond launch posts?' or before calling chieflab_request_specialist. It provides clear context and an alternative action, making it easy for the 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?

With no annotations provided, the description carries the full burden. It discloses that the action is flipped to executed, metadata fields (markedManuallyAt, executedManually=true) are set, and the card disappears from Today's Loop. However, it does not discuss error conditions, permissions, or reversibility, leaving some gaps.

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

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

The description is front-loaded with the core purpose and provides necessary details. The 'P135' reference adds minor noise but does not detract significantly. It is structured logically: purpose, examples, effect, and alternative. 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 simple action (flip state with optional note), schema coverage is complete, and no output schema exists. The description covers when to use, what it does, parameter purpose, and UI effect. It is fully sufficient for correct invocation without additional context.

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

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

Schema coverage is 100% (baseline 3). The description adds value beyond the schema by explaining the note parameter's storage location and purpose (metadata.markedManuallyNote for the brain), and the actionId and workspaceId are clear from their schema descriptions. This extra context justifies a 4.

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

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

The description clearly states the tool marks a next-move action as completed when there is no URL to record, providing specific examples (reply_to_commenters, dm_engagers) and explicitly differentiating from chieflab_record_manual_publish. The verb 'mark' and resource 'next-move action' 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 explicitly states when to use this tool (no URL to record) and when not to use it (when there is a URL), directing the agent to chieflab_record_manual_publish as an alternative. This provides clear guidance on tool selection.

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

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

With no annotations, the description discloses idempotency ('second call returns existing measurement'), no API key requirement, auto-creation of next-move actions, and uses the Firebase API. It does not cover error handling or rate limits, but the provided behavioral traits are substantial for safe agent 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 concise and front-loaded with the core purpose. Each phrase adds value (idempotency, auth, outcome actions). The single-sentence structure is effective but could be slightly improved with bullet points for 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 3 params, the description covers the tool's purpose, usage condition, idempotency, auth, and automated follow-up actions. It lacks explicit error scenarios but provides a complete mental model for an AI 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 meaning beyond the schema: it reinforces 'force' behavior and repeats actionId context, but workspaceId is not elaborated. No new parameter semantics are provided.

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 pulls a Hacker News post's score, comments, and top replies via the public HN API and writes them to metadata.proof. It specifies the action type (published Hacker News action) and distinguishes it from sibling tools like chieflab_check_measurement_due which only check due status.

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 a published Hacker News action is ripe for 24h measurement', providing clear context. It outlines the decision logic based on outcome (trending/engaged/stalled) but does not explicitly exclude alternative tools, though siblings are largely unrelated.

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 fully discloses behaviors: uses public API without auth, parses subreddit and post ID from publishedUrl, auto-creates next-move actions based on outcome (trending, engaged, downvoted), and idempotent unless force:true. 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 dense paragraph. It front-loads the core purpose and is reasonably concise, though the auto-creation logic adds length. It could be slightly more structured, 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 no output schema, the description explains what data is written to metadata.proof and the auto-creation of next-move actions. It covers the input, process, and outcome adequately for a specialized tool, though exact proof structure is omitted.

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

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

Schema coverage is 100%, so the description adds little beyond param descriptions. It mentions 'force' in context and explains how actionId is used, but this is already captured in 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: pulling a Reddit post's score, comments, upvote ratio, and top replies via the public Reddit JSON API and writing them to metadata.proof. It uses a specific verb+resource and distinguishes from siblings like chieflab_measure_hacker_news.

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 specific usage condition: 'USE WHEN a published Reddit action is ripe for 24h measurement.' It also mentions idempotency and the force parameter for re-measurement, but does not explicitly contrast with alternative tools or state when not to use it.

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

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

With no annotations provided, the description carries the full burden. It details what the tool probes (tables vs. in-memory), checks for durability, table existence, etc., and explains the 'tableExists: false' case. However, it does not mention if there are any side effects or read-only guarantees.

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

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

The description is relatively long but well-structured with a badge, purpose, use cases, and return format. Each sentence adds value, though some minor trimming could improve 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?

The description provides a detailed return format without an output schema, which is helpful. However, it lacks explanation of the workspaceId parameter, and it does not cover scenarios like missing data or permission issues. It is adequate but not fully 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?

The input schema has one parameter (workspaceId) with no description and 0% schema coverage. The description does not mention this parameter at all, leaving its purpose and effect unexplained. Since coverage is low, the description should compensate but fails to do so.

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: 'verify the persistent stores' and lists specific tables and fallback. It provides explicit use cases (after migrations, before launch, debugging) that distinguish it from sibling tools like chieflab_query_proof_ledger or chieflab_status.

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 the user just ran the SQL migrations... OR before a real founder launch... OR when debugging...' This provides clear context, though it does not explicitly mention when not to use or 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 that the tool pulls engagement data (likes, comments, views, shares, follower delta) and returns per-account analytics, top posts, best-time-to-post, and a structured next-move recommendation. It does not mention destructive actions or auth requirements, but its read-only nature is implied. The description adds valuable context beyond annotations.

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

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

The description is relatively long but every sentence adds value. It front-loads the alias and usage condition, then lists outputs. 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?

No output schema is provided, so the description compensates by listing what is returned (per-account analytics, top posts, recommendation brief). It explains the 24h condition but does not cover error cases or prerequisites beyond that. Still, it provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100% with descriptions for all four parameters. The description adds context: runId is 'the launchId returned by chiefmo_launch_product', accountIds defaults to all accounts, outputMode defaults to 'context', and lookbackDays defaults to 7 (max 90). This goes beyond the schema's basic 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 is for post-launch review after 24 hours, listing specific user queries it addresses ('how did the launch perform?', 'what worked?', 'metrics from my launch'). It includes an alias note and distinguishes itself by describing its specific function (pulling engagement, recommending next iteration) among many 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?

The description explicitly provides a condition for use: 'USE WHEN ≥24h has passed since chiefmo_publish_approved_post fired and the user asks...', which clearly tells the agent when to invoke this tool versus others. It also implies not to use before that time.

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

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

No annotations are provided, so the description carries full burden. It discloses that actions land in 'awaiting_approval' and require human approval, and mentions use of company brain and brand voice. But it lacks disclosure of side effects, permissions needed, 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 informative but somewhat long. It front-loads key information (usage condition) but includes detailed explanations that could be condensed. Still, it is structured and readable.

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

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

Given no output schema, the description explains the return value (draft queue, reviewUrl, agentGuide block). It covers input, behavior, and output for a 4-parameter tool without nested objects, making it reasonably 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%, baseline 3. The description adds meaning beyond schema: explains that runId is the 'prior launchId from chiefmo_launch_product', horizon lists allowed values with default, and channels is optional. This enriches understanding.

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

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

The description clearly states the tool's purpose: 'turns one launch into a 7-day launch mode: drafts a queue of follow-up actions'. It specifies the verb ('prepare next move') and resource ('queue of follow-up actions'), and distinguishes from siblings by noting it is an alias of chiefmo_prepare_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 says 'USE WHEN the user has just published a launch (or ≥24h post-launch) and asks...' providing clear context. It also mentions grounding in prior launch's runId and company brain. However, it does not explicitly state when NOT to use it or mention alternative tools.

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

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

Describes the approval gate behavior (returns { reason: 'requires_approval', reviewUrl }) and that it outputs live post URL. Calls it a "Money/external-system action". Lacks details on rate limits but covers key behaviors well for a publish 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?

Description is concise (3-4 sentences) and front-loaded with the alias and main purpose. Every sentence adds value without fluff. Slightly longer than necessary but still 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 (5 params, no output schema, many siblings), the description covers the approval flow, usage context, links to other tools, and warnings. Provides sufficient detail for safe invocation.

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

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

Schema coverage is 100%, but description adds context: content is "the final rendered post text", actionId is from chiefmo_launch_product, platforms accounts from chieflab_list_publish_accounts, scheduleAt is ISO 8601. Adds meaningful guidance 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 it publishes approved social posts via Zernio, listing platforms. Distinguishes from siblings by requiring an approved actionId 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?

Explicitly says "USE WHEN the user has approved a publishAction from chiefmo_launch_product" and "never call this without an approved actionId", providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description fully discloses the tool's behavior: it is a read-only query, returns specific fields, and explains persistence behavior (persistent if Supabase wired, otherwise in-memory). This provides complete transparency for an agent.

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

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

The description is concise and front-loads the purpose and usage. It is a single paragraph that effectively communicates key points without unnecessary fluff, though it could be slightly more structured (e.g., bullet format).

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

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

The description covers the return format (proof rows with artifact URLs, channels, etc.) and persistence behavior, which is sufficient for a query tool. However, it lacks details on ordering or default pagination, which would be useful given no 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?

Although schema coverage is 100%, the description adds value by explaining the purpose of the 'measurementDueOnly' filter (rows ready for 24h readback) and contextualizing the parameters. This goes slightly beyond the schema descriptions.

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

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

The description clearly states the tool queries the persistent proof ledger and gives concrete use cases ('what has ChiefLab actually shipped for this workspace?', 'show me the launch history'). It also lists the returned data (proof rows, artifact URLs, etc.), making the purpose unambiguous and distinct from other tools.

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

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

The description explicitly says 'USE WHEN' followed by specific user queries, providing clear usage context. However, it does not mention when not to use this tool or suggest alternatives, which would further enhance 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?

Discloses internal actions: reads metadata.proof.artifactUrl, writes metrics into metadata.proof.metrics + measuredAt, auto-classifies outcome, creates next-move actions, and returns metric schema. With no annotations, this provides sufficient 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?

Information-dense but not overly long; each sentence adds value. Front-loaded with a clear identifier and purpose. Could be broken into shorter sentences for readability.

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

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

Given complexity (manual entry, auto-classification, next-move creation) and no output schema, the description fully covers purpose, usage, parameter details, and what the tool 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?

Schema coverage is 100%, and the description adds significant value by listing channel-specific keys for the 'metrics' object and explaining behavior when called without metrics (retrieve 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 defines the tool as a manual metric fallback for channels without public API measurement, naming specific channels (X, LinkedIn, Email, landing pages, Product Hunt) and explicitly distinguishing from siblings by stating 'anything except hacker_news / 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?

It provides explicit usage conditions: 'USE WHEN a published action's channel doesn't have a public-JSON metrics endpoint... AND the founder is ready to paste the visible numbers.' It implies alternatives for hacker_news/reddit but does not name sibling tools directly.

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 flips the publishAction status, persists a proof_asset, and queues metrics readback. This gives the agent a clear understanding of side effects and consequences of not using the 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 a single, well-structured paragraph. It front-loads the usage condition and explains functionality and consequences concisely. No unnecessary text, but could be broken into multiple sentences for 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 the 5-parameter schema and no output schema, the description provides sufficient context: usage scenario, side effects, and importance. It does not describe return values, but the tool's purpose implies it completes an action, and the side effects are well explained.

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

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

Input schema has 100% coverage with good descriptions. The tool description adds overall context but does not significantly enhance individual parameter meaning beyond the schema. However, it references the fallback tool for actionId and publishedUrl, slightly elevating utility.

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 record the live URL of a manually posted channel back to ChiefLab. It specifies the verb 'record' and the resource 'manual publish', and distinguishes from siblings by tying to chieflab_use_manual_fallback and explaining the closed loop continuation.

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', explicitly stating the condition (user manually posted using chieflab_use_manual_fallback) and the motivation (feed back URL for closed loop). It also warns that without this tool, manually-posted channels are lost, providing clear guidance on when 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 provided, the description fully discloses behavioral traits: it pulls the existing brief, merges the instruction, returns an updated brief for LLM rendering, requires a follow-up commit call, and details multi-turn coherence (increments revision, preserves original in history). 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 concise (4 sentences), front-loaded with the usage trigger, and avoids superfluous details. Every sentence serves a purpose: trigger, action, post-requisite, and behavioral note.

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

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

The description covers when to use, the core workflow, post-requisite action, and behavioral details (revision tracking, history preservation). It does not explain error cases or return format, but given the complexity and lack of output schema, it is 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?

The input schema covers 3 of 4 parameters with descriptions (75% coverage). The description adds valuable context for 'instruction' (plain-English, examples) and 'body' (optional, pre-rendered). However, 'workspaceId' lacks description in both schema and description, slightly reducing clarity.

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 what the tool does: redraft a published draft when the user says phrases like 'make this more casual' or 'shorter'. It specifies the action of pulling the brief, merging the instruction, and returning an updated brief, which differentiates it from sibling drafting 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 provides explicit usage triggers ('USE WHEN the user says ... about a published draft') and a critical follow-up step (call chieflab_record_rendered_copy). However, it does not explicitly mention when not to use this tool or list alternatives, leaving some ambiguity.

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, but description fully discloses key behaviors: reads original brief, does NOT auto-persist, and lists return fields. This is excellent 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?

Single paragraph with clear structure: purpose, usage, internal logic, return info, persistence caveat. Slightly verbose but all sentences add 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 nested objects, the description covers everything: usage context, internal steps, return shape, and persistence decision. Complete for an AI 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?

All 12 parameters have schema descriptions (100% coverage). Description adds value for key params like runId (looks up brief) and assetId (swap in place). Barely misses 5 due to some params being straightforward.

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 explicitly states it regenerates a visual asset with different style/fidelity/headline/model, and distinguishes from siblings which are about actions, approvals, or publishing.

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 specific usage condition: when a reviewer hits 'Regenerate' in Launch Room. Also clarifies non-persistence. Lacks explicit when-not or alternatives, but context is clear.

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

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

With no annotations, the description bears full burden. It discloses that specialists are deterministic stubs, return structured briefs/plans/drafts, create an approval-gated action, and can be bypassed with autoCreateAction=false. It does not cover authentication or rate limits, but the behavioral traits are well communicated.

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: purpose first, then usage, then behavior. Each sentence adds value. The 'P87' prefix is minor clutter but does not harm clarity. Could be slightly shorter but effective.

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

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

The description covers purpose, usage, behavioral traits, and parameter significance. It explains the return format (structured briefs/plans/drafts) and integration with Launch Room. Given no output schema, the description provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of runId ('grounding in launch brief') and the effect of autoCreateAction. It also contextualizes kind with examples, though schema already lists allowed values. Overall, description enhances parameter understanding.

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

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

The description explicitly states the tool delegates to a specialist agent for specific kinds of tasks beyond copy. It lists six kinds with concrete examples, clearly distinguishing from siblings like chieflab_create_work_request. The purpose is 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?

The description specifies when to use: 'USE WHEN the launch needs more than copy' and enumerates the six specialist kinds. It provides context for parameters like runId and autoCreateAction but does not explicitly state when not to use or name alternatives. 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?

No annotations provided, so description carries full burden. It states the return value (ready or still blocked), but does not disclose side effects (e.g., whether any state is modified) or error conditions. Adequate but not comprehensive.

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

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

Two concise sentences with no filler. Front-loaded with action and purpose, followed by usage guidance. 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 no output schema, the description provides return value context. Covers the main use case, but lacks details on error handling or exact response format. Still sufficient 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 describes actionId but not workspaceId (50% coverage). The tool description adds no additional meaning for parameters; workspaceId remains unexplained. The description does not compensate for the schema 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?

Clearly states the verb 're-check' and the resource 'blocked publishAction's connector readiness'. Explicitly distinguishes from sibling tools like chiefmo_publish_approved_post and chiefmo_send_approved_email by mentioning they can be re-fired after retry.

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

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

Provides explicit usage scenario: 'USE WHEN the user has just connected a missing provider and the agent needs to know if the action can fire.' Also suggests subsequent actions, but does not mention when not to use it or alternative tools.

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

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

No annotations provided, so description carries full burden. Describes internal actions: reads visualAssets list, updates status, persists to run metadata. Could mention that it does not destroy anything, but mutation is clear. Lacks return value info.

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

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

Four focused sentences, front-loaded with action and asset types. Every sentence provides essential information; 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?

No output schema, but description covers purpose, parameters, and persistence effect. Lacks details on return value or error conditions, but sufficient for typical agent understanding.

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

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

Schema coverage is 100%, but description adds value by explaining reason parameter is stored for audit and brain memory, and clarifies decision enum effect. Beyond schema but not extensive.

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 action (approve/reject) on specific asset types (LinkedIn graphic, X image, etc.) and distinguishes from sibling tool chieflab_regenerate_visual_asset by noting that this tool persists changes while the other produces 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?

Explicitly says 'USE WHEN a reviewer hits Approve or Reject in the Launch Room', providing clear context. Mentions companion tool, but no explicit when-not scenarios, which would make it a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses that results are 'active' and 'ranked by recency', which adds some behavioral context. However, it does not mention any restrictions, authentication needs, or potential side effects. A score of 3 reflects adequate but not exhaustive 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?

The description is three sentences, front-loaded with the primary use case, followed by result details and a pairing suggestion. Each sentence adds value, though it could be slightly more concise 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 the absence of an output schema, the description explains the nature of return values (active records, ranked by recency) and the broader workflow context. It does not fully define 'capability', but the tool name and use cases make it understandable. Fairly complete for a search 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 description coverage is 100%, so baseline is 3. The description does not add meaningful extra context beyond what the schema already provides for tags, limit, and capability. It meets the minimum acceptable level.

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 imperative ('USE WHEN') with concrete examples like 'find me a demo-video capability'. It specifies the resource ('active capability records') and verb ('search'), and distinguishes from sibling tools like chieflab_create_work_request, which handles the actual work request after discovery.

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 the condition for use: when an operator needs a capability outside its own scope. It also pairs the tool with chieflab_create_work_request, providing a clear workflow path. No contradictory usage advice is given.

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

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

With no annotations, the description covers critical behavior: 'Money/external-system action — once sent cannot be unsent', highlighting irreversibility and external action. It also notes strict approval gate 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?

Five sentences, front-loaded with purpose and usage condition, then behavioral note. No redundant information; 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?

The description covers purpose, usage, key requirements (verified domain, short list), irreversibility, and links to a similar approval gate. It lacks error handling or rate limits but is generally complete 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 86% (high), so baseline 3. The description adds value by explaining the `actionId` parameter as required for the approval gate and reiterating `from` must be verified. This contextualizes 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 it sends an approved launch email via Resend, specifying the verb 'send' and resource 'approved email'. It distinguishes from siblings by referencing the approval gate from chiefmo_launch_product and comparing to chiefmo_publish_approved_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?

The description explicitly instructs 'USE WHEN the user has approved an email publishAction from chiefmo_launch_product', providing clear context. It implies when not to use (without approval) but doesn't list alternative tools explicitly.

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 discloses mutation behavior, partial update merge, null removal, and that launches will ground in these facts. Adequately transparent without annotations.

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

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

Front-loaded with purpose, but includes historical context ('pre-P88 brief pipeline was repo-first') that could be trimmed. Still, structure is clear with bulleted fields.

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

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

No output schema, so missing return value description. However, for a set operation, the description covers main behavior and usage. Could mention error cases or side effects.

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

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

Schema coverage 100% (baseline 3). Description adds value by explaining partial updates, null removal, and listing the fields the brief consumes, which goes beyond schema names.

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 'set the workspace's persistent company profile' with specific verb and resource, and distinguishes from sibling 'chieflab_get_company_profile' through context.

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 'Pass partial maps to update specific fields; pass null for a field to remove it', providing clear usage guidance. Does not exclusions or alternatives, but sibling differentiation is sufficient.

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

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

With no annotations, the description carries full weight. It reveals encryption at rest, workspace scoping, and billing implications. However, it omits details on overwriting existing keys or immediate validation, which would strengthen 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 concise and well-organized: action first, then key benefits, provider list, storage note, and sibling reference. Every sentence is informative without redundancy.

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

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

Given no output schema and simple parameters, the description fully covers purpose, usage scenarios, security, and related tools. It leaves no critical gaps for an agent to misuse the 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%, but the description adds value by mapping provider values to services (e.g., gemini for image gen) and explaining the apiKey's role in direct billing. The workspaceId optional parameter is also contextualized.

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 current workspace, specifying supported providers and contrasting with siblings like chieflab_set_resend_key. It explicitly differentiates by being a generic setter for any listed provider.

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 BYOK (bring your own key) vs letting ChiefLab use its own key. It lists compatible providers and directs to chieflab_revoke_provider_key for removal, providing clear usage context.

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

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

With no annotations, the description fully discloses behavior: partial map updates, null to remove, persistence details (persistent vs in-memory), and return value structure. 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 paragraph but well-structured: starts with purpose, then setup, parameter details, persistence, and return. No fluff, but slightly dense; could be split into bullet points for 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?

Comprehensive for the tool: explains return value, side effects, and relationship to other tools (implicitly via reference to chiefmo_approve_action). Missing mention of sibling chieflab_get_publishing_targets for reading targets, but not critical.

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

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

Schema coverage is 100%, but description adds semantic context: explains the structure of channelTargets map with examples for LinkedIn, X, and email, and how null removes channels. This goes beyond the schema's property 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 tool sets per-workspace publishing target defaults to avoid repeated parameters in chiefmo_approve_action. It specifies verb 'set' and resource 'publishing targets', distinguishing it from siblings like chieflab_get_publishing_targets.

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 'One-time setup per workspace', indicating when to use. It explains the tool's role in conjunction with chiefmo_approve_action. However, it does not mention when to avoid using it or alternatives for different 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?

With no annotations, description thoroughly explains behavioral traits: workspace creation, key return, config writing, delivery URL expiration (1 hour), single-use, IP rate limit. 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?

Concise single paragraph with front-loaded usage condition. Could benefit from bullet points for the two flows, but still clear 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?

No output schema, but description explains the return value (apiKey) and covers both users' ability to write config or use delivery URL, including expiration and rate limits. 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 has 100% coverage with good parameter descriptions. The description repeats the same info without adding new semantics 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 it creates a new workspace and returns the API key, distinguishing it from other tools that involve reading, connecting, or other operations.

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 condition: 'when the user has no ChiefLab API key yet and you've gotten a 401 error'. Provides two clear flows (preferred and fallback).

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

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

The description discloses that the action status changes to rejected with metadata.skipReason and that the next-move generator reads skip reasons to avoid suggesting similar moves. This goes beyond the basic purpose, though it could mention prerequisites or side effects like irreversibility.

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-loading the purpose and adding key behavioral details without unnecessary words. Every sentence contributes meaning.

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

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

The description covers the main purpose, effect, and learning mechanism. It lacks explanation of return values or prerequisites, but given the tool's simplicity and the presence of other commands, it is mostly 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?

With 100% schema coverage, the baseline is 3. The description adds value by providing example reasons for the 'reason' parameter and explaining its role in learning, which enhances understanding beyond the schema's description.

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

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

The description clearly states the tool allows a founder to reject a next-move recommendation without executing it, using the verb 'rejects' and specifying the resource 'next-move recommendation'. It distinguishes from siblings like approve_action by explicitly noting the action is flipped to rejected.

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 and wants to capture the reason. It provides examples of reasons, giving context for appropriate use. However, it does not explicitly state when not to use or directly compare with sibling tools.

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

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

Describes stateful, re-summonable behavior, recovers workspace business state even after lost context. No annotations, so description fully handles 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?

Front-loaded with 'SESSION-RECOVERY · FIRST CALL'. All sentences are informative but slightly verbose. Still concise enough.

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 fully explains return structure (headline, priority, cards with fields, next prompt) and aggregations. Complete for agent to invoke correctly.

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

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

Only one optional parameter (workspaceId) with schema description. Description adds no further meaning. Baseline 3 due to 100% 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?

Clearly states it returns a command-center bootCard for session recovery, listing aggregated data. Distinguishes itself as the FIRST CALL. Specific verb 'returns' and resource 'bootCard'.

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: FIRST CALL when session starts and user mentions specific topics. Also gives instruction: surface cards before drafting new launch.

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 compensates by declaring it a 'pure function' with deterministic output. It also outlines the output structure (kind, priority, reasoning, draftBrief, measurementGroundingFacts). No side effects disclosed beyond the pure function claim.

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

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

The description is moderately long but every sentence adds value. It is front-loaded with the purpose and usage condition. The output structure is specified. Could be slightly shorter, but no unnecessary information.

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

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

For a complex tool with 4 parameters and no output schema, the description covers the essential aspects: trigger condition, deterministic nature, output structure, and pairing with another tool. However, it doesn't clarify how it differs from chieflab_prepare_next_move, which may cause confusion.

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

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

Schema description coverage is 100%, and the description adds meaningful context. For 'runId', it explains grounding vs templates. For 'metrics', it lists accepted synonyms. For 'channel', it enumerates valid values. This improves understanding beyond the schema alone.

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

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

Purpose is extremely clear: 'suggest next move' based on measurement metrics. The description explicitly states when to use ('USE WHEN measurement just came in') and specifies the resource (metrics + brief). It distinguishes from siblings by mentioning pairing with chieflab_create_next_move_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?

Guidelines are explicit: use when measurement just came in, either automatic (24h) or manual. It pairs with chieflab_create_next_move_action. No exclusions or alternatives discussed, but the trigger condition is well-defined.

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

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

Without annotations, the description carries the full burden. It discloses the output format, the approval gate, and the conversion of a blocked channel into a manual ship. However, it does not explicitly state whether the tool has side effects or mutates state, which would be useful for a tool that 'converts' something.

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 effectively front-loads the usage condition with 'USE WHEN'. It is slightly verbose but all sentences contribute meaningful information. Could be more structured with bullet points, but current form is acceptable.

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 5 parameters, no output schema, and no annotations, the description provides sufficient context: trigger condition, output components, prerequisite, and even a future measurement template. It lacks error handling details but is otherwise complete for an agent to use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context for the overall tool but does not provide additional meaning beyond the schema descriptions for parameters like channel, actionId, subreddit, etc. The schema already adequately describes 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 provide a manual-publish brief when a launch action is blocked due to lack of automated publish path. It specifies the exact output and differentiates from sibling tools like chieflab_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 starts with 'USE WHEN' and explicitly states the condition for using the tool (blocked automated publish path). It also mentions the prerequisite that the originating publishAction must be approved, providing clear guidance on when to call 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 exist, so description fully covers behavior. Details return object structure, including ok field and nextStep on failure. Could mention auth or side effects, but sufficient for a health check.

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 is dense but front-loaded with purpose and key constraints. Could be slightly more structured, but no unnecessary 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 no output schema, description fully describes return structure, error handling (nextStep), and includes a link to external protocol. Complete for an agent to invoke correctly.

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

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

Schema covers 100% of parameters. Description adds value by noting workspaceId is optional and inferred from bearer auth, providing context beyond schema.

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

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

The description clearly states it is a POST-INSTALL HEALTH CHECK, with specific verb 'verify install' and use case after wiring ChiefLab. It distinguishes from siblings like 'boot' and 'status' by focusing on post-install verification.

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 exactly once after runtime wiring, providing a link to bootstrap protocol. No explicit when-not, but context is clear. Mentions nextStep for failure, guiding recovery.

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