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

With no annotations provided, the description carries the burden of explaining behavior. It communicates that this is a mutating, add-only action and warns about target accuracy through the project parameter instruction. But it does not disclose edge-case behavior such as what happens when both project and task_id are supplied, whether notes overwrite, or what the response is.

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 filler: the primary action and target are front-loaded, followed by clear proactive usage guidance and a concrete parameter instruction. 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 moderately simple append-note tool, the description provides enough contextual framing to invoke it correctly: what to add, when to use it, and how to target the right project. The absence of an output schema and the one-required-parameter shape reduce the burden on the description. Minor ambiguity around project vs. task precedence keeps it from a 5.

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

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

Schema description coverage is 100%, so the schema already fully documents all five parameters. The description reinforces the project parameter's importance but adds little semantic value beyond what the schema property descriptions already convey. 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 action ('Add a note') and the target resource ('to a project or task'). It distinguishes itself from retrieval tools by explicitly naming note-creation content types like architecture, bugs, ideas, and research findings. Though log_decision is a sibling, the note-taking purpose is clear and well-scoped.

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

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

Provides explicit when-to-use guidance: proactively when the user shares important context worth remembering. It also gives a practical requirement: always specify the project parameter when known. It does not, however, state when not to use it or point to alternatives like search_notes or log_decision, so it misses the 'when-not/alternatives' bar for a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a new project to track,' which restates the title and gives no details about duplicate-name handling, required permissions, side effects, or response behavior. This is a notable gap for a creation 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 short sentences, front-loaded with the purpose and followed by usage triggers. Every word earns its place and there is no redundant phrasing.

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

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

The tool is a simple create with only one required parameter, the schema covers all optional fields, and there is no output schema requiring explanation. The main missing context is a pointer to update/repo-path tools for existing projects, but the trigger sentence ('doesn't exist yet') partially covers when not 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 description coverage is 100%, so the parameters (name, repo_path, tech_stack, description) are fully documented in the schema. The description adds no parameter-specific meaning beyond the schema, so the baseline 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 uses a specific verb ('Create') with a clear resource ('a new project to track'), and the usage context ('when starting a new project') clarifies scope. It does not explicitly name sibling tools or contrast with create_task/list_projects, so it misses the full 5.

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

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

The description explicitly states when to use it: 'when starting a new project or when a user mentions a project that doesn't exist yet.' This gives positive triggers and an implicit negative case (existing projects are not for this tool), but it doesn't mention alternatives such as set_project_repo_path for adding metadata to an existing project.

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?

There are no annotations, so the description carries the full behavioral burden. It states that the tool creates a task, but it does not disclose side effects such as whether the task is immediately persisted, how project defaulting is resolved, or what the call returns. This leaves the agent with limited transparency beyond the basic write 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 two short sentences with no filler. The first sentence states the core action, and the second sentence provides actionable usage guidance, making it well-structured and front-loaded.

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

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

With six parameters and no output schema, the description is adequate but incomplete. The schema covers all parameter semantics and the description gives usage context, but there is no mention of the return value or post-creation behavior, which an agent would need to confidently handle the tool's result.

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

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

Schema description coverage is 100%, and each parameter already has a clear description, so the baseline is 3. The description text itself adds little parameter-level detail beyond mentioning 'in a project,' which aligns with the project 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 opens with 'Create a new task in a project,' which is a specific verb and resource phrasing. This clearly identifies the tool's purpose and distinguishes it from siblings like update_task, get_task, and list_tasks.

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

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

The description explicitly says to 'Proactively use this when the user mentions something that needs to be done, a bug to fix, or a feature to build,' giving clear trigger conditions. It does not explicitly mention when not to use it or point to an alternative like update_task, but the context is strong enough for most cases.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies that the operation ends a session, but it does not disclose side effects, whether an active session is required, whether the action is reversible, or what happens to session data afterward. For a state-changing tool, this 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?

Two short sentences with no filler. The core action and the invocation trigger are both front-loaded and every clause contributes useful information.

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

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

The tool is moderately complex with five parameters, a required summary, and no output schema or annotations. The description plus fully-covered schema give an agent enough to invoke the tool, but important behavioral context—such as prerequisites around an active session and consequences of ending it—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 description coverage is 100%, so the schema already documents all five parameters and their meanings. The description reinforces that 'summary' captures what was accomplished and implies 'next_steps' relates to what to do next, adding slight context, but it does not need to compensate for missing schema info.

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

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

The description states a specific verb 'End' with a specific resource, 'a work session', and the key content of the operation: summarizing what was accomplished and what to do next. This clearly differentiates the tool from siblings like start_session and get_session_brief.

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

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

The description explicitly says 'Call this when the user is done working,' which provides a clear trigger condition for use. It does not name alternatives or explicitly state when not to use it, but the usage context is unambiguous given the sibling set.

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

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

With no annotations, the description carries the burden of behavior disclosure. It communicates that the tool returns static recommended instructions, hints at idempotence with 'Call this once', and explains that the output is suitable to paste into other LLM clients. It could be more explicit about being side-effect-free, but the read-only nature is strongly implied.

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

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

The description is a single focused sentence without filler. It front-loads the core return value and then immediately adds actionable usage context, earning every word.

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

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

For a zero-parameter tool with no output schema and no annotations, the description provides everything needed: what the tool returns, when to call it, and how to use the result. Nothing essential 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?

The tool has zero parameters, so there is nothing to document. A score of 4 reflects the baseline for parameterless tools, since no semantic burden falls on 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 states a specific action and resource: 'Returns the recommended instructions for using mindpm effectively.' This clearly distinguishes it from all sibling tools, none of which serve as a meta-instruction provider.

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

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

The description explicitly tells an agent when to invoke the tool ('Call this once if you are unsure how to use mindpm') and when to share output with a user. No alternative tool is needed, so the absence of when-not guidance is not a 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 carries the behavioral disclosure burden. 'List' conveys a read-only operation and 'all' communicates broad scope, while 'with what's blocking them' adds output detail. However, it does not disclose behavior when the optional project parameter is omitted, nor any ordering, pagination, or access considerations.

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 compact sentence with no filler. It front-loads the action and resource while including the most important output detail in a well-structured way.

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

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

For a simple list tool with one optional parameter and no output schema, the description adequately covers the purpose and the main return content. The only notable gap is that it does not explain whether omitting 'project' means all projects or the current context, but this is minor given the tool's low complexity.

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

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

The input schema already fully describes the only parameter, 'project', as 'Project name or ID', giving 100% schema description coverage. The description adds no parameter-level meaning or default behavior, so the baseline score of 3 is appropriate.

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

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

The description names a specific action ('List'), a precise resource ('blocked tasks'), and an additional output detail ('with what's blocking them'). This clearly distinguishes it from generic task-listing siblings such as list_tasks.

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

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

Usage is only implied: an agent would infer to use this tool when it needs blocked tasks and their blockers. No explicit guidance is given about when to prefer alternatives like list_tasks or get_task, and no exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool either fetches a single key or lists all context, but it does not clarify return format, whether the project parameter is required, or what happens when both parameters are omitted. The verb 'get' implies read-only, but the description adds little 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, front-loaded sentence with no filler. Every phrase contributes to understanding the core behavior and the primary branching condition.

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

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

The tool has optional parameters and no output schema, yet the description does not explain whether 'project' is needed for key retrieval, what happens if both fields are omitted, or what the returned context structure looks like. This leaves ambiguity for an agent deciding how to invoke 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%, so the schema already documents both 'key' and 'project'. The description adds the high-level relationship between key and listing all context, but does not provide additional parameter meaning beyond what the schema already offers.

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

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

The description states a clear verb ('Get') and resource ('context'), and expresses the two modes: retrieve by key or list all for a project. It is distinct enough from siblings like set_context, though it does not explicitly contrast itself with query or search.

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 when to use the tool (when you need context by key or all context for a project) but gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as query, search, or get_project_summary.

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 of behavioral disclosure. It names the metrics and frames them as DORA-inspired, which tells the agent what kind of output to expect. However, it does not state whether the operation is strictly read-only, how metrics are calculated, or whether the output is a snapshot versus a trend series.

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 compact sentences with no filler. The metric list is front-loaded, and the second sentence provides a clear usage purpose. 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?

For a two-parameter tool with no output schema, the description lists the returned metric concepts, which is helpful. It is not fully complete because it leaves ambiguity about whether the result is a single snapshot or a historical trend, and it does not define 'performance tier' or 'flow efficiency' beyond the label.

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

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

The schema already documents both parameters with 100% coverage, so the description does not need to add much. It only vaguely echoes the 'project' parameter without adding meaning beyond the schema, such as how days affects the computed metrics. 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 identifies a specific resource: delivery metrics for a project, and enumerates the exact metrics (throughput, lead time, flow efficiency, performance tier). It does not, however, explicitly differentiate itself from related siblings like get_project_status or get_project_summary, 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 phrase 'Use to understand delivery health and trends' gives a clear context for when to invoke this tool. It does not mention alternatives or exclusion cases, but the stated purpose is explicit enough to guide selection among 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?

With no annotations, the description carries the behavioral burden. It does disclose two key behaviors: filtering out blocked tasks and returning only highest-priority tasks. But it does not explain how priority is determined, what happens when project is omitted, or what the result shape 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?

The description is one concise sentence plus a short guiding question, with the key result front-loaded. 'Smart query' is mild filler, but it does not detract meaningfully from clarity or length.

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-only list tool, the description is mostly adequate: it states what is returned and at a high level how results are filtered. But with no output schema, it does not say what task fields are returned, and the optional project behavior is ambiguous despite 0 required 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 100%, so the baseline is 3. The description adds only the project-scoping concept and the notion of priority, but provides no additional semantics beyond the schema for limit or project.

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 names a specific verb ('Returns'), a specific resource ('tasks'), and a precise scope ('highest priority non-blocked tasks for a project'). This clearly distinguishes the tool from siblings like list_tasks, get_task, and get_blockers even without explicit sibling names.

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 phrase 'what should be worked on next?' gives a strong contextual cue for prioritization/planning use. However, it does not explicitly state when not to use the tool or name alternatives, so usage guidance is implied rather than fully spelled out.

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 behavioral disclosure burden. The verb 'Get' and the term 'overview' imply a read-only operation, and the listed components clarify what kind of data will be surfaced. However, it does not state side effects, permission needs, performance costs, or how the data is aggregated.

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-loads the core purpose, and wastes no words. The additional 'Great for getting up to speed' is a brief, useful usage signal rather than filler.

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

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

Given the tool's low complexity (one required parameter) and no output schema, the description adequately communicates what the response will cover. It enumerates the major output areas, though it does not specify the response format or note any limitations such as recency windows or filtering behavior.

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

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

Schema coverage is 100% and the single 'project' parameter already has a description: 'Project name or ID'. The tool description adds no additional meaning or constraints about the parameter, so the 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 a specific verb and resource: 'Get a full overview of a project' and enumerates the components (active tasks, recent decisions, blockers, last session summary). However, it does not explicitly differentiate this from closely named siblings like get_project_summary or get_blockers, so it falls short of full clarity.

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

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

The phrase 'Great for getting up to speed' implies a use case, but the description gives no explicit guidance on when to prefer this tool over alternatives such as get_project_summary, list_tasks, list_decisions, or get_blockers. No exclusions or when-not-to-use conditions 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?

With no annotations, the description carries the behavioral burden. It discloses the kind of data returned and implies a read-only operation, but it does not explicitly confirm that no project state is modified, nor does it clarify whether the 'project' parameter can be omitted and resolved from 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 a single, front-loaded sentence that states the tool's purpose and lists its output sections without any filler. Every part contributes to the agent's understanding.

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 one-parameter read tool with no output schema, the description covers the return contents well. However, it omits usage guidance and does not explain optional-parameter behavior, so an agent may not know when to choose this over related 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?

Schema description coverage is 100% for the single 'project' parameter, so the schema already documents it adequately. The description adds no further parameter detail, which is acceptable given the high 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 states a clear action ('get') and resource ('project summary') and enumerates the summary contents: tasks by status, recent activity, open blockers, and upcoming priorities. It does not explicitly differentiate from the sibling get_project_status, but the listed contents make the broader scope evident.

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 no guidance on when to use this tool versus alternatives such as get_project_status, get_blockers, or query. There are no exclusions, prerequisites, or hints about which agent intent should route here.

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 behavioral disclosure burden. It explicitly declares the operation is read-only and clarifies that it does not open a session or mark one as started. It also lists the output categories. It does not cover authorization or edge-case behavior, but for a simple read tool these omissions are minor.

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 filler. It front-loads the most important fact ('Read-only'), then gives a concrete content list, and closes with a useful sibling distinction. Every clause earns its place.

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

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

Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is complete enough for an agent to invoke it correctly. It explains the safety profile, what the brief contains, and how it differs from start_session. Nothing essential for selection or calling 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 description coverage is 100%, and the only parameter, 'project', is already documented in the schema as 'Project name or ID'. The description does not add extra parameter-level meaning, so the 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 what the tool does: it returns a read-only summary of what changed since the last session ended, and enumerates the exact content categories (commits, branch/working-tree state, task changes, blockers, decisions, notes). It also distinguishes itself from start_session, leaving no ambiguity about scope.

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

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

The description gives explicit when-to-use context ('what changed since the last session ended') and an explicit alternative/exclusion: 'Unlike start_session, this does not open a session or mark one as started.' This tells the agent both when to pick this tool and why it is not a session-opening action.

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 behavioral disclosure burden. It conveys that the operation is a read that returns full task details, subtasks, and related notes, which is useful context, but it does not describe the response structure, potential absence of results, or any safety considerations.

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 front-loads the core action and then adds the most relevant scoping details. There is no filler, repetition, or unnecessary qualification.

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

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

The tool is simple with one parameter, but there is no output schema and no explicit description of the return format beyond 'full detail' and the mentioned sub-tasks/notes. The description is adequate for a basic retrieval action, but an agent would still lack clear expectations about the exact response fields or error behavior.

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

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

The input schema has one required parameter, task_id, and its description is clear, so schema coverage is 100%. The tool description adds no extra meaning about how task_id should be interpreted, but the schema already covers the necessary semantics, making the baseline of 3 appropriate.

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

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

The description uses a specific verb and resource: 'Get full detail for a specific task,' and explicitly scopes the response to include 'sub-tasks and related notes.' This distinguishes it from sibling tools like list_tasks and get_next_tasks, which are broader list-type 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?

The description gives no guidance on when to use this tool versus alternatives such as list_tasks or get_next_tasks. There is no stated context, prerequisite, or exclusion, so the appropriate usage must be inferred from the name and generic wording.

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 conveys the core behavior: enumerating decisions and optionally filtering by tags. With no annotations, it does not add detail about pagination, ordering, project-required semantics, or response shape, though 'list' implies a read-only 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 short sentences front-load the main operation and add a useful filtering tip. There is no filler or redundant wording.

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

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

For a simple read-only list tool, the description is minimally adequate and the schema covers all parameters. However, key operational details are missing: whether project is required, how multiple tags work, and what the returned decision objects contain, especially since there is no output schema.

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

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

Schema coverage is 100%, with each parameter already described. The description adds a general mention of tag filtering but does not clarify parameter relationships, multi-tag syntax, or behavior when project or limit are omitted.

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

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

The description clearly identifies the action ('List decisions'), the resource ('decisions'), and the scoping context ('for a project'). It is unambiguous next to sibling list_projects and list_tasks, though it does not explicitly contrast with log_decision or search 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?

There is no guidance about when to prefer this tool over alternatives such as query, search_notes, or get_project_summary. The only implication is 'when you need decisions,' with no exclusions or alternative-based routing.

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. 'List all tracked projects' clearly conveys a read-only enumeration, and the status filter is transparent. It does not mention default behavior when status is omitted, ordering, pagination, or return shape, but there are no hidden side effects to disclose.

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 short sentences with no filler. The core action is front-loaded, and the optional filter is stated immediately after, making it easy to scan and parse.

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

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

For a simple one-optional-parameter list operation with no output schema, the description provides the essential behavior and filter options. It does not specify return fields or what happens when no status is supplied, but the tool name and action make the general return type obvious.

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

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

The schema already provides 100% coverage for the single optional 'status' parameter, including a description and enum values. The tool description repeats those same enum values ('active, paused, completed, or archived') without adding new semantic meaning or usage nuance.

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

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

The description states a specific verb ('List') and resource ('all tracked projects'), making the tool's purpose immediately clear. It is distinguishable from siblings like create_project, list_tasks, and get_project_status by the noun 'projects', though it does not explicitly name any alternative.

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 when to use it: when you need a list of projects, optionally filtered by status. However, it provides no explicit guidance about when not to use it or how it compares to related tools like get_project_status or get_project_summary.

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 and does reveal a meaningful behavioral default: non-completed tasks for the most recent active project. Still, it doesn't disclose ordering, how 'active project' is resolved, error behavior, or explicitly confirm the read-only nature beyond the verb 'List.'

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 short sentences with the action front-loaded and only one additional behavioral clause. It contains no filler and does not redundantly repeat the schema's per-parameter descriptions.

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 7-parameter listing tool with no output schema and no annotations, the description supplies the key behavioral default while the schema handles filter semantics. It is adequate for selecting and invoking the tool, though it omits details such as sort order and response shape.

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%, giving the baseline of 3, but the description adds value by explaining the implicit default for project/status that the schema does not encode. That extra context helps an agent understand what happens when project or status filters are omitted.

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

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

The description states a clear verb ('List') and resource ('tasks') and adds a useful default scoping detail. It distinguishes the tool from single-task get_task or mutation tools like create_task, but it doesn't explicitly differentiate it from potentially overlapping siblings like get_next_tasks or search.

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 second sentence gives concrete context: 'Defaults to showing non-completed tasks for the most recent active project.' This tells an agent what to expect when no filters are supplied and hints at when to use it. However, it offers no explicit when-not-to-use guidance or pointers to alternative filter/search 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 exist, so the description carries the full behavioral burden. It only says 'Record' and gives triggers; it does not disclose persistence, whether the entry can be overwritten, or what response the agent should expect. This is a meaningful gap for a write 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 no wasted words: first defines the action and objects, second gives a proactive trigger. Front-loaded and easy to scan.

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 schema fully documents all parameters and the description covers the trigger scenarios. There is no output schema, so return values need not be explained; the main missing piece is persistence or response behavior, which keeps this from a 5.

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

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

All 7 parameters have schema descriptions, so schema coverage is 100%. The description mentions reasoning and alternatives but adds no detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb ('Record') and resource ('a decision') and names the content it captures (reasoning, alternatives). It clearly distinguishes from siblings like list_decisions, which reads decisions, by focusing on creating a log entry.

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 to use proactively when the user makes a technical decision, chooses between options, or settles a debate. It gives a clear trigger but does not mention when not to use it or compare it with alternatives such as add_note.

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 burden of behavioral disclosure. It usefully states that the tool is read-only and only allows SELECT statements, which is an important safety behavior. However, it provides no additional context about result format, error behavior, resource limits, or permission requirements.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then adds the critical restriction and usage guidance. 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 one-parameter tool, the description is largely complete: it explains what it does, the only allowed operation, and when to use it. The lack of an output schema is mitigated by the obvious nature of a SELECT query result, though explicit mention of return format would make it fully complete.

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

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

Schema description coverage is 100%, so the SQL parameter is already well-documented. The description reinforces the 'SELECT' restriction but does not add significant new meaning beyond what the schema already provides. A 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 a specific verb ('Execute'), resource ('database'), and the exact nature of the operation ('read-only SQL query', 'Only SELECT'). It also distinguishes itself from sibling tools by noting it is for custom queries not covered by other tools, which is a strong differentiation.

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

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

The description gives clear usage context: use this for custom queries not covered by other tools. It states the read-only constraint, but does not explicitly list when not to use it or name specific alternative tools, though the 'not covered by other tools' phrase implies this.

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 behavioral disclosure burden. It discloses that the tool performs full-text search using FTS5, ranks results by relevance, and covers tasks, notes, and decisions. It does not mention auth, rate limits, or return packaging, but these are relatively minor for a read-only search 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 deliberately worded sentence that front-loads the core behavior, then the scope, then the ranking mechanism. There is no filler or redundant restatement of the tool name.

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 operation and scope, and the schema covers all parameters. However, there is no output schema and the description does not describe the shape of results or what happens when no project is specified, leaving some ambiguity for an agent invoking 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 description coverage is 100%, so each parameter is already documented in the schema. The description adds the project context and search scope, but it does not need to repeat schema-level parameter details, yielding the baseline score of 3.

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

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

The description states a specific verb ('search') and a precise resource scope: full-text search across tasks, notes, and decisions. It also adds meaningful distinguishing detail via 'FTS5, ranked by relevance' and the title 'Search Everything', separating it from sibling tools like search_notes.

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

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

The description clearly conveys that this is the broad cross-category search tool rather than a notes-only search. It does not explicitly name alternatives or provide when-not-to-use conditions, so it stops short of full routing guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action; it does not explicitly say the operation is read-only, describe what is returned, or mention result ordering or limitations. 'Search' implicitly suggests a read operation, but the lack of return-value information 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?

The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning, making it very easy for an agent to parse quickly.

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

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

For a simple tool with full schema coverage and only three flat parameters, the description is nearly sufficient. However, with no output schema and no guidance distinguishing it from the generic 'search' and 'query' siblings, the description leaves gaps around return values and the precise scope of 'for a project.'

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

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

The schema already documents all three parameters (100% coverage), so the baseline is 3. The description adds value by clarifying that 'query' performs full-text matching and that the 'project' parameter scopes the search across that project's notes, going beyond the minimal 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 identifies a specific action ('Full-text search') and resource ('notes'), and scopes it to 'a project.' This clearly conveys what the tool does and is enough to recognize it as the notes-specific search tool among siblings like 'search' and 'query', though it does not explicitly name or contrast those alternatives.

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 no guidance on when to use this tool versus alternatives. Given siblings include a generic 'search' and 'query', an agent is left to infer that search_notes should be used specifically for searching notes rather than broader content.

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 burden of behavioral disclosure. 'Upsert' explicitly communicates create-or-overwrite behavior, and the project scoping is stated. It doesn't cover persistence, visibility, or failure modes, but the core mutation behavior is transparent.

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

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

Two sentences with no filler: the first front-loads the action, resource, and upsert behavior; the second provides the proactive trigger. 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 relatively simple setter tool whose parameters are fully documented in the schema, the description gives purpose, usage trigger, and upsert semantics. It could additionally clarify optional-project behavior or point to get_context, but the agent has enough to call it 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%, so the schema already documents key, value, project, and category. The description reinforces the meaning of key/value by listing context examples, but it adds no new parameter syntax, dependencies, or relationship details beyond the schema.

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

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

The description states a specific verb ('Set') plus a resource ('key-value context pair for a project') and adds the upsert semantic. This clearly distinguishes it from sibling read tools like get_context and from note/decision 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 gives explicit proactive when-to-use guidance with concrete examples such as architecture decisions, config values, conventions, and constraints. It does not mention alternative tools or when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It does state the write operation ('set or update') and a downstream effect (affects session brief content). However, it does not disclose whether an existing path is overwritten, whether the operation is reversible, what validation occurs beyond the .git requirement, or what the tool returns, leaving notable gaps for a mutation tool with zero annotation coverage.

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

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

Two concise sentences with no filler: the first states the action and target, the second explains why the tool matters. The most important information is front-loaded, and 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 two scalar parameters, full schema coverage, and no nested objects, the description provides the essential information: what the tool does, what its prerequisite is, and why it is needed. It could add details about overwrite behavior or response format, but nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100%, with both 'project' and 'repo_path' already described in the input schema. The description adds only the contextual relationship to git activity, not new parameter-level meaning, so the 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 uses a specific verb ('Set or update') and names a precise resource ('local git repository path for a project'), and it adds the downstream purpose (enabling git activity in the session brief). It is not a tautology and clearly distinguishes this tool from the listed siblings, none of which cover this action.

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

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

The description states the condition for using this tool: it is required when the session brief must include git activity such as commits, branch, and working-tree state. It does not explicitly name alternatives or say when not to use it, but the contextual cue is strong enough for an agent to route correctly.

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, and it does well by disclosing the return contents ('full project overview including last session's next_steps, active tasks, blockers, and recent decisions') and the required kanban_url display behavior. It does not explicitly state whether starting a session has stateful side effects beyond 'Begin a work session,' but the main behavior is transparent enough.

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

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

The description is well-structured and front-loaded: purpose first, then return contents, then when/how to call it, then the important display instruction. Each sentence adds necessary guidance without fluff or repetition.

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

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

The description is complete enough for an agent to know when to invoke the tool, what to expect in the response, and one critical follow-up behavior (showing kanban_url). It does not detail edge cases like calling with no project parameter or how it relates to get_project_status, but the core context is present.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds practical context for the project parameter by explaining when to pass it explicitly, but it doesn't clarify the meaning of the `brief` parameter beyond what the schema already states.

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 and resource ('Begin a work session for a project') and clearly states what the tool returns. It distinguishes itself implicitly by describing the start-of-conversation role and the contents of the overview, though it doesn't explicitly name sibling tools like get_session_brief or get_project_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 gives clear invocation guidance: 'Call this at the start of every conversation' and explains multi-project handling with 'call once per project — after that, pass project explicitly on every tool call.' It does not explicitly mention when not to use it or name alternative tools, so it lacks full exclusion guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'update any field' and does not explain partial-update semantics, replacement behavior, error conditions, permissions, or whether an updated task is returned. The schema covers array replacement semantics, but the description itself adds little behavioral transparency beyond the obvious mutation.

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

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

The description is two sentences with no filler. The first sentence states the core function, and the second adds practical usage context. Every word earns its place.

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

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

The tool has 8 parameters, no annotations, and no output schema, so the description must do more than it does. It tells the agent when to use the tool and the schema documents all inputs, but it does not explain what happens when only task_id is provided, whether updates are partial, or what the caller should expect in return. This is adequate for invocation but leaves meaningful 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 description coverage is 100%, so the schema already documents every parameter, including enum values and replace-vs-append behavior for arrays. The description adds no parameter-specific details beyond saying any field can be updated, which is general and already implied by having optional editable fields.

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 updates any field of a task, providing a specific verb and resource. It is distinct from siblings like create_task and get_task by the action itself, though it does not explicitly name sibling tools or differentiate them, which prevents a 5.

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

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

The description gives concrete usage guidance: use proactively when task status changes, priorities shift, or new information arrives. It does not mention when not to use this tool or name alternatives such as create_task, but the provided contexts are clear enough for appropriate invocation.

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