Record an active agent work task with a time-limited scope lease to focus context-engine processing on relevant files and symbols.
Record explicit agent work plus a bounded advisory scope lease.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| task_id | No | ||
| agent_id | Yes | ||
| session_id | No | ||
| task_title | Yes | ||
| scope_paths | No | ||
| ttl_seconds | No | ||
| scope_symbols | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.62Does 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 hints at a 'bounded lease' and 'scope', which implies time-limited scoping, but it does not explain side effects, persistence, expiration behavior, idempotency, or what the returned claim/lease contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and it front-loads the primary action. However, it is too sparse for the parameter complexity and leaves important semantics entirely implicit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 0% schema coverage, no annotations, and a large sibling family, this description is not complete enough for an agent to invoke the tool confidently. The output schema is noted as present, but the description still omits lease semantics, expected inputs, and relationship to other work_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the 8 parameters. It only loosely maps 'scope lease' to scope_paths/scope_symbols/ttl_seconds, and does not clarify the meaning of agent_id versus session_id, the role of task_id/task_title, or how the lease is enforced or released.
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 ('Record explicit agent work') and a resource ('bounded advisory scope lease'), which distinguishes it from many sibling work_* tools at a high level. The phrase 'bounded advisory scope lease' is somewhat jargon-heavy but conveys that the tool registers work and a scoped, time-limited claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like work_handoff, work_resume, or work_record_context. The context of sibling tools suggests a work-tracking workflow, but the description provides no explicit when-to-use, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.