Fetch a single PocketDraft catalog item by entity type and ID directly, avoiding browser delays.
Get one catalog item without waiting for browser work.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| entity | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v4.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so safety is covered. The description adds one behavioral trait beyond them — that the call avoids browser rendering latency — but leaves ambiguous whether the returned item could be stale or whether it errors when the item is absent.
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 sentence, front-loaded with the verb and resource, with no filler. It is arguably under-specified rather than verbose, but nothing in it is wasted.
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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. What is missing is the usage context an agent needs to pick this over its siblings and any note on error behavior when the id is unknown.
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 carries the burden of explaining the two required parameters and it explains neither. The 'entity' enum of seven catalog types and the 'id' string are left entirely to the raw schema, with no added meaning about valid id formats or entity semantics.
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 (Get) and resource (one catalog item), and the singular framing implicitly distinguishes it from the sibling pocketdraft_list_catalog. The trailing phrase 'without waiting for browser work' is cryptic but does not obscure what the tool fetches.
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 guidance on when to use this versus pocketdraft_list_catalog or pocketdraft_operation_status. The 'without waiting for browser work' clause hints at a fast/cached path but never states the condition that selects this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.