Owner or office: approve or reject stopped time entries (up to 200 at once, one shop). Office staff cannot decide their own time; only the owner can. Approved time is locked and counts for payroll and job costing; rejected time goes back to the worker to fix (any fix puts it back to waiting). A note is kept with the decision.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| decision | Yes | ||
| time_entry_ids | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses the consequences of each decision (approved time is locked and counts for payroll/job costing; rejected time returns to the worker and any fix resets it to waiting), the batch/single-shop constraint, and the permission restrictions. It omits idempotency and error behavior, but the side-effect disclosure is strong.
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, front-loaded with the actor and action, then permissions, then side effects. Dense but every sentence earns its place with 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?
A mutation tool with no annotations but an output schema, so return values need not be described. The description covers permissions, side effects, batch limits, and the note—enough for an agent to invoke it safely. Minor gap around error/idempotency behavior 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 coverage is 0%, so the description must compensate, and it does for all three params: 'approve or reject' maps decision, 'up to 200 at once, one shop' explains the batch limit and single-shop scope of time_entry_ids, and 'a note is kept with the decision' gives note a purpose. It lacks explicit format guidance (uuid, maxLength) but adds real meaning beyond the enum and array 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?
States a specific verb pair (approve or reject) and a precise resource (stopped time entries), plus scope (up to 200 at once, one shop). This clearly distinguishes it from adjacent timesheets tools like reopen or void, which handle different lifecycle states.
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 states who may act ('Owner or office') and the key restriction ('Office staff cannot decide their own time; only the owner can'). It doesn't name a specific alternative tool, but the who/when constraints are clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.