catalog_checkVerify every file in an area is listed in its catalog and append missing entries to keep records complete.
Is every file of an area in its catalog? add_missing appends rows to describe.
| Name | Required | Description | Default |
|---|---|---|---|
| prefill | No | ||
| add_missing | No | ||
| catalog_file | Yes |
Changes observed during successful MCP inspections.
v0.1.1Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "additionalProperties": true,
- "title": "Result",
- "type": "object"
- }
- },
- "required": [
- "result"
- ],
- "title": "catalog_checkOutput",
- "type": "object"
-}New value: +nullv0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds useful context that add_missing appends rows, but it does not explain what prefill does, whether the append is reversible, or what the check returns.
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?
Only two short sentences, so it is not verbose, but the question phrasing and undefined 'area' and 'describe' terms make it cryptic rather than efficient. Every sentence earns its place, yet clarity is sacrificed for 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?
With no output schema and no annotation coverage of return values, the description should clarify what the check produces, what catalog_file should point to, and what happens when files are missing. It leaves all of these open for a tool that can both report and mutate.
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% across three parameters, so the description must compensate. It only explains add_missing; the required catalog_file parameter and the prefill parameter (default true) are left entirely undocumented, which is insufficient for a tool with a required file input.
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 question form ('Is every file of an area in its catalog?') conveys a verification purpose against a catalog, and 'add_missing appends rows' hints at an optional mutation. However, 'area' is never defined, the required catalog_file parameter is not mentioned, and the distinction from sibling catalog_describe is left implicit.
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 guidance on when to call this versus catalog_describe, verify, inventory, or storage_check. The only usage-adjacent statement is that add_missing appends rows, which hints at a mutating mode but does not say when that mode is appropriate or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.