Retrieve local operation handoff status—pending approvals, inflight items, unprocessed notifications—with evidence and freshness constraints, without syncing or approving.
ローカル運用記録の状態・承認待ち・inflight・通知未処理を根拠と鮮度の制約付きで返す。同期・承認・再送はしない
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| project | No | ||
| since_last_read | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does disclose that the tool does not sync, approve, or resend, indicating a read-only operation. It also mentions 'freshness constraints,' suggesting data may not be real-time. However, it does not mention side effects, authentication requirements, error handling, or pagination, so it is only partially 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?
The description is a single, dense sentence that packs the core function and key limitations without any fluff. It is front-loaded with the main purpose and includes the critical 'does not' clause. Every word earns its place, making it highly concise and well-structured.
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 three parameters with no documentation, no output schema, and no annotations. The description only covers the general purpose and a few behavioral constraints. It leaves the agent without knowledge of parameter meanings, expected response format, or any prerequisites. For a tool with this complexity, the description is incomplete and leaves significant 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?
The schema has zero description coverage for its three parameters (account, project, since_last_read), and the description does not explain any of them. It only discusses the output and behavioral constraints. Since the description is the only source of parameter meaning and it provides none, agents cannot know what values to supply or how they affect 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?
The description clearly states the tool returns local operation record statuses (approval pending, inflight, notification unprocessed) with constraints of evidence and freshness. It also explicitly says it does not sync, approve, or resend, making its read-only nature unambiguous. This gives a specific verb and resource, and the negative clause helps distinguish it from any mutation 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?
The description offers no guidance on when to use this tool versus alternatives. It never mentions any sibling tool or scenario. The statement about not syncing/approving/resending implies a read-only use case but does not specify when an agent should call this function over others. There is no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.