List unresolved analysis items for a project, sorted by severity and paginated, so you can prioritize verification and track unverified findings.
미확인 목록 (심각도순, 페이징).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No | ||
| offset | No | ||
| status | No | ||
| severity | No | ||
| project_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only that results are severity-ordered and paged, giving no indication of read-only safety, how pagination behaves (defaults 50/0 in the schema), whether an empty result is meaningful, or what happens with filters. For a bare tool with zero annotation coverage this is a significant gap.
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?
A single short phrase with no filler and the two key behaviors (ordering, paging) front-loaded. It is efficient but so sparse that it reads as under-specification rather than disciplined brevity.
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?
Six parameters, a required project_id, four optional filters, no annotations, no output schema, and no sibling disambiguation – the description should do much more to be callable with confidence. It never says what an 'unknown' record contains or how results are shaped or truncated.
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, and it does not: the four filter parameters (domain, status, severity, and their semantics) go entirely unexplained, nor is the role of the required project_id stated. Only '페이징' hints at limit/offset, which is the bare minimum implied by the parameter names themselves.
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 phrase '미확인 목록' (unconfirmed list) with '심각도순, 페이징' (by severity, paged) does tell an agent this is a paged listing of unknown/unverified items ordered by severity. However, it never states what an 'unknown' is in this domain or how it relates to siblings like oss_unknown_record / oss_unknown_update, and the verb is implied rather than stated. Minimum-viable identification of the resource, not a differentiating definition.
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 when-to-use guidance at all: nothing tells the agent to call this instead of oss_unknown_record (to add one) or oss_unknown_update (to resolve one), and no prerequisites such as a required project_id are mentioned. The agent must infer the workflow from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.