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

No annotations are provided, so the description carries the full behavioral burden, but it says nothing about whether the draft is saved, sent, or returned, what permissions are needed, or what the output looks like. It only clarifies that the result contains TL;DR, metrics, wins, challenges, and asks.

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?

A single front-loaded sentence with no wasted words, listing the key sections efficiently.

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

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

For a six-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It does not explain input semantics, behavior, or return expectations.

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

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

Schema description coverage is 0% for six parameters, and the description only indirectly maps to some fields by naming sections like metrics table, wins, challenges, and asks. It does not explain the required company and month fields or the structure of the metrics objects.

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

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

The description uses a specific verb ('Draft') and resource ('monthly investor update') and names the sections produced. It is clearly distinct from siblings like weekly_plan and launch_checklist, though it does not explicitly differentiate itself.

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

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

There is no guidance on when to use this tool versus alternatives such as weekly_plan or launch_checklist, nor any prerequisites or exclusions. The monthly investor update context is implied only by the resource 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?

With no annotations, the description carries the full burden. 'Create' implies a mutation, but it says nothing about side effects, whether the checklist is persisted, what happens on duplicate product/date combinations, or what is returned. This is a significant gap for an unannotated write 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?

A single front-loaded sentence with no waste, but the brevity reflects under-specification rather than efficient communication.

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

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

Three undocumented parameters, no annotations, and no output schema — the description would need to explain inputs and results, and it explains neither. An agent cannot call this correctly without guessing at 'date' and 'extra'.

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% for three parameters. The description names only 'product' incidentally; it never explains the required 'date' format or the purpose of the 'extra' array. The description fails to compensate for the documentation 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?

States a specific verb-plus-resource: 'Create a launch checklist.' An agent immediately knows the operation and artifact produced. No sibling differentiation is offered, but the siblings (weekly_plan, pipeline_upsert, investor_update) are unrelated domains, so confusion risk is low.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites, and no statement of what preconditions (e.g., an existing product record) are needed. The single sentence gives implied usage only.

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 usefully discloses that results are ordered by stage and that all pipeline members are included, but it does not state read-only safety, pagination behavior, or what the return format looks like.

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?

A single front-loaded sentence with no wasted words. The scope and ordering are established immediately.

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

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

For a zero-parameter read-only list tool with no output schema, the description covers the essential scope and ordering. Minor gaps around pagination and return format remain, but the core call semantics are 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?

There are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed because the tool takes no input.

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?

States a specific verb ('List') and resource ('everyone in the pipeline'), plus the ordering behavior. It implicitly distinguishes itself from pipeline_upsert, but does not explicitly differentiate from the other 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 implies read-only listing but gives no explicit guidance on when to use this tool versus pipeline_upsert or the other sibling tools. No exclusions, alternatives, or preconditions are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It adds useful hints ('local markdown CRM', 'appending to its log'), but says nothing about what an update overwrites, whether fields merge or replace, permission/data-safety needs, or what is returned. For a mutation tool with zero annotation coverage this leaves significant 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?

A single compact sentence with the action and target front-loaded and no filler. It is efficient, though extremely terse given the tool's complexity.

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

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

With a mutation tool, 5 undocumented parameters, no annotations, and no output schema, the description should carry much more. What exists covers storage location and log-append behavior but omits field semantics, update/merge behavior, and result expectations.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate but does not. It never explains name, stage (with its six-value enum), company, nextStep, or note, leaving the agent to guess at each field's meaning and the semantics of merging on update.

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?

States a clear verb ('Add or update') and resource ('customer/investor in the local markdown CRM') with a specifically named storage mechanism and an append-to-log side effect. It does not distinguish itself from the closely related sibling investor_update, so it falls short of a 5.

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

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

The word 'upsert' is only implied by 'Add or update', with no statement of when to prefer this over investor_update or pipeline_list, no prerequisites, and no when-not conditions. The agent must infer routing from the sibling names alone.

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 behavior. It states the output is markdown with top goals and Friday review, but does not say whether it overwrites an existing plan, where it is stored, whether it requires auth, or what it returns; for a creation/mutation tool that is a meaningful 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?

Single front-loaded sentence with no filler; the parenthetical efficiently names the plan components and output format. It is concise and well-structured for a short tool description.

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 zero annotation coverage, no output schema, and no schema descriptions for three parameters, the description is not complete enough: it omits storage/overwrite behavior, week/focus semantics, and output/return details. It conveys the core artifact but not enough for reliable invocation.

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

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

Schema description coverage is 0%, so the description must explain all 3 parameters. It indirectly references goals ('top goals') but never explains week format, focus meaning, or the goals array constraints (1-5 items), leaving most parameter semantics undocumented.

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?

Names a specific verb ('Create') and resource ('this week's plan'), and states the expected artifacts ('top goals + Friday review') and format ('as markdown'). It is clear enough to separate from pipeline/investor/launch siblings by resource, though it does not explicitly contrast them.

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 no when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives among the sibling planning tools. At best the phrase 'this week's plan' implies a weekly planning context, but selection is left to inference.

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