AICortex

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: what categories of state the briefing pulls in and its legacy/duplicate status relative to cortex_start. It does not mention cost or latency, which is the only notable omission.

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 short sentences, each carrying distinct information: what it returns, why the alias exists, and the migration path. Nothing is repeated from the schema or annotations.

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 an output schema, complete annotation coverage, and fully documented parameters, most structured needs are met, and the description supplies the one thing structured data cannot: the deprecation/migration story. A brief note on how the task parameter shapes results would make it fully self-contained, but the gap is 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?

Schema description coverage is 100%, and the schema already explains both task and project, including that an empty project lists known projects. The description says nothing further about the parameters, so the schema does all the semantic work — the baseline 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 states a specific action (a start-of-conversation briefing) and enumerates exactly what it returns: user identity, working preferences, project notes, tasks, and last session. It also names the sibling cortex_start as identical, so an agent can distinguish the two without opening either schema.

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 routing rules: use this only because existing project instructions say 'call bootstrap', while new setups should call cortex_start instead. Both the when-to-use and the alternative are stated, not implied.

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?

Annotations already declare read-only, idempotent, closed-world behavior, yet the description still adds real operational facts: a 4,000-character output cap with truncation flagged as 'shortened', and the explicit empty-state behavior for a project with no notes. It stops short of describing permissions or cost/latency, so it is strong but not exhaustive.

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 most important instruction ('Call this first') is front-loaded, and the rest is dense but information-bearing. Some phrasing is compressed to the point of awkwardness ('a project with no notes yet says so'), and the trailing example costs length, but nothing is truly wasted.

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 an output schema present, the description need not detail return structure, yet it sketches enough of the briefing's sections that the agent knows what to expect, and both optional parameters and the no-argument default path are covered. Remaining gaps (error behavior, what 'skills matched' means) are 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?

Schema coverage is 100%, so both parameters are already documented, but the description adds meaning the schema does not: what each argument changes about the returned payload (project yields notes/tasks/last session; task yields skills and integrations) and a worked example call. The added value is real though partly overlapping with existing parameter 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?

States a concrete action (return a briefing) and enumerates the content by mode: profile/working preferences, plus project notes, open tasks and last session for `project`, and matching skills and integrations for `task`. It explicitly contrasts itself with bootstrap, memory_search and task_list, so an agent can place it among siblings without opening schemas.

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?

Gives an unambiguous trigger ('Call this first in every conversation'), explains the no-argument case, and routes later needs elsewhere ('use memory_search for a fact and task_list for the task board'). It even resolves the overlap with the bootstrap sibling by naming it as the equivalent for older setups.

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?

Adds real context beyond the annotations: results and errors pass through unchanged, refused names point back to search, and permissions match a direct invocation — which importantly explains that destructiveHint is inherited from the target tool rather than universal. What's missing is any note on side effects like rate limits, retries, or whether arguments are validated against the target 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?

Front-loads the core verb and result-passthrough behavior, then adds refusal routing, then the safety caveat, then a single example. Every sentence carries a distinct fact and the example earns its place by demonstrating the two-field call shape.

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 passthrough dispatcher with no output schema, the one thing an agent needs is what comes back — the description answers that ('its own errors too', result returned unchanged). Combined with inherit-permissions disclosure and the call example, nothing essential is absent.

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 goes further with a worked example showing name paired with an arguments object, making the passthrough relationship concrete. It does not explain how per-tool parameter schemas are discovered or how to handle argument mismatches.

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 and resource ('run a tool found with integration_search and return its result unchanged') and implicitly contrasts with the sibling integration_search, which only discovers tools. An agent can tell execution apart from discovery without opening any schema.

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 routes the agent: names must come from integration_search, and an uncallable name is refused with a pointer back to integration_search. It also gives an operational rule for destructive targets ('confirm such steps as you would there'), so when-to-use and when-to-be-careful are both 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?

Beyond the readOnly/idempotent/openWorld annotations, it discloses result ordering ('matches best first'), the shape of each result ('each with its parameters (* = required)'), and the empty-result behavior ('no match says so'). That is meaningful behavioral context, though it says nothing about match quality thresholds or whether results are cached/stale.

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

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

Front-loaded with purpose, then alternatives, then the follow-up tool, then an example — a sensible information order with no filler sentences. The domain enumeration is long but earns its place by bounding scope; a slightly tighter list would make it a 5.

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 an output schema present and full schema coverage, the description only needs to explain routing and result semantics, and it does both plus the call-chain to integration_call. The only omission is any hint about result-count behavior or what to do when matches are poor, which is minor for a two-parameter search tool.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds a concrete worked example ('print a PDF on the office printer') that clarifies the query parameter is a natural-language task rather than a keyword. The limit parameter is left entirely to the schema, which is acceptable.

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 a specific verb+resource ('Find a tool beyond the core set') and enumerates the concrete domains covered (devices, services, files, mail, printing, SSH, webhooks, playbooks, agents). It explicitly separates itself from skill_search and memory_search, so an agent can route without inspecting any schema.

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 states the use case (discovering non-core tools), names two sibling alternatives with the conditions that select them ('For how-to instructions use skill_search, for stored facts memory_search'), and names the follow-up action ('Run one with integration_call'). When-to-use, when-not-to-use, and alternatives are all present.

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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's job is to add context, which it does: it discloses the return shape (content plus version) and the exact error text for an unknown name. It stops short of describing whether storage is per-scope or how a miss interacts with the default scope.

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 compact sentences with the primary action and return value front-loaded, followed by the prerequisite and the failure behavior. Every clause carries information; there is no 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?

For a simple two-parameter read tool with a full output schema and strong annotations, this is nearly complete: the lookup key, the return contents, and the error behavior are all covered. The only omission is any mention of the scope parameter's effect on which memory is found.

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 both parameters are already documented, including the 'before the —' parsing hint and the scope values. The description adds no meaning about the name or scope parameters beyond what the schema says, 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?

States a specific verb (read) and resource (a memory), plus what is returned (full content and version) and the key it is addressed by (name). It also names the sibling memory_search as the way to obtain that key, so an agent can distinguish it from the search tool without opening the schema.

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 routes the agent to memory_search first to obtain the name, which is a real when-to-use instruction rather than vague context. It also documents the failure path for an unknown name, but it gives no guidance on when to prefer this over other siblings or what the scope choice implies for retrieval.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: relevance ordering with a documented priority (title hits weigh most, then tags/project, then text) and the fact that results are truncated to name, title and a snippet. It does not mention result-count limits or pagination behavior.

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

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

Two compact sentences, zero filler, with the core search-and-rank behavior front-loaded and the sibling hand-off placed last where it is most actionable. Every clause conveys distinct 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?

With an output schema present and full schema coverage on six parameters, the description need only cover purpose, ranking and the read-follow-up, which it does. Minor gaps remain around scope semantics ('shared' vs 'users/<id>') and default result limits, though those are already documented in the schema.

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

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

Schema description coverage is 100%, so the schema already documents tag, type, limit, query, scope and project. The description only reinforces the query semantics ('words... any order') and loosely gestures at tag/project via the ranking note, adding little beyond the structured fields. Baseline 3 applies when the schema carries the parameter burden.

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 a specific verb and resource ('Find memories by words') and immediately defines the matching and ranking model (title > tags/project > text). It also explicitly separates this tool from its closest sibling by noting that 'memory_read gives the full text', so an agent can distinguish the two without opening either schema.

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 clear routing guidance by naming memory_read as the follow-up for full content, implying this tool is the discovery/search step. It stops short of stating explicit exclusions, such as when to prefer skill_search or integration_search, or when a filtered list versus a keyword search 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?

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description explains exactly why: writing the same title REPLACES the existing memory. It further discloses that untyped memories are REFUSED and that a dedup hint surfaces related titles to merge — behavior not derivable from the schema or annotations. Minor gap: it doesn't state whether replacement can be undone.

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?

Dense and front-loaded, with the required-type rule stated before the exclusions. Heavy capitalization and parenthetical asides make it slightly noisy, but nearly every clause carries actionable content rather than restating the 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?

For a nine-parameter mutation tool with an output schema and full annotation coverage, the description covers the remaining unknowns an agent needs: the type taxonomy, the refusal on missing type, the destructive title-overwrite, the dedup hint, and where secrets belong instead.

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 would be 3, but the description adds real meaning beyond it: it defines what each of the four type values is for (user/feedback/project/reference) and gives a usage rule for review on project memories. The title/overwrite interaction is also clarified in prose rather than left to the field 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?

Opens with a specific verb+resource ("Save a durable, TYPED memory") and immediately distinguishes itself from the read/search siblings by emphasizing typed durability and write-back. The four enumerated types make the tool's identity unmistakable.

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 when-to-use criteria (durable facts only, not session chatter, nothing already in code/git) and an explicit routing rule for the excluded case: secrets go to the vault via secret_set through integration_call. It also instructs the agent to read before rewriting the same title, pointing at memory_read.

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?

Annotations declare non-read-only, non-destructive, closed-world, but do not say what persistence semantics to expect; the description adds that it appends (rather than replaces), that a session id comes back, and that old sessions expire after SESSION_RETENTION_DAYS. It does not say whether appending to an existing session merges or overwrites a prior summary, which is the one behavioral detail left open.

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 short sentences, each carrying distinct information, with the core operation and its purpose front-loaded and the retention caveat last. No restatement of the name or title.

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?

An output schema exists and annotations carry the safety profile, so the description only needs the handover intent, the memory_write boundary and retention, all of which are present. What remains thin is session lifecycle detail, such as what happens when a session_id is reused or a title collides, but nothing needed to invoke it correctly 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 every parameter including model, title, project, status, summary, next_steps and session_id is already documented in the schema. The description's mention of resume-by-another-device and the returned session id adds framing but no new syntax or format detail beyond what the schema 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 gives a concrete verb and resource ('Append a checkpoint to a work session') plus the reason it exists ('so another LLM/device can resume it'). It also separates itself from the sibling memory_write in the same breath, so an agent can route without opening a schema.

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?

'For handing over work in progress; durable facts belong in memory_write' states both the intended use and the alternative with the condition that selects it. The routing decision between persistent memory and transient session checkpoints is explicit rather than implied.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds context the annotations cannot: unknown names and skills outside the allowed set produce a message rather than a hard failure, and the return is the entire SKILL.md (potentially large). It does not discuss size or truncation limits, which keeps it from a 5.

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 short clauses, front-loaded with the action and payload, followed by the prerequisite and the failure mode. No redundant restatement of the title or 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?

An output schema exists, so return shape needn't be described. For a one-parameter read tool, the definition covers the action, payload scope, prerequisite, and error behavior — everything an agent needs 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% and the schema already explains the ' — ' delimiter, so the baseline is 3. The description adds a constraint not encoded in the schema — that the name must fall within the caller's allowed set — which meaningfully informs how to choose the value.

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

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

The description uses a specific verb and resource ("Load a skill's full instructions (its whole SKILL.md) by name"), which tells the agent both the action and the scope of the payload. It also names the sibling tool skill_search as the source of the name, so an agent can distinguish it from skill_search and memory_search without opening any schema.

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 tells the agent the prerequisite step (find the name with skill_search) and notes what happens for an unknown or disallowed name. What's missing is an explicit statement of when to load versus when a search result alone suffices, but the implied usage is clear 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?

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds genuinely new behavior: result cap of 10, the ranking signals (name weighted most, then description, tags, text), and that no match is reported rather than returning an empty list silently.

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 compact sentences, front-loaded with the outcome and the result format, with the ranking rule parenthesized rather than buried. The parenthetical is dense but each clause carries real information; no 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?

With an output schema and full annotation coverage, the description only needs to cover purpose, ranking, and workflow placement — all present. The one omission is that it never mentions how the optional category filter narrows results, though the schema covers it 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?

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description earns an extra point by explaining how the query string is matched — name matches outrank description, tags, and full text — which is meaning the schema does not convey. It says nothing about the category filter's effect on results.

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 and resource ('Find skills for a task') and immediately specifies the return shape (up to 10 lines 'name — description', best first). It also implicitly distinguishes itself from the sibling skill_load, which fetches the chosen skill rather than discovering it.

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?

Gives explicit sequencing: 'Call this before specialized work, then skill_load the best match.' That names the alternative tool and the condition that selects it, so an agent knows both when to use this tool and what to do next.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered; the description adds behavior the annotations don't: ordering is "oldest first" and results are exhaustive ("every match"). It doesn't discuss result limits or volume, but with an output schema present and the exhaustiveness claim stated, the gap is 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?

Two sentences: the first defines the resource, ordering, and returned fields; the second routes the agent to the right next action. Nothing is repeated and the scoping information is front-loaded.

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

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

For a two-optional-parameter read tool with full schema coverage, annotations and an output schema, the description covers purpose, ordering, exhaustiveness and the follow-up workflow. Only edge details such as whether done tasks are included by default or any result-size ceiling are left implicit.

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%, with both owner and status fully documented including the empty-string default semantics, so the schema carries the burden and the baseline of 3 applies. The description hints at filtering only implicitly via "every match" and adds no syntax or enum detail beyond the schema (status enum lives in the schema text, not the parameter enum list).

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 and resource ("List the tasks on the shared agent board") and disambiguates what a task is ("work handed between agents"), plus the return fields (id, status, owner, title). The read-only list role is clearly distinct from the write siblings referenced later (task_add / task_claim via integration_call).

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

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

Explicitly prescribes when to call it ("Check it before adding or claiming one") and names the alternatives for the write path (task_add / task_claim reached through integration_call). An agent knows both the trigger condition and where to go instead for mutation.

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