WritersLogic research agents

citation-audit

Citation Audit — Bibliography in, evidence audit out: reference-verifier checks every reference (fabricated, mis-cited, retracted, corrected); the top DOI-bearing references (corrections first, then the most cited in the manuscript) get a replication-auditor pass on the sentence that cites them; when a target is contested, paper-contradictions compares it with the studies against it. The contradiction check is opt

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "citation-audit"
  }
}

Input Schema

Name	Required	Description
`topK`	No	References to audit for replication (default 2).
`claim`	No	The claim the bibliography supports; used for the replication and contradiction checks instead of the citing sentence.
`latex`	No	LaTeX source with a thebibliography environment (\bibitem) or embedded filecontents .bib; \cite commands supply citation contexts and are checked against the entries.
`bibtex`	No	BibTeX/BibLaTeX text (the contents of a .bib file).
`pdfUrl`	No	Public PDF URL. Text extraction is best-effort (Word and Google Docs exports work best).
`arxivId`	No	arXiv id or URL; references are read from the ar5iv HTML (.ltx_bibitem), falling back to the PDF.
`manuscript`	No	Optional manuscript text (LaTeX or plain) that supplies citation contexts: \cite keys, [n] numbers or Author (year) citations.
`references`	No	Plain-text reference list (numbered, blank-line separated, or one per line; APA, IEEE, Vancouver, Chicago).
`identifiers`	No	Bare identifiers instead of a bibliography: up to 150 DOIs (bare, doi: or doi.org URL), arXiv ids or URLs, or PMIDs (bare, PMID: or PubMed URL), mixed freely. Each is resolved and checked for retraction, correction and a published version of record.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load and does disclose real behavior: best-effort PDF text extraction, ar5iv HTML fallback for arXiv, ordering of audited references. However the final sentence is cut off mid-word, hiding exactly the kind of conditional behavior (contradiction check optionality) an agent needs, and there is nothing on latency, cost, or failure handling for a nine-input pipeline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the clauses are dense with useful detail rather than filler. But the whole thing is a single run-on construction that trails off truncated, so the most decision-relevant condition is the one that got cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-annotation, no-output-schema pipeline tool, the description covers input roles adequately and the schema covers the rest. The truncated final sentence leaves a genuine gap in the conditional logic, and nothing indicates what the audit returns or how large a run can be.

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 the schema already defines every input including formats, limits, and defaults. The description adds only pipeline-level context (which sources feed citation contexts, which feed identifiers) rather than parameter-level meaning, so the baseline 3 applies.

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?

"Bibliography in, evidence audit out" plus the named sub-checks (reference-verifier, replication-auditor, paper-contradictions) makes clear this is an orchestration tool that runs a multi-stage citation audit. It does not, however, distinguish itself from simply calling reference-verifier directly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the internal routing logic (every reference verified; top DOI-bearing ones get a replication pass, corrections first then most-cited) which implies when each stage fires. But it never tells the agent when to choose this tool over the standalone sibling tools, and the one clause that would set a usage condition — "The contradiction check is opt..." — is truncated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All WritersLogic research agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?