Skip to main content
Glama
Sign In
doc-tools-mcp

doc-tools-mcp

by metaneutrons
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

bib:exists

Check whether a citation ID exists in a CSL-YAML bibliography file before citing it. Avoid broken citations by verifying IDs quickly.

Instructions

Check if a citation ID exists in the bibliography. Fast boolean check before citing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file": "<file>",
      "id": "<id>"
    },
    "name": "bib:exists"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe citation ID to check
fileYesAbsolute path to the CSL-YAML bibliography file (required). Look for "bibliography:" in pandoc.yaml or the YAML frontmatter of .md files.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A3.8/5.0
Behavior3/5

Does 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools