ChiefLab

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

No annotations are provided, so the description must carry the full burden. It uses the word 'read' implying idempotency, but does not disclose side effects, authentication needs, rate limits, or input validation behavior. The description adds minimal transparency beyond the name itself.

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

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

The description is relatively concise, front-loading the purpose and providing useful alias and record tool context. While the list of record tools adds length, it is relevant for completeness. Slightly too verbose, but overall well-structured.

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

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

For a simple read tool with no output schema, the description lists the components of the returned brain, which provides some context. However, it does not describe the output format or possible error states, leaving some gaps for an agent.

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

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

Schema description coverage is 0%, and the description does not explain the meaning or format of tenantId and workspaceId, nor how they affect the result. The only hint is 'per-tenant company brain,' but this does not map to the parameters explicitly.

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 a 'primary read' that returns the 'per-tenant company brain' with specific components (brand voice samples, repo facts, etc.), effectively distinguishing it from siblings. It also notes it is a spec-renamed alias of chiefmo_company_brain, which helps avoid confusion with the sibling 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?

The description implies the tool is for reading contextual information before launches ('drives cross-launch grounding') and lists related record tools, but it does not explicitly guide when to use this tool versus alternatives 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, the description carries the full burden. It clearly states the return value (authorize URL) and describes the OAuth flow and resulting connector state. It also warns about the partial live-data path for most connectors, providing useful behavioral context beyond the basic 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?

The description is a single paragraph but is front-loaded with the key use case and includes necessary caveats. It is clear and direct, with no unnecessary words, though it could be slightly more structured.

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

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

The description covers the tool's purpose, output (authorize URL), and limitations. Without an output schema, it adequately describes the return value. The note about v1 wiring adds important context for agent decision-making.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add additional semantics beyond what the schema already provides for 'provider' and 'workspaceId'. It doesn't explain allowed values or usage details 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 starts with 'USE WHEN the user wants to connect a third-party data source via OAuth' and lists specific examples, clearly stating the tool's purpose and resource. It distinguishes from siblings by noting that only chieflab_connect_publish_account is fully wired.

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 context for connecting third-party data sources. It also includes a note about v1 limitations, guiding the agent on when this tool is appropriate and that other connectors may have partial functionality.

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

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

With no annotations, the description carries full burden. It clearly indicates a read-only operation ('Get ... instructions') and describes the return value (prerequisites, steps, verification commands). No contradictions or missing behavioral details are apparent, though it could explicitly state no side effects.

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

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

Two sentences: first covers purpose and output, second covers usage. No fluff, front-loaded with essential 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?

For a simple tool with one parameter and no output schema, the description fully covers purpose, input, output, and usage context. No gaps remain given 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?

The schema has 100% coverage with a description listing valid providers. The description repeats these providers in parentheses but adds no additional semantic information beyond what the schema provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get step-by-step JIT setup instructions for a connector (zernio | resend | ga4 | search_console | github | cms).' It specifies the exact output format (prerequisites, ordered steps, verification commands) and distinguishes itself from sibling connector tools like chieflab_connector_status by focusing on setup instructions.

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

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

The description explicitly states when to use: 'Use when a launch pack reports a connectorBlocker — pipe these steps to the user.' This provides clear context and a specific trigger. It implies when not to use (other scenarios) but doesn't mention alternative tools, which is acceptable given the narrow scope.

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 states returns status values (pending/connected/failed) but doesn't elaborate on auth needs, rate limits, or that it's a read-only operation. Adequate but could be more explicit.

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

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

Single sentence with context, example queries, and key return values. No filler, perfectly front-loaded, and efficient.

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

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

Given the tool's simplicity (2 params, no output schema), the description gives enough context for its purpose. Could mention workspaceId's role, but overall it's clear for a status-check 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 two parameters (workspaceId optional, connectionId required) but description only mentions connectionId. With 0% schema description coverage, this omission leaves workspaceId unexplained, reducing agent 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 checks connector status after OAuth, with specific user queries. It distinctly differs from sibling tools like chieflab_connect_connector by focusing on status 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?

Explicitly specifies when to use ('just completed a connector OAuth flow') and gives example user questions. Could mention when not to use or alternatives, but provides strong 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?

Although no annotations exist, the description reveals that OAuth providers return an authorizeUrl and API-key providers return instructions for a set-key tool. It also mentions that without it, other tools return errors. However, it does not discuss whether it overwrites existing connections or other side effects.

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

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

Three sentences, no fluff. Each sentence serves a purpose: what it does, when to use, and expected behavior per provider type.

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

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

Given the simplicity (one parameter, no output schema), the description covers purpose, usage, behavioral differences, and prerequisites. It could mention idempotency or potential side effects, but overall it's adequate.

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

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

With only one parameter and 100% schema description coverage, the description adds value by listing example providers and explaining behavioral differences (OAuth vs. API-key), which goes beyond the schema's basic enum.

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

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

The description clearly states the tool connects a third-party provider to the workspace, lists specific providers (Zernio, Resend, GA4, etc.), and distinguishes it from siblings that handle reading, publishing, or other 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?

It explicitly says 'USE WHEN the user wants to wire up publishing, email sending, or analytics readback,' and differentiates between OAuth and API-key providers, including the expected return values. It also warns of consequences if not used before 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 provided, but description discloses tool returns OAuth URL, requires user interaction, and will fail with 'Profile ID required' if missing. Does not cover permissions or rate limits, but for a connect tool this is sufficient.

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

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

Description is front-loaded with purpose and includes a structured flow and note. Slightly long but 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?

No output schema, but description explains return value (OAuth URL), prerequisites, failure mode, and ties to sibling tool. Covers the entire user flow adequately.

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 4 parameters have schema descriptions (100% coverage). Description adds value by explaining platform enum, profileId sourcing, and redirectUrl default, and the failure behavior for missing profileId.

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

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

The description clearly states the tool connects social accounts for posting, lists supported platforms, and distinguishes from sibling chieflab_list_publish_accounts by specifying the flow and output (OAuth URL).

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' and provides a standard flow, including how to obtain the required profileId. Names sibling tool for confirmation. Doesn't explicitly list when not to use, but context is clear.

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

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

No annotations provided, so description carries full burden. Mentions that each tenant gets its own brand context, voice samples, memory—important side effects. Lacks details on immediacy, reversibility, or authorization needs.

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

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

Concise single sentence plus usage prompt; no fluff. Front-loaded with 'USE WHEN' for quick identification.

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?

Adequate for a creation tool with no output schema. Explains purpose and scope but could mention return value (e.g., created tenant object) or error conditions.

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

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

Schema coverage is 100%, so baseline 3. Description does not add meaningful extra details beyond schema field descriptions (e.g., no example values or usage hints).

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 ('create') and resource ('tenant'), with context of isolating brand context per user. Differentiates from siblings like chieflab_list_tenants and chieflab_set_tenant_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?

Includes explicit 'USE WHEN' directive with example scenarios, guiding the agent to appropriate context. Lacks explicit when-not-to-use or alternative tools, but context is clear.

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

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

No annotations provided, so description must disclose behavioral traits. It only lists content types and filterability, but omits whether the operation is read-only, destructive, requires auth, or any side effects. Significant gap.

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 redundant words. Front-loaded with purpose and content. Every part earns its place.

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

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

No output schema, no annotations, and incomplete parameter info. Description doesn't cover return format, pagination, or workspace scoping. Inadequate given 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 has 33% description coverage. Description adds context only for 'bucket' ('Filterable by bucket'), but leaves 'limit' and 'workspaceId' unexplained. Inadequate for 3-param tool with low schema coverage.

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

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

Description clearly states tool lists specific CS-ops items (blocked launches, missing approvals, etc.) and is differentiated from sibling tools like chieflab_launch_product or chieflab_list_tenants.

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 to triage what's stuck' and mentions filterability by bucket, providing clear usage context. Lacks explicit when-not-to-use or alternatives, but sufficient for its simplicity.

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

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

No annotations are provided, so the description must disclose behavioral traits. It describes the tool as a lookup that returns a tool name, implying a read-only operation, but does not mention side effects, permissions, or error handling. This is adequate but leaves 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 extremely concise—two sentences that front-load the tool's purpose and usage context without extraneous information. Every sentence serves a clear purpose.

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

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

Despite having no output schema, the description adequately explains the tool's return value (the next tool to call) and its context (blocked channel). It covers the essential information for an agent to decide whether to use this tool.

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

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

Schema coverage is 100% for the single parameter 'channel'. The description mentions channel id examples but adds no new meaning beyond the schema's description. Therefore, 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 the tool's function: returning the next tool to call to unblock a typically blocked channel. It explicitly names the two possible return values (chieflab_connect_provider and chieflab_use_manual_fallback), which distinguishes it from siblings.

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 context: 'USE WHEN the user clicks an unblock button or the agent decides which channel to wire next.' This gives clear guidance on when to invoke the tool, though it does not explicitly list cases when not to use it.

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

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

No annotations provided, so description carries full burden. It details what the tool accomplishes: turning the product into a loop with launchPack, signed reviewUrl, approval-gated actions, 24h measurement, memory, next move, moneyLoop, and agentDependency. Also recommends prerequisite 'Gather repoContext first.' Lacks explicit mention of side effects like creation or mutation, but overall transparent.

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

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

Description is fairly long but front-loaded with purpose and usage. Each sentence adds value given the tool complexity. Could be slightly more concise but structure is logical and complete.

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 9 parameters, nested objects, and no output schema, the description covers prerequisites, usage triggers, outcomes, and guidance. It does not explain return values explicitly but mentions outputs like launchPack, reviewUrl, etc. Overall sufficient for the complexity.

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

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

Schema coverage is 100%, and description adds significant meaning: defaults for channels, recommended nature of repoContext, clarification of outputMode values ('context | draft | full'), and relationship between productUrl and productDescription. Provides 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?

Explicitly states it is an outcome-named alias for chiefmo_launch_product, lists specific user queries that trigger it, and distinguishes from sibling tools like chiefmo_diagnose_marketing. The verb 'turn the product into' plus resource 'repo-grounded money/distribution loop' provides a specific purpose.

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

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

Provides explicit when-to-use scenarios: 'USE WHEN a coding agent just built, shipped, or deployed something and the user asks...' and includes a list of example user queries. Also gives routing guidance: 'Route exactly like chiefmo_launch_product; 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?

With no annotations, the description bears full responsibility and does well by detailing internal composition of chieflab-post and chieflab-email, approval-gated publishActions, signed reviewUrl, and 24h measurement queue.

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 packing much information, but it lacks structure like bullet points or clear separation. It is moderately concise but could be better organized 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?

Despite describing the high-level orchestration process, the tool has 10 parameters, nested objects, and no output schema. The description does not cover parameter usage or return values, leaving the agent underinformed for a complex 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 description provides no explanation of any of the 10 input parameters. Given 0% schema coverage, the agent receives no guidance on parameter meaning or usage, leaving a significant gap.

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

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

The description clearly states it is an orchestrator for an end-to-end launch loop, listing specific channels and steps. It distinguishes itself from the sibling tool chiefmo_launch_product by noting it is a spec-renamed alias, providing unique identity.

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 identifies it as the 'primary' operator and a reference implementation, giving implicit context for usage. However, it lacks explicit when-to-use or when-not-to-use guidelines compared to other sibling tools.

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

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

No annotations provided, so description carries burden. It describes a read operation without side effects, but does not explicitly state non-destructive nature or any other behavioral traits.

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

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

Description is well-structured: first line states purpose, then output format, then usage examples. 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 simple tool with one optional parameter and no output schema, description fully explains what the tool returns (grouped catalog with capabilities and providers) and when to use it.

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

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

Schema coverage is 100% and description adds context by listing categories and explaining that category parameter filters the result, enhancing understanding 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?

Description clearly states it lists available channels, enumerates many examples, and explains output grouping and capabilities. Distinguishes from sibling tools by focusing on channel catalog rather than 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?

Explicitly provides trigger queries and recommends use before calling chiefmo_launch_product, giving clear when-to-use guidance.

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

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

No annotations exist, so description carries full burden. It explains output format and usage context (drives dashboard panels), but lacks details on permissions, rate limits, or side effects. Since it's a read operation, the description is adequate but not detailed.

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

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

The description is extremely concise—two sentences. First sentence defines output keys and scope, second gives usage guidance. No wasted words or repetition.

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

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

Given no output schema, the description explains return format sufficiently. It also provides usage context. However, it does not mention potential edge cases like empty catalog or error conditions, which would make it more complete.

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

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

Schema coverage is 100% with a single optional workspaceId parameter described as 'Optional workspace id.' The description does not add further semantics about default behavior or constraints, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns readiness state for every channel in the catalog for the current workspace, using specific terms like ready, provider, blocker, etc. It distinguishes purpose from siblings like chieflab_list_available_channels by focusing on readiness.

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 tells when to use: when user asks about channels they can publish to right now or before chiefmo_launch_product. It provides concrete query examples, though it doesn't list when not to use or explicitly name alternatives.

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

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

With no annotations, the description discloses that it returns all connectors across operators with OAuth-live status, distinguishing live data from mock snapshots. It does not mention read-only nature or permission requirements, but the behavioral context is good for a list operation.

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

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

Two sentences with clear front-loading: first sentence states purpose, second specifies returns. No wasted words.

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

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

For a simple list tool with no parameters and no output schema, the description fully explains what it returns (all connectors with OAuth-live status) and scope (per workspace, across all operators). Complete for its 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 is empty, so schema coverage is 100% trivially. The description adds no parameter info (none needed). Baseline 4 is appropriate for a parameterless tool.

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 third-party connectors connected to the workspace, with example queries. It distinguishes from siblings like chieflab_connector_status (specific status) and chieflab_list_available_channels (available channels) by explicitly focusing on connectors with OAuth-live 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 you want to know which third-party connectors are connected' and provides sample queries. However, it does not mention when not to use or list alternatives among siblings, so it lacks exclusions.

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

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

Description is a read operation but does not explicitly state non-destructive behavior or side effects. With no annotations, could be improved by clarifying it only lists data and does not modify anything.

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

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

Two sentences, front-loaded with usage context, no extraneous words. Every sentence serves a purpose.

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

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

Given simple tool with one optional param and no output schema, description covers prerequisite (API key), return value, and usage context. Lacks only a mention of response format, which is acceptable.

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

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

Schema coverage is 100% for the single optional parameter. Description adds context that it returns data for the workspace, but does not significantly enhance meaning 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?

Description specifies it lists verified Resend sender domains (from addresses) for the workspace, with example user queries. Distinguishes from sibling tools like chieflab_set_resend_key.

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

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

States explicit usage trigger: 'USE WHEN you need to know which from addresses chiefmo_send_approved_email will accept'. Also mentions prerequisite of RESEND_API_KEY, providing 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?

With no annotations, the description must fully disclose behavior. It mentions sorting but omits that this is a read-only operation, does not mention error handling, pagination, or authentication 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?

Two concise, front-loaded sentences communicate the core purpose and a key usage hint without any redundant information.

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

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

Given the lack of output schema and annotations, the description does not explain the return format, parameter details, or error behavior, making it insufficient for reliable agent 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 0%, yet the description provides no explanation of either parameter (limit, workspaceId), leaving the agent to infer their meaning solely from the schema.

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

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

The description clearly states the tool lists launch templates for the workspace, sorted by most recently created, and distinguishes it from sibling tools like chieflab_save_launch_template by indicating it is for reading lists.

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

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

The description explains when to use this tool (to list templates) and provides an explicit usage scenario: passing a label to chiefmo_launch_product. However, it does not explicitly state when not to use it or alternative tools for other purposes.

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

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

No annotations provided. Description explains it lists playbooks with details, implying read-only behavior, but does not explicitly state non-destructive nature or other traits. Adequate but not rich.

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

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

Single, well-structured sentence with essential information front-loaded. No wasted words.

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

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

Given no output schema, description fully explains what the tool returns: list of playbook types and their attributes. Complete for its intended 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?

Input schema has zero parameters, so description adds no parameter info. Baseline is 4 for no parameters.

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

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

The description clearly states that the tool lists ChiefLab launch playbooks with specific types (devtool, saas, etc.) and details (channel mix, angle, ICP). It distinguishes itself from the sibling tool 'chiefmo_launch_product' by indicating its use 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 states when to use: 'before calling chiefmo_launch_product' and 'to pick productType explicitly when auto-detection is wrong'. Provides clear context and alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns connected accounts and accountIds, implying a read operation. It also notes the API key prerequisite. Missing details on pagination, error handling, or idempotency, but adequate for a simple list tool.

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

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

Two sentences, front-loaded with 'USE WHEN', no redundant information. Every sentence is essential and well-structured.

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

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

Given the simple tool (one optional param, no output schema, no nested objects), the description provides necessary context: what it returns, why it's used, and a prerequisite. Lacks mention of edge cases like no connected accounts, but minor.

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

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

The input schema has 100% description coverage for the one optional parameter workspaceId. The description does not add additional meaning about this parameter beyond the schema; it focuses on the purpose of the output. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'list' and resource 'publish accounts', provides example user queries, and distinguishes from any sibling tool by specifying it returns accountIds for publishing. It 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?

Explicitly says 'USE WHEN you need accountIds before publishing', giving clear context. It also mentions the API key requirement. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, which is a minor gap.

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

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

With no annotations, the description discloses that the tool is a read operation returning active tenants by default and how to get other statuses. It does not discuss rate limits or permissions, but for a simple list tool, this is sufficient.

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

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

Two sentences with zero wasted words. First sentence gives purpose and usage patterns; second specifies defaults and filter options. Highly 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?

The description covers the tool's purpose, default behavior, and parameter use. For a simple list tool with no output schema, it is mostly complete, though it could mention the response format (e.g., names and IDs).

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 only parameter 'status' is fully described in the schema (100% coverage). The description adds natural language examples and restates the default, but does not provide significant new meaning beyond the schema.

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

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

Description clearly states the tool lists tenants in the workspace, backed by natural language examples ('list my tenants', 'show me all customers I've onboarded'). It distinguishes from sibling tools like chieflab_create_tenant and other list tools.

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

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

Provides explicit usage context ('USE WHEN you want to see...') and explains default behavior. However, it does not mention when not to use it or suggest alternative sibling tools for related tasks.

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

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

No annotations are provided, so the description must cover behavioral traits. It explains that the tool reads data and returns metrics/brief, implying a read operation. However, it does not mention permissions, rate limits, or any potential side effects, 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 short (two sentences) and front-loaded with key information. It is mostly concise but includes some jargon ('Zernio engagement') that may not be universally understood.

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 (no output schema, 2 parameters), the description is incomplete. It fails to explain what the returned 'structured metrics' include or the meaning of the input parameters. The agent needs more context 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?

The description provides no information about the parameters (runId, workspaceId) beyond what is in the schema. With 0% schema coverage, this is a significant omission. The agent cannot infer parameter semantics from the 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 explicitly states the tool's function: '24h post-launch readback' that pulls data from specific sources (Zernio, GA4, Search Console) and returns structured metrics plus a brief. It also clarifies it is a renamed alias of chiefmo_post_launch_review, distinguishing it from siblings.

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 indicates the tool is for '24h post-launch readback,' providing clear timing context. However, it lacks explicit guidance on when not to use it or alternatives beyond the alias mention.

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. Description discloses 'approval-gated' and 'spec v0.1 conformant' but lacks details on side effects, authentication needs, rate limits, or data mutation beyond publishing.

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 includes extraneous phrases like 'Operator: chieflab-post (primary)' and 'spec v0.1 conformant' that add little value. Could be more concise while retaining key info.

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 8 parameters, no output schema, and no annotations, description covers purpose and usage context but omits parameter details and return value format. Leaves gaps for an agent to infer.

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 13% (only 'channel' described). Description references 'channel + product context' but does not explain other 6 parameters (goal, brand, tenantId, productUrl, repoContext, workspaceId, idempotencyKey). Incomplete.

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 identifies tool as a single-channel publish loop, accepts channel and product context, returns draft/publishAction/reviewUrl. Distinguishes from sibling 'chieflab_launch_product' by calling it 'full launch loop overkill'.

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

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

Explicit usage examples: 'post this to linkedin', 'draft a hacker news submission', 'send a tweet about this'. States when not to use ('full launch loop is overkill') and hints at fallback to launch handler.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It describes the three main effects (status update, proof persistence, metrics queuing) but omits details on authorization, idempotency, or rate limits. The description is 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?

The description is well-structured with a leading 'USE WHEN' statement. It is concise but covers necessary details in a few sentences. Could be slightly shorter, but no redundant 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, the description does not explain return values. It does adequately describe the side effects (status change, proof asset, metrics queue). With 5 parameters and high schema coverage, the description is mostly complete but lacks output documentation.

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%: all 5 parameters have descriptions in the input schema. The description adds context by explaining the purpose of 'actionId' and 'publishedUrl' and notes that 'notes' persist into the P9 brain, but this information largely overlaps with the schema descriptions. Baseline 3 applies since schema already covers parameters well.

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 specific action: recording a manual publish URL back to ChiefLab. It details the exact operations (status flip, proof persistence, metrics queuing) and distinguishes from sibling tools like chieflab_use_manual_fallback and other record 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 begins with 'USE WHEN' and explicitly states the prerequisite (manual post to a channel from chieflab_use_manual_fallback). It explains why the tool is necessary ('Without this tool, manually-posted channels are lost'), providing clear context. However, it does not mention when not to use the tool or alternative 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?

Despite no annotations, the description discloses key behaviors: it closes the orchestration loop, is idempotent (replaces prior rendered body on second call), and writes to the reviewUrl so reviewers see real text. No contradictions.

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

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

Description is somewhat long but each sentence adds value: use case, orchestration context, parameter guidance, idempotency. Could be slightly trimmed but remains focused. No wasted sentences.

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

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

Tool is simple (4 params, 2 required, no output schema). Description explains idempotency and where to find assetId. For a write operation, this covers the essential context. Could mention potential error states, 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 value by explaining the purpose of each parameter beyond the schema: body is 'final rendered copy', assetId source is clarified, renderedBy for audit, workspaceId optional. This adds meaningful context.

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 writes rendered copy from a launch-pack brief for human review. It specifies the verb 'writes' and the resource 'reviewUrl', and distinguishes from siblings like chieflab_brain_read by explaining the orchestration loop.

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

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

The description explicitly provides a use case ('USE WHEN your agent's LLM has rendered the final copy...') and explains the orchestration flow. However, it does not explicitly mention when not to use this tool or list alternative tools 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?

Discloses that data is stored per tenant and that future prompts will ground against approved tone and avoid rejected patterns. The 'rejection becomes memory' loop is described. No annotations, so description carries burden well; could still mention if data is appended or overwritten.

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

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

Description is front-loaded with usage condition, then explains mechanism. It is informative but slightly verbose; every sentence adds value, but could be tightened.

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 main functionality and outcome (learning loop). Lacks details on error handling or multiple calls behavior, but for a data recording tool, it is sufficiently complete for an agent to decide 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?

Description adds meaning to parameters by explaining the kind values (approved/rejected/reference) and the purpose of feedback field. Schema coverage is 80% but descriptions are brief; this context helps the agent understand usage 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?

Description clearly identifies the tool as storing approved/rejected voice samples per tenant to influence future generations. It uses specific verbs and distinguishes the purpose from sibling tools like chiefmo_record_brand_voice by focusing on feedback loop.

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

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

Explicit 'USE WHEN' triggers (user approves/rejects draft) provide clear guidance. However, no explicit mention of when not to use or alternatives among siblings, though context implies specific scenario.

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 transparency burden. It discloses persistence ('persists into the P9 brain') and downstream reading, but does not clarify overwrite behavior (append vs replace), required authorization, or concurrency effects, leaving gaps 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 two concise sentences, front-loaded with the key action and examples. Every sentence adds value—usage context and persistence. No redundancy or wasted words.

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

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

Given the tool has 3 parameters (one nested), no output schema, and no annotations, the description explains purpose and downstream impact but omits return value/confirmation, error handling, and behavior on repeated calls. Adequate but with notable gaps.

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

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

Schema coverage is high (67% with descriptions), so the baseline is 3. The tool description provides examples of preference content but does not add structural detail beyond the schema's description of the 'preference' object or clarify the optional workspaceId parameter meaningfully.

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

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

The description explicitly states the action ('record a workspace's per-job preference') with concrete examples ('always use the founder LinkedIn account'), clearly identifying the verb and resource. It distinguishes from sibling tools like chiefmo_launch_product and brain_read by focusing on writing preferences.

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 that the recorded preference influences chiefmo_launch_product, providing clear context for when to use the tool. However, it does not specify when not to use it or mention alternative tools (e.g., chieflab_set_tenant_context) that might serve different purposes, slightly reducing guidance.

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

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

No annotations provided, so description carries full burden. It discloses that the tool checks readiness, returns whether ready or still blocked with connect path. It implies a non-destructive check. It does not mention permissions, side effects, or rate limits, but for a simple retry check it is adequate.

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

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

The description is concise at 2-3 sentences, front-loaded with the main purpose, and structured logically: action, return, usage condition. Every sentence adds value with no redundancy.

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

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

The description covers return values (ready or still blocked with path) and suggests next steps. With no output schema, this is helpful. However, it lacks mention of prerequisites (e.g., action must exist) or error cases. Given the tool's simplicity, 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 description adds no parameter information beyond the schema. The schema describes `actionId` but not `workspaceId`. With 50% schema description coverage, the description should compensate for the missing `workspaceId` description but fails to do so. No additional meaning or format details 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's purpose: 're-check a blocked publishAction's connector readiness.' It specifies the resource (blocked publishAction) and verb (re-check). It distinguishes from siblings by being specific to retrying a blocked action after a provider connection, not just general connector 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 the user has just connected a missing provider and the agent needs to know if the action can fire.' This provides clear context for usage. It also suggests follow-up actions (re-fire specific tools). However, it does not explicitly state when not to use or list alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses that productUrl and assets are not saved (exclusions) and implies mutation. However, it does not detail side effects like overwriting existing templates, permission requirements, or return values, leaving moderate 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?

Three sentences with no fluff. The first sentence states purpose and content, the second gives usage timing, and the third clarifies exclusions. Every sentence adds value, making it efficient and front-loaded.

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

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

Given the complexity (10 parameters, nested objects, no output schema, no annotations), the description covers core purpose, exclusions, and usage timing. However, it omits details about required vs. optional parameters (only label is required) and does not elaborate on nested objects like icp or brand, leaving some gaps for a complete 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 40%, with some parameters having descriptions (label, description, sourceLaunchId, productType). The description clarifies the purpose of channels, angle, brand, and defaultRepoContext by labeling them as 'shape.' For the many undocumented parameters (icp, brand, workspaceId, etc.), the description provides indirect meaning but lacks explicit field-level detail, setting a baseline of 3.

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

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

The description clearly states the tool saves a 'launch's shape' (channels, angle, brand, default repo context) as a reusable template. It specifies what is excluded (productUrl, assets), providing a precise verb+resource. This distinguishes it from related siblings like chieflab_list_launch_templates.

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 advises to use this tool 'AFTER a launch performs well so the next one in the same shape skips re-asking,' giving clear context. It does not mention when not to use or provide alternatives, but the guidance is sufficient for typical scenarios.

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

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

With no annotations provided, the description carries the full burden. It discloses the quality dimensions and the prerequisite, but does not clarify whether the tool mutates data (writes scores) or is read-only, nor does it mention permissions or response format.

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

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

The description is a single, well-structured sentence that front-loads the key action and dimensions, then provides necessary context 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 covers purpose, usage context, and prerequisites, but lacks information about return values (no output schema) and potential side effects. For a tool that re-scores, the output is important 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%; both parameters are documented in the schema. The description adds useful context for runId (source and effect) but workspaceId is only restated. Baseline is 3, and the added value is marginal.

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: re-scoring a launch pack on six named quality dimensions. It distinguishes itself from sibling tools by specifying the prerequisite (chieflab_record_rendered_copy) and contrasting with the earlier score from chiefmo_launch_product.

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

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

The description explicitly states when to use this tool: 'Use AFTER chieflab_record_rendered_copy populates rendered bodies' and explains why the earlier score is insufficient. It provides clear context and ordering but does not explicitly 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool is approval-gated and an alias, but does not detail error handling, idempotency, or return behavior. 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?

The description is concise at two sentences, front-loading the key purpose and usage. Every sentence adds value with 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?

Given no output schema, no annotations, and 0% schema description coverage, the description does not cover the full context. Missing details on runId, idempotencyKey, return values, and failure modes make it incomplete for a tool with three parameters.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains actionId's origin (publishActions) but does not mention runId or idempotencyKey. This leaves significant gaps for the agent.

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

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

The description clearly states the tool's purpose: an approval-gated email send via Resend. It specifies the verb 'send', the resource 'email', and the approval context. It also distinguishes itself from siblings by noting it is an alias of chiefmo_send_approved_email.

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

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

The description provides clear guidance on when to use this tool: after user approval, passing actionId from a prior launch's publishActions. It implicitly tells the sequence but does not explicitly state when not to use it or list alternatives.

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

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

With no annotations provided, the description reveals that the API key is 'stored encrypted at rest', which is important for security. However, it doesn't disclose whether setting a new key overwrites the old one, rate limits, or other side effects.

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

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

The description is concise with three sentences, front-loading the usage condition ('USE WHEN'). 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 no annotations, no output schema, and simple parameters, the description covers purpose, usage, and key behavioral detail (encrypted storage). It could mention error handling or overwrite behavior, but overall it's 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 coverage is 100%, so the schema already documents both parameters. The description adds limited extra meaning: for apiKey it mentions 'encrypted at rest', and for workspaceId it says 'optional'. This adds some value but is 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?

The description clearly states the action ('stores the Resend API key encrypted') and the usage scenario ('USE WHEN the user wants to bring their own Resend account'). It distinguishes itself from sibling tools by specifying the purpose related to per-workspace email sending.

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 starts with 'USE WHEN', providing clear context for when to use this tool. It mentions dependent tools (chiefmo_send_approved_email, chieflab_list_email_senders), but doesn't explicitly state when not to use or provide alternative tool names.

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?

Description discloses upsert behavior and states that operator outputs will ground against this context. However, with no annotations, it should detail merge behavior on update, permissions, or side effects. The description is adequate but leaves 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?

Description is front-loaded with usage instructions and examples. It is clear and efficient, though the examples could be slightly condensed. Overall, well-structured for an AI agent.

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

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

For a tool with 9 parameters, no output schema, and no annotations, the description provides essential purpose and impact but lacks return value description, error conditions, or parameter validation rules. It meets minimum viability.

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 only 33%, but the description lists most relevant fields (brand, audience, voice, pillars, competitors, content angles, positioning risks) and explains their role as brand context. It adds meaning beyond the schema but does not detail each parameter's specific use 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 starts with a specific use case ('onboarding a new tenant or refreshing their brand') and gives example queries. It clearly identifies the action (upsert brand context) and resource (tenant context). It also distinguishes from sibling tool chieflab_create_tenant by suggesting pairing.

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

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

Explicitly states when to use ('USE WHEN onboarding a new tenant or refreshing their brand') and provides example natural language prompts. It recommends pairing with chieflab_create_tenant, but lacks explicit when-not-to-use or alternative tools for similar tasks.

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 the operation adds or updates and returns the updated member record, but lacks details on side effects (e.g., idempotency, error cases, permission requirements).

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

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

The description is two sentences, front-loaded with the action and result. No unnecessary words or redundancy.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is somewhat complete for a simple mutation but lacks error handling, role validation details, and prerequisites. With siblings like chieflab_workspace_members, the mutation intent is clear.

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

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

Schema coverage is 50%, with descriptions for role and userId only. The description mentions the allowed roles, which is already in the schema, but does not explain email or workspaceId. It adds minimal value 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 action (Add or update) and the resource (workspace member's role), listing the allowed roles. This distinguishes it from sibling tools like chieflab_workspace_members, which likely lists members.

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

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

No explicit guidance on when to use this tool vs alternatives, such as when to add vs update, or prerequisites like workspace existence. The description is purely functional.

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 key is 'stored encrypted at rest', which is a useful behavioral trait. However, with no annotations provided, the description could have covered more details such as error handling, idempotency, or authorization requirements. The encryption note adds value but leaves room for improvement.

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

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

Three sentences, each with a clear purpose: usage condition, dependent tools, and API key source. Front-loaded with imperative instruction. No redundant or unnecessary text.

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

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

For a simple two-parameter tool with no output schema, the description covers when to use, what it does, how it relates to other tools, and how to get the key. It is complete enough for an agent to correctly select and 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?

Schema coverage is 100% and the description adds little beyond the schema: it mentions the API key format (sk_live_...) but that is already in the schema's description. The optional workspaceId is not elaborated. Baseline is 3 due to high schema coverage, and the description provides marginal extra insight.

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

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

The description clearly states the tool's purpose: 'USE WHEN the user wants to bring their own Zernio account' and specifies it stores the API key encrypted. It identifies the resource (Zernio API key) and the action (store), distinguishing it from other config tools on the server.

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 with 'USE WHEN' and lists dependent tools that require this key, providing clear context. It also tells users where to obtain the API key. However, it does not mention when not to use it or alternative approaches, leaving some gap.

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: creates workspace, returns apiKey, URL expires in 1 hour, single-use, IP-rate-limited. It also describes the agent-first signup flow, ensuring the agent understands the side effects and constraints.

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

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

The description is a single paragraph that front-loads the trigger condition, then covers main action, preferred flow, and fallback. It is concise but dense; could be more structured, yet 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 3 optional parameters, no output schema, and the signup context, the description covers purpose, trigger, flow, return values (apiKey, deliveryUrl), and constraints. It is complete for an agent to select and invoke without gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that agentName logs for support, contactEmail for future notifications, and workspaceLabel defaults to 'default'. This provides context beyond schema descriptions.

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

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

The description clearly states the tool creates a new workspace and returns an API key, triggered by a 401 error when the user has no API key. This is a specific verb+resource and distinguishes from sibling tools like chieflab_brain_read.

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' with the condition (no API key and 401 error). Provides a preferred flow (write to MCP config) and a fallback (deliver URL), giving clear guidance on when and how to use.

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

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

No annotations provided. Description mentions approval requirement and returns a brief with tracking template, but does not disclose side effects, permission needs, or whether it modifies state.

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

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

Three sentences, front-loaded with usage condition and output. Could be slightly trimmed but is efficient and well-structured.

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

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

Given no output schema, description explains return components (text, checklist, URL, measurement template) and integrates with other tools (chiefmo_record_proof). Provides sufficient context for agent 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 covers 100% of parameters. Description adds qualitative context (e.g., 'Override the channel', 'ChiefLab pulls the brief, channel hints, and brand voice'). Adds value beyond schema.

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

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

Description clearly states the tool is for blocked manual-only channels, returns a paste-ready brief. Differentiates from siblings like chiefmo_publish_approved_post (automated) and chieflab_launch_product (general launch).

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 launch action is blocked because the channel has no automated publish path' and 'Approval-gated upstream.' Provides clear context but does not explicitly list alternatives or when not to use.

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

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

No annotations are provided, so the description must convey behavioral traits. It correctly identifies the tool as a read/list operation ('List workspace members'), but does not disclose any potential limits, pagination, or authorization requirements. The description is adequate for a simple read 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, focused sentence that conveys the tool's purpose and a common use case. It is not overly verbose, but could include a brief note on the parameter.

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 core functionality and a use case, but lacks details on required input (workspaceId) and return format. Given the tool's simplicity (one param, no output schema), the description meets minimum viability but is not fully comprehensive.

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

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

The schema has one parameter (workspaceId) with 0% description coverage. The description does not mention the parameter or explain that it is required to filter by workspace. The agent must infer the parameter from context, which reduces 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 'List workspace members with roles' and enumerates specific roles (owner/approver/editor/viewer), making the tool's purpose very specific. It distinguishes itself from sibling tools like chieflab_set_workspace_member.

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 use case: 'Use for team management and to see who can approve publishes.' This gives context for when to use it, but 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, so description carries full burden. Describes a read operation but adds no behavioral details beyond purpose—no mention of side effects, rate limits, or response size. Adequate but minimal.

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

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

Two efficient sentences: first defines action and metrics, second gives usage guidance. No wasted words, front-loaded with purpose.

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

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

Lists all metrics but lacks output format description (e.g., JSON structure). Given low complexity and one optional parameter, this is nearly complete.

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

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

Schema covers 100% of parameters; description adds no new meaning. The optional workspaceId is already described in schema. Baseline score of 3.

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

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

The description clearly states the action ('Get scale metrics') and lists specific metrics (launches, repeat-launch rate, etc.), distinguishing it from sibling tools like chiefmo_measure_launch_results which likely focus on other metrics.

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 for the scale dashboard or 'how is this account doing' checks', providing clear context. However, it does not mention when not to use or offer alternatives.

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

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

No annotations provided, so description must cover behavioral traits. It discloses the approval effect and executor activation but does not mention error handling, idempotency, or side effects of approving an invalid actionId.

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, front-loading the core purpose in the first sentence. It efficiently conveys usage context without extraneous detail. Could be slightly tightened but overall well-structured.

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

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

Given no annotations or output schema, the description covers the high-level workflow, usage trigger, and parameter derivation. Sufficient for an agent to select and invoke the tool correctly, though edge cases (invalid actionId) are not addressed.

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

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

Schema coverage is 100% with descriptions. Description adds context: actionId is preferred, id is legacy alias, and explains how to derive the value from launch response. This enhances schema information.

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 approves a specific ChiefMO publish/send action, enabling its executor to fire. It specifies the verb 'approve' and the resource (action), distinguishing it from sibling executors like 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?

Explicitly tells when to use: when user says 'approve <channel>', 'approve all', etc., in IDE chat. Provides detailed workflow on how to obtain the actionId from the launch response. Lacks explicit 'when not to use' but is otherwise 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?

The description says 'Approve' which implies a state change, but no annotations are provided. It does not disclose consequences, required permissions, reversibility, or side effects of approval.

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, but it is so brief that it sacrifices informativeness. It could include more details without becoming verbose.

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

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

Given the tool has one parameter and no output schema, the description should explain the parameter and the outcome of approval. It fails to provide this context, leaving the agent with minimal information 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?

The only parameter 'id' has no description in the schema (0% coverage) and the tool description does not explain what the id represents, such as whether it's a run ID or another identifier. The format or source of the id is missing.

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

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

The description clearly states the action (approve) and the object (ChiefMO run that is awaiting approval). However, it does not differentiate from the similar sibling tool 'chiefmo_gtm_run_approve' or explain the relationship to 'chiefmo_reject_run'.

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

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

No guidance is provided on when to use this tool versus alternatives like 'chiefmo_gtm_run_approve' or under what circumstances a run should be approved. The description lacks context on prerequisites or conditions.

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

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

With no annotations, the description carries full burden. It accurately describes the check behavior and return format but omits any discussion of side effects, rate limits, or authentication needs. No contradictions exist.

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 of three sentences. It front-loads the core action and quickly adds context and output details. No extraneous information.

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

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

Given no output schema, the description explains the return format (ranked list with status and suggested fixes). It also notes dependencies (company brain) and is complete for a pre-publish gate 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 description adds value by explaining that claims are checked against the 'company brain (repo facts, proof assets, brand voice)'. This gives meaning beyond the schema's parameter 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 identifies the tool as scanning drafts for unsupported claims before publishing. It specifies content types (post, email, blog, ad, landing copy) and expected output (ranked list with statuses and fixes). This differentiates it from siblings like chiefmo_draft_blog_post or chiefmo_generate_ad_variants.

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 'Run as a publish gate' and 'BEFORE publish', providing clear context for when to use. However, it does not mention when not to use or list alternative tools, leaving some ambiguity for the agent.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation ('Return') but does not explicitly state side-effects, authentication needs, or rate limits. The listing of output components adds some transparency, but more detail on behavior would be beneficial.

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, no fluff. First sentence defines output, second lists use cases. Front-loaded and efficient.

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

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

Given no output schema and multiple output components, the description covers the main elements and use cases. It does not detail the structure of the returned data beyond listing sections, which is sufficient for an agent to understand the tool's capability.

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 only 33% (only 'format' described). The description clarifies that 'format' defaults to markdown and accepts 'json', adding value. However, 'tenantId' and 'workspaceId' are left without explanation, so the description only partially compensates for the low schema coverage.

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

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

The description clearly states the tool returns the 'full rendered company brain' and lists its components. The verb 'Return' and resource definition are specific. However, it does not explicitly differentiate from the sibling 'chieflab_brain_read', which may serve a similar function, though the description is sufficiently detailed.

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 use cases: 'inspect what ChiefLab knows, debug grounding, or pipe into a custom prompt.' This provides clear context for when to use the tool, but it does not mention when not to use it or name alternatives, which would improve the score.

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 clearly explains the tool's behavior: it can surface reviewUrl, execute an approved action, wait for measurement, measure results, or prepare the next move. It also notes that ChiefLab remembers approval state, actionIds, etc., providing good behavioral context.

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

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

The description is two sentences, front-loaded with the primary purpose, and uses clear, direct language. Every part earns its place, with no redundancy or extraneous information.

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

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

Given the tool's complexity (state-resuming loop with multiple possible actions) and the absence of an output schema, the description provides sufficient context about what the tool does and its place in the workflow. It could mention potential return values more explicitly, but overall it is 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 100% coverage, so baseline is 3. The description adds that runId is the launchId/runId returned by prior tools and that workspaceId is optional (usually supplied by auth), which adds useful context beyond the schema.

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

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

The description clearly states it resumes a ChiefLab launch loop from a runId, specifying the verb 'Resume' and the resource 'launch loop'. It also distinguishes itself from siblings by referencing the context of prior calls like 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?

The description explicitly states when to use this tool ('USE WHEN an agent has already called chieflab_get_users_after_build / chiefmo_launch_product and needs the exact next action') and explains the stateful behavior of ChiefLab, which helps the agent understand why this tool exists and when it is appropriate.

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, and the description does not disclose any behavioral traits, side effects, permissions, or what 'create' entails beyond the minimal description.

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

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

The description is a single concise sentence with no extraneous information, but front-loading is limited.

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

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

Given no output schema and no annotations, the description is too minimal. It does not explain what the tool returns or what side effects occur, leaving significant gaps for a creation action.

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 does not add significant meaning beyond the parameter descriptions. 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 creates a ChiefMO marketing run from a business goal, using a specific verb and resource. It is distinct from sibling tools like chiefmo_gtm_run_start.

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

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

No guidance on when to use this tool versus alternatives, such as chiefmo_gtm_run_start or other creation tools. Missing context on prerequisites or scenarios.

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

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

No annotations provided, so description carries full burden. It discloses the AI model (Gemini 2.5 Flash Image), that brand context is auto-applied, and metering details with cost and credits. Does not mention auth or destructive behavior, but for a generation tool this is adequate.

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

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

Three concise sentences: first states purpose and model, second gives usage guidance, third adds sibling distinction and cost. No redundant information.

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

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

For a graphics generation tool, the description covers what it does, when to use, cost, and relationship to sibling. Missing output format, but this is typical for gen tools. Overall complete for its complexity level.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor context about brand auto-application but otherwise does not extend meaning beyond what the input schema already provides.

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

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

The description clearly states the tool generates 'social/launch graphics' and lists specific use cases: launch images, social graphics, hero images, visuals for launch. It distinguishes from sibling tool chiefmo_launch_product by noting that tool includes graphics inline, so this one is for ad-hoc generation.

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

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

Explicit 'USE WHEN' directive lists scenarios (launch images, social graphics, etc.). Also explicitly states when NOT to use: if part of a launch run, as chiefmo_launch_product already handles it. Provides alternative by name.

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 baselines are pulled live when GA4/Search Console are connected, but it does not mention any side effects, required permissions, or error handling. For a design tool that likely has no destructive effects, this is adequate but not thorough.

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

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

The description is two sentences with no unnecessary words. The first sentence defines the core function, and the second adds usage context. Every sentence earns its place, making it highly concise and well-structured.

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

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

Given no output schema, the description lists the key components of the output (hypothesis, variants, etc.), which is sufficient for an agent to understand the return value. It could mention the output format or structure, but the listed components provide reasonable completeness for a design tool.

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

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

Schema coverage is 100%, so the parameters are already documented. The description does not add extra meaning beyond what the schema provides; it only implies that 'goal' is the marketing question. A 3 is appropriate when the schema already handles parameter description effectively.

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

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

The description clearly states the tool's purpose: converting a marketing question into a runnable experiment with specific components (hypothesis, variants, metric, sample size, kill criteria). It distinguishes itself from sibling tools like chiefmo_diagnose_anomaly or chiefmo_draft_blog_post by focusing on experiment design.

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

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

The description explicitly says 'Use BEFORE shipping a new test so you have a stop rule', providing clear when-to-use guidance. It also describes two modes (manual vs. connected to GA4/Search Console), though it does not explicitly state when not to use or list direct alternatives.

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

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

No annotations provided; the description implies read-only analysis by 'explainer' and 'proposes actions', but does not explicitly state safety or potential side effects. Could be more transparent about non-destructive nature.

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 that front-load the purpose and provide an example. No wasted words.

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

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

Covers the tool's purpose, input example, and expected output (ranked causes and actions). Without an output schema, it briefly describes the return value, which is sufficient for this diagnostic tool.

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

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

Schema coverage is 100% so the schema fully documents parameters. The description aligns with the 'goal' parameter via the example, but adds no additional semantic nuance 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 is an analytics anomaly explainer, gives a concrete example ('Search Console clicks down 30%'), and specifies that it ranks causes and proposes actions, distinguishing it from similar diagnostic 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?

It explicitly says 'Given a metric drop or spike', indicating when to use it. However, it does not mention when not to use it or provide alternatives, but the context is clear enough for the intended use case.

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

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

No annotations exist, so the description carries the full burden. It mentions that the tool is approval-gated and returns specific outputs (evidence, drafted assets, proposed actions, reviewUrl, per-tenant memory). It does not disclose any destructive potential or rate limits, but as a diagnostic tool, these are less critical. The description is transparent about its behavior and return value.

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 front-loads key information: purpose and when to use. It is concise and each sentence adds value. However, it could be slightly more structured (e.g., bullet points for return types) for easier parsing, but it remains efficient.

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

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

Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers the essential aspects: purpose, usage conditions, parameter guidance, return types, and the approval gate. It includes optional parameters like webhookUrl and idempotencyKey. It is sufficiently complete for an agent to use the tool correctly.

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

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

Schema description coverage is 100% (all 9 parameters are described). The description adds value beyond the schema by explaining the brand object's usage: 'OPTIONAL but recommended for cost + accuracy' and conditions for omitting. It also explains the outputMode parameter options in detail, aiding the agent in choosing the right mode.

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 diagnoses an EXISTING marketing program, specifies it is not for new launches, and contrasts with the sibling 'chiefmo_launch_product'. It lists what it returns (evidence, drafted assets, proposed actions, etc.), making the tool's purpose unambiguous.

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

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

The description explicitly tells when to use this tool: when the user has live campaigns and asks 'why is X not working' or wants to 'iterate on this funnel.' It also explicitly tells when not to use it: 'For first launches, prefer chiefmo_launch_product.' This provides clear decision 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 that the tool can either output markdown for manual pasting or commit directly to GitHub if connected, and that post tracking is available with Search Console/GA4. It does not explicitly mention potential side effects like file creation or overwrite, but the commit behavior is clearly indicated.

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 covering all key aspects (components, modes, tracking). No wasted words, front-loaded with the primary action.

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

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

Given no output schema, the description explains what is produced (markdown or committed post) and the components. It covers integrations and the need for prior connections. Minor gap: does not detail the return format or confirmation message, but the output is sufficiently described for an agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema: it repeats the integration context but does not elaborate on parameter usage or syntax.

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 drafts a blog post with specific components (title, slug, meta description, body, internal links, OG image prompt) and explains two modes (manual markdown vs. GitHub commit). It distinguishes from sibling content tools by mentioning 'repo-aware' and the integration with GitHub and Search Console/GA4.

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

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

Description explains the modes and integrations but does not explicitly state when to use this tool over alternatives like `chiefmo_generate_landing_copy` or `chiefmo_generate_social_posts`. Usage is implied but no exclusions or comparisons are provided.

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

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

No annotations are provided, so the description carries full responsibility. It lists outputs but does not disclose behavioral traits such as whether it is read-only, required permissions, or side effects. Without annotations, more detail would be helpful.

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

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

Two sentences front-load purpose with 'USE WHEN' and examples. Second sentence outputs key information. No extraneous text, highly 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?

Despite the absence of an output schema, the description lists all key output categories (category, audience, voice, etc.). It also notes the tool's role as a foundational step for other skills, providing complete context for an agent.

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

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

Schema coverage is 100% for the single parameter 'brandUrl', and the description adds 'URL or brand name' which mirrors the schema description. No additional semantic meaning beyond what the schema provides.

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

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

The description uses specific verb phrases like 'analyze brand X' and 'extract brand voice from this URL', clearly identifying the tool's purpose of understanding a brand. It distinguishes from siblings by positioning it as the first call for brand work, which other ChiefMO skills depend on.

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 starts with 'USE WHEN' and provides concrete examples of user requests. It also states it should be used as the first call and that other skills use its result as context, giving clear usage context and dependencies.

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. The description says 'emit a list ready to persist' but doesn't clarify if the tool itself persists data or is read-only. This ambiguity leaves the agent unsure of side effects.

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

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

Single sentence of 20 words, front-loaded with the verb 'Pull'. 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?

Despite having a nested repoContext parameter and no output schema, the description provides minimal detail about input constraints or the output format. Essential context is missing.

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

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

Schema coverage is 67% with brandUrl undocumented. The description adds no parameter context beyond what the schema provides, failing to clarify the missing brandUrl 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 extracts structured product facts from repoContext and outputs a list for persistence. It distinguishes from siblings like chiefmo_record_repo_fact which records individual facts.

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

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

The description implies use when repoContext is available and product facts are needed, but no explicit when-not or alternatives are mentioned. Siblings like chiefmo_record_repo_fact are not referenced.

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

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

With no annotations provided, the description carries full burden. It discloses the output (ad variants with angles, headlines, etc., plus a test plan), the draft-only nature, and platform scope. It does not cover authentication, rate limits, or error conditions, but for a generative tool the disclosed behaviors are sufficient and accurate.

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

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

The description is two sentences, front-loaded with the usage trigger, then concise output and constraint details. No redundant or extraneous information.

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

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

For a simple generative tool (2 params, no output schema, no annotations), the description provides key context: what the tool does, what it returns, and important constraints (drafts only, platforms). It could elaborate on the test plan or variant count, but overall covers the essentials.

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% (both parameters described in schema). The description does not add extra detail beyond the schema: it implies the 'goal' parameter captures the ad objective and target audience, but no syntax or format guidance. 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 generates paid-ad copy for Meta and Google Ads, with explicit user-intent examples like 'write Google Ads variants' and 'Meta ad creative for this campaign'. It distinguishes from sibling tools (e.g., generate_landing_copy, draft_blog_post) by specifying the paid-ad context and output (variants plus test plan).

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 begins with 'USE WHEN' and provides concrete triggers ('write Google Ads variants', 'split-test headlines'). It also states platforms ('For Meta and Google Ads') and a key limitation ('Drafts only — publishing requires approval and budget rules'). However, it does not explicitly name alternative tools for other copy types, leaving some inference needed.

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

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

With no annotations provided, the description carries full burden. It states the tool returns a draft skeleton, requires approval and ESP connection, and implies creation behavior. It does not explicitly state whether it saves data or is idempotent, but overall discloses key behavioral traits.

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

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

The description is a single, well-structured paragraph of three sentences. It is front-loaded with the usage trigger condition and every sentence adds essential information without redundancy.

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

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

For a tool with 2 simple parameters and no output schema, the description fully explains the return value (4-email skeleton with specific details) and necessary prerequisites (approval, ESP). No additional information is needed.

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

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

The input schema has 100% coverage with descriptions for both parameters (goal and brandUrl). The description adds value by providing example values for goal (welcome, nurture, win-back, launch, etc.) and clarifying brandUrl as optional context.

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 generates an email-only sequence (not a full launch) and specifies the output: a 4-email skeleton with subject line ladder, send timing, and segmentation notes. It distinguishes itself from the sibling tool chiefmo_launch_product.

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

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

The description starts with 'USE WHEN' and provides concrete examples (welcome, win-back, nurture). It explicitly says what the tool is not for ('not a full launch') and directs the agent to use chiefmo_launch_product for launch emails. It also notes that the tool only drafts, requiring approval and a connected ESP.

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 output format ('ready-to-paste markdown') and a prerequisite ('Page build/publish requires approval and a connected web tool'), but does not cover other behavioral aspects like mutability, auth needs, 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?

Three sentences with no wasted words. The first sentence efficiently combines usage guidelines with examples, the second describes output, and the third adds a key prerequisite. Could be slightly more structured, but overall concise and front-loaded.

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

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

Given no output schema, the description adequately explains the return format and includes a prerequisite. For a tool with two simple parameters, this covers the essential context. However, deeper details about markdown sections could improve completeness.

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

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

Schema coverage is 100% with both parameters described. The description adds context via examples but does not provide new semantic detail beyond the schema definitions. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose with specific examples like 'write a landing page for X' and 'rewrite my hero'. It distinguishes itself from other content generation tools by focusing on landing-page copy, though it does not explicitly name siblings.

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 'USE WHEN' pattern provides clear context for when to use the tool, with explicit examples. However, it lacks any guidance on when not to use it or alternatives, leaving the agent to infer exclusion criteria.

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

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

The description discloses what the tool returns (posts with hooks, captions, hashtags, cadence) and its draft-only nature, implying no side effects or destructive actions. Without annotations, this adds value beyond the schema.

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

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

The description is a single, well-structured paragraph with no wasted words. It covers usage, exclusions, output, and lifecycle in a logical order.

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 fully explains the return format (posts with hooks, captions, hashtags, cadence) and the overall workflow (drafts only, needs approval). No gaps.

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

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

Schema coverage is 100%, so the description adds context: 'goal' is what posts accomplish, 'brandUrl' triggers Brand DNA discovery. This clarifies usage 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: generating social-only drafts. It uses specific verbs ('draft', 'write', 'give me') and distinguishes from a key sibling ('chiefmo_launch_product') that handles full launches.

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

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

Explicit 'USE WHEN' conditions are provided, along with clear exclusion ('NOT for new product launches') and a named alternative ('chiefmo_launch_product'). It also notes that scheduling/publishing requires approval via 'chiefmo_publish_approved_post'.

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

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

No annotations exist, so description is the sole source for behavioral traits. It implies a simple read operation but does not explicitly state absence of side effects, authorization needs, or other behaviors. Adequate for a basic getter.

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 immediately conveys the purpose. Every word earns its place; 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?

For a simple fetch operation, the description is largely complete. However, it does not mention what the return value represents (e.g., full action object), though this may be inferred from context. Still sufficient for a single-parameter tool with clear siblings.

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 0% schema description coverage, the description adds no meaning to the 'id' parameter beyond the schema's type string. It does not clarify expected format, examples, 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?

The description clearly states the verb 'Get' and the resource 'one ChiefMO action by id', distinguishing it from siblings like chiefmo_list_actions which lists multiple 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?

No guidance provided on when to use this tool versus alternatives such as chiefmo_list_actions or chiefmo_get_run. The description lacks context for 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?

No annotations are provided, so the description carries the full burden. It only states 'Get one... by id' without disclosing any behavioral traits such as error handling, authentication requirements, or whether the operation is read-only (though implied). Minimal transparency.

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

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

The description is extremely concise: one short sentence with no redundancy. Every word serves a purpose.

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

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

Given the low complexity (single required param, read operation), the description is adequate but lacks details about the return value, error conditions, or expected format. No output schema exists, so the description should provide some context, which it does not.

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

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

The schema description coverage is 0%, and the description only repeats 'by id' which adds no additional meaning beyond the parameter name. It does not describe what the 'id' represents, how to obtain it, or any constraints (e.g., format).

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

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

The description clearly states the verb 'Get' and the resource 'asset', and specifies filtering by 'id'. This distinguishes it from sibling tools like 'chiefmo_list_assets' which lists assets without filtering by a single ID.

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

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

The description implies usage when you have a specific asset ID, but provides no explicit guidance on when to use this tool versus alternatives such as 'chiefmo_list_assets' or other get tools. No exclusions or context are given.

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

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

No annotations provided. Description does not disclose if this is a read-only operation, what happens if the ID is invalid, or any permissions required. For a simple get, minimal disclosure but still lacking.

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

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

Single concise sentence with no unnecessary words. Efficiently communicates the core function.

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

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

Given the low complexity (1 param, no output schema, no nested objects), the description is minimally adequate. However, it leaves out return value details and error handling, which are important for an agent deciding whether to use this tool.

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

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

Schema has 0% description coverage for the single parameter 'id'. Description only says 'by id', adding minimal meaning beyond the schema. Should explain what id refers to or format expectations.

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 verb 'Get', resource 'ChiefMO run', and method 'by id'. Distinguishes from sibling tools like chiefmo_get_action and chiefmo_get_asset.

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

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

No guidance on when to use this tool vs alternatives such as chiefmo_list_runs, chiefmo_approve_run, or chiefmo_get_skill. No context or exclusions provided.

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

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

No annotations are provided, yet the description omits behavioral details such as side effects, idempotency, or whether it modifies state. The burden is on the description, but it only states action without transparency.

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

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

Two sentences precisely deliver purpose and usage guidance with no wasted words. Front-loaded with the core action.

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

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

For a tool with no output schema and nested objects, the description lacks details on return values, error conditions, or blocking/async behavior. It covers purpose and usage but not output or execution 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 67%, and the description adds no new information about parameters beyond what the schema provides. The description's high-level usage context doesn't deepen 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?

Explicitly states 'Run one specific GTM agent in isolation, bypassing the orchestrator,' with a clear verb and resource. It distinguishes from sibling tools like chiefmo_gtm_run_start by mentioning isolation and re-runs/diffs.

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 a concrete condition: 'use when you've already collected the upstream handoffs and want to invoke a single agent for re-runs / diffs.' This implies when not to use, though explicit alternatives are not named.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only operation by stating 'Read every handoff...' but does not explicitly mention safety, permissions, or lack of side effects. This is adequate but not thorough.

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

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

Two concise sentences. The first states the purpose, the second provides usage context. 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 the tool's simplicity (1 parameter, no output schema, no annotations), the description covers purpose and usage. However, it lacks parameter explanation and does not describe the return format. It is nearly adequate but has 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?

The only parameter 'runId' has no description in the schema (0% coverage). The description does not explain what 'runId' is or how to format it. With 0% coverage, the description should compensate but fails to add any meaning.

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

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

Description clearly states 'Read every handoff emitted in a GTM run, in order.' The verb 'Read' and resource 'handoffs emitted in a GTM run' are specific. It distinguishes from sibling tools like chiefmo_gtm_run_get which deals with runs, not handoffs.

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

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

Description explicitly says 'Useful for the command center timeline and for debugging why an agent skipped (no input handoff found).' This provides concrete use cases. However, it does not mention when not to use or alternative tools, but the context is clear.

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

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

With no annotations, the description bears the full burden. It states 'Read' implying no side effects, explains key namespacing, and return type. However, it doesn't disclose error handling or behavior for missing keys. Given simplicity, it's mostly transparent.

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

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

Two sentences, front-loaded with core purpose. Every sentence adds value: first states action and scope, second gives key format and output. No redundancy or fluff.

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

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

Covers key purpose and output, but lacks details on mandatory scope parameters (tenantId, workspaceId) and behavior when key is omitted. No output schema, but description suffices for a simple read operation.

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 33% schema description coverage; the description adds no value beyond the schema for 'key' and does not explain 'tenantId' or 'workspaceId' parameters. The purpose mentions workspace and tenant but doesn't map to parameters.

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

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

The description clearly states it reads shared memory for a workspace and tenant, with examples of memory keys. It distinguishes itself from siblings like 'chiefmo_gtm_memory_set' (write) and 'chiefmo_memory_diff' (diff).

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

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

No explicit guidelines on when to use this tool versus alternatives. While the purpose is clear, there is no mention of when to read vs. set or diff, or any preconditions. Implicitly, it's for memory retrieval, but lacking explicit direction.

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 responsibility. It explains the caller-asserted nature, default sourceAgentId behavior, and appropriate use cases. However, it does not disclose whether writes are idempotent or if previous values are overwritten, but the description is still informative.

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

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

The description is two sentences, no redundancy, front-loaded with the core action, and the second sentence provides essential usage context. Every word adds value.

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

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

For a tool with 5 parameters and no output schema, the description covers purpose and usage but lacks details on parameter semantics (key format, tenantId/workspaceId purpose) and does not mention return value or error handling. 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.