Search the workspace's tracker for open work items by terms or status, reading the system of record directly instead of mirroring its data.
Ask the workspace's tracker what is open. The tracker stays the system of record; this reads it rather than mirroring it.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | An absolute path in the workspace. | |
| limit | No | How many items. | |
| terms | No | A word to search for. | |
| statuses | No | A status to filter by. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose that the tracker remains the system of record and that this reads it rather than mirroring it – i.e. a non-mutating read that returns fresh source data. It says nothing about pagination, result limits, or what a result set looks like, so the disclosure is partial.
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 short sentences, front-loaded with the core action, with no filler. The second sentence is more architectural framing than operational detail, but it is brief and does not bloat the definition.
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 search tool with no annotations and no output schema, the description omits return-shape expectations, default limits, and how the optional filters behave. The agent is left to guess what a successful call yields.
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 cwd, limit, terms, and statuses are already documented structurally; the baseline is 3. The description adds no filtering semantics beyond the schema (e.g. how terms and statuses combine), so it does not exceed baseline.
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 says it asks the tracker 'what is open', which implies listing/finding open work items, but never uses a concrete verb like 'search' or names the resource as work items. It does not distinguish itself from siblings never4ga_work_get or never4ga_search, leaving the agent to infer the scope.
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 explicit statement of when to use this versus never4ga_work_get (single item) or never4ga_search (general search). The only guidance is the implicit notion that it returns open items, with no exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.