Check whether a citation ID exists in a CSL-YAML bibliography file before citing it. Avoid broken citations by verifying IDs quickly.
Check if a citation ID exists in the bibliography. Fast boolean check before citing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The citation ID to check | |
| file | Yes | Absolute path to the CSL-YAML bibliography file (required). Look for "bibliography:" in pandoc.yaml or the YAML frontmatter of .md files. |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It does disclose that this is a boolean check and that it is fast, implying a read-only, lightweight operation. However, it does not describe error behavior, such as what happens if the file is missing or malformed, nor does it clarify how existence is determined.
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 extremely concise: two short sentences with no filler. The core purpose is front-loaded, and the behavioral hint ('Fast boolean check') is placed immediately after, making it easy for an agent to parse quickly.
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 simple existence-check tool with two required parameters, the description is mostly complete: it states the purpose, the return nature (boolean), and the workflow context. It does not need an output schema because the return type is implied, though it could have mentioned alternatives or error handling to be fully self-sufficient.
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 both parameters are already documented in the schema, including the file parameter's meaning and lookup guidance. The description adds only the phrase 'citation ID' to reinforce what the id parameter references, but does not significantly go beyond the schema.
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 action ('Check if a citation ID exists in the bibliography') and the resource ('the bibliography'), with an added hint about it being a 'Fast boolean check'. This distinguishes it from operations like adding, updating, or deleting, though it does not explicitly name a sibling alternative such as bib:get or bib:search.
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 phrase 'before citing' gives a clear workflow context for when this tool should be used. It does not explicitly discuss when not to use it or name alternatives, but the intended use case is evident and not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.