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

With no annotations, the description carries the full behavioral burden. "Caps enforced" is a genuine hint that limits/truncation apply, but it is undefined — no cap values, no behavior on overflow, no statement of whether prior context is replaced or merged, no auth requirements, and no idempotency info for a 10-parameter 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?

At eight words it is front-loaded and wastes no filler, but this is under-specification masquerading as conciseness — the brevity strips information an agent needs for a complex 10-parameter write rather than trimming redundancy.

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

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

Ten parameters, two required, zero schema descriptions, no annotations, no output schema, and an eight-word description leave the agent without enough to call this correctly or understand its effects. The definition is far too thin for the tool's complexity.

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

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

Schema description coverage is 0% across 10 parameters, and the description adds no parameter meaning whatsoever — agent, changed, facts, tasks, decisions, questions, since, next, project, and evidence are all unexplained in both places. "Caps enforced" is the only tangential hint and is too vague to compensate for the coverage gap.

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

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

States a verb ("Save") and a loose resource ("compact results"), so an agent can infer this persists something before ending a session. However, "compact results" is jargon that doesn't map cleanly to the schema's facts/tasks/decisions/questions structures, and nothing distinguishes it from ctx_task or ctx_compile beyond the vague write implication.

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?

"Before finishing" gives a real timing trigger, implying this is the terminal/persist step of a session. But no alternatives are named and there is no when-not guidance, so the sibling relationship with ctx_get/ctx_search/ctx_task/ctx_compile is left entirely to inference.

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, and it discloses nothing. It does not state whether the operation is read-only, whether the budget parameter caps output, what side effects exist, or what permissions are needed.

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 single fragment is short but this is under-specification rather than effective conciseness. There is no front-loaded statement of action or outcome for the agent to anchor on.

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 four-parameter tool with no annotations, no output schema, and no parameter descriptions, the definition leaves the agent with nothing to determine behavior or required inputs beyond the schema's field names. It is fundamentally incomplete.

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

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

Schema description coverage is 0% across four parameters (role, task, budget, project), and the description explains none of them. The agent cannot learn what 'budget' constrains or how 'role' affects the compiled pack.

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 is a noun phrase ('Context pack for one task') rather than a verb+resource statement, so it does not say what the tool actually does (compile/build a context window). It gives no differentiation from siblings like ctx_get, ctx_search, or ctx_task.

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 when-to-use guidance, no exclusions, and no mention of alternatives. Nothing tells the agent when ctx_compile should be chosen over ctx_get, ctx_search, or ctx_task.

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 and no output schema, the description carries the full load, and it does disclose meaningful behavior: since returns deltas relative to a cursor and topic drills in. It says nothing about auth/permissions, result format, budget behavior, or whether the call is read-only, leaving real gaps for a context-fetch tool.

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

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

Three telegraphic fragments, front-loaded with the resource and the when-to-call guidance; nothing is redundant. It borders on under-specification rather than excess, so it is tight but not wasteful.

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 5-parameter tool with 0% schema coverage, no annotations, and no output schema, the description should explain role/budget/project and the return shape. It covers only since and topic, leaving the agent guessing on the majority of the surface.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and only partially does: it explains since (cursor for deltas) and topic (drill in) but says nothing about role (an enum with 6 values), budget, or project. Three of five parameters are undocumented in both the schema and 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?

"Shared project context" names the resource but supplies no verb, so the agent must infer that this is a read/retrieval call (the name ctx_get and "Call at start" hint at it). It does not differentiate this tool from siblings like ctx_search or ctx_compile, so it lands at minimum-viable rather than clear.

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 concrete timing guidance ("Call at start") and conditional behavior ("pass since=<last CURSOR> later for deltas"), which tells the agent exactly when and how to re-invoke. It stops short of naming alternatives (ctx_search, ctx_commit) or stating when *not* to use it, so it is clear context without exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says only 'Search shared memory.' It does not disclose read-only vs mutating behavior, whether the search is keyword/semantic/hybrid, result limits, permissions, or what a match looks like. This is a severe gap for a search tool with zero structured safety hints.

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 single sentence is short and front-loaded, but this is under-specification rather than conciseness. Nothing here would be cut for being redundant; instead, essential content is missing.

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?

A 3-param search tool with no annotations and no output schema demands a description that explains query semantics, scope, and result behavior. The description supplies none of that, so an agent cannot safely invoke it without inspecting sibling tools or guessing.

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

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

Schema description coverage is 0%, and the description does not mention any of the three parameters (q, k, project). An agent cannot learn that q is the query string, k bounds result count, or project scopes the search. With the schema doing none of the work and the description doing none either, parameter semantics are effectively absent.

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 verb (Search) and a resource (shared memory), so the basic intent is legible. However, it is generic and does not differentiate this tool from siblings like ctx_get, ctx_compile, or ctx_task, leaving the agent to guess the boundary. That is the definition of a vague-but-not-tautological purpose.

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

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

There is no guidance on when to use this tool versus ctx_get or any other sibling, no mention of prerequisites, and no exclusions. The description offers nothing beyond the name.

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

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about what claiming does (locking, exclusivity, conflicts), whether release undoes a claim, what recovery follows a failed complete, or any permission requirements. 'complete needs evidence' is the only real behavioral disclosure.

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

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

Extremely compact and front-loaded with the action verbs, so no sentence is wasted. However, at this level of compression for a 5-parameter mutating tool the terseness shades into under-specification.

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?

A concurrency-sensitive task-mutation tool with 5 params, zero schema descriptions, no annotations, and no output schema needs substantially more than 8 words. An agent cannot tell what a successful claim returns or how conflicts are surfaced.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate, and it only partially does. It implies the action enum values and flags evidence for complete, but says nothing about the required agent or task_id, nor about the optional 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?

Names three specific verbs (claim, release, complete) against one resource (a task), which is enough to distinguish it from read-oriented siblings like ctx_get/ctx_search. The pipe-delimited form and lack of any scope statement keep it from 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 only guidance is that 'complete' requires evidence, which is a precondition rather than a when-to-use statement. It never says when to claim vs. release, or how this relates to the mutation-flavored sibling ctx_commit.

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