Aurelius is a fact-checked research MCP server that helps you conduct rigorous, citation-verified academic research through a structured workflow. It operates primarily in a host-driven mode where the connected application's LLM handles reasoning and writing, so no LLM API key is required for most operations.
Screen research topics: Evaluate whether a topic is acceptable under Aurelius's admission policy before drafting — returns a heuristic flag and the full policy for a final accept/reject decision.
Retrieve research policy: Fetch the full list of accepted vs. restricted research domains at any time.
Generate academic outlines: Scaffold a standard academic structure (Abstract → Introduction → ... → References) for any topic.
Search the web for evidence: Query live web sources via Tavily to find supporting evidence for factual claims, with options to limit results or filter to academic sources only (requires a Tavily API key).
Verify citations: Check whether a specific academic citation exists in reputable sources, catching hallucinated or misattributed references before they appear in a final draft (requires a Tavily API key).
Save research drafts: Persist a Markdown-formatted research draft to the output directory.
Save verification reports: Persist a fact-checking report with a status line (VERIFIED/REJECTED) and full details.
Run autonomous research loops: Execute the entire pipeline — screen → draft → fact-check → revise — automatically using Aurelius's own LLM, configurable by model, provider, and revision rounds (requires an OpenAI, Anthropic, or Google API key).
Integrates with Google Gemini CLI to provide fact-checked research capabilities, including topic screening, web search, citation verification, and report generation.
Integrates with ChatGPT (via remote deployment) to provide fact-checked research capabilities, including topic screening, web search, citation verification, and report generation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Aurelius Research the health effects of microplastics in drinking water and verify all citations."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A fact-checked research MCP server. Aurelius gives any MCP-capable app — Claude (Desktop / Code / claude.ai), Gemini CLI, Cursor, and (via a remote deployment) ChatGPT — a set of research tools that verify every citation against real scholarly databases (OpenAlex, Crossref — DOI-backed and retraction-aware) and every claim against live web sources before presenting it. No more hallucinated papers, no more silently-cited retracted studies.
Aurelius grew out of a multi-agent research framework and distills its best idea into a portable tool server: screen a topic → draft → fact-check → revise.
Writing the paper yourself, in LaTeX? Aurelius-IDE is the sibling project: a language server that runs these same retraction-aware checks inline in your editor, as you type, rather than through a chat client. It uses this package as its optional verification backend. Same checks, different surface.
By default Aurelius runs in host-driven mode: the app you connect it to (Claude, Gemini,
etc.) uses its own model to reason and write, and Aurelius just supplies the research and
fact-checking tools. That means Aurelius needs no LLM API key of its own — the tokens are
covered by your existing Claude/Gemini/ChatGPT subscription. Citation verification runs
against OpenAlex and Crossref — both
free, both keyless. The only optional key is Tavily, used for general
web_search and as a fallback when a citation isn't indexed in either scholarly database
(free tier available).
There's also an optional autonomous mode (autonomous_research / aurelius-research)
where Aurelius drives its own LLM — that one needs an LLM API key with quota.
Related MCP server: truth-anchor-agent
pip install aurelius-mcpThe bare name
aureliuswas already taken on PyPI, so the package ships asaurelius-mcp. The import name (import aurelius) and the CLI command (aurelius) are unchanged.
This provides two commands:
aurelius — launch the MCP server (stdio). This is what MCP clients run.
aurelius-research "<topic>" — run one autonomous research job from the terminal.
If
aureliusisn't found (the pip scripts dir may not be on your PATH — common on Windows), use the equivalent module form anywhere acommandis expected:"command": "python", "args": ["-m", "aurelius"].
Citation verification (verify_citation, verify_claims) needs no key — it runs against
the free, keyless OpenAlex and Crossref APIs. A Tavily key is only needed for web_search
(general factual-claim evidence) and as a fallback when a citation isn't indexed in either
scholarly database. Create a free key at https://tavily.com and expose it as
TAVILY_API_KEY (see the config snippets below, which inject it into the server's environment).
Edit claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"aurelius": {
"command": "aurelius",
"env": { "TAVILY_API_KEY": "tvly-your-key" }
}
}
}Restart Claude Desktop. See examples/claude_desktop_config.json.
claude mcp add aurelius --env TAVILY_API_KEY=tvly-your-key -- aureliusAdd to ~/.cursor/mcp.json (or the project .cursor/mcp.json):
{
"mcpServers": {
"aurelius": { "command": "aurelius", "env": { "TAVILY_API_KEY": "tvly-your-key" } }
}
}Add to ~/.gemini/settings.json:
{
"mcpServers": {
"aurelius": { "command": "aurelius", "env": { "TAVILY_API_KEY": "tvly-your-key" } }
}
}Then just ask: "Use Aurelius to research the historical correlation between GDP growth and unemployment, and verify every citation."
A real run on "the historical correlation between GDP growth and unemployment (Okun's law)":
Claude drafted the paper, then called verify_citation on every reference.
Citation | Verdict |
Okun, A. M. (1962). Potential GNP: Its Measurement and Significance. | ✅ Verified — corroborated by arXiv and Federal Reserve sources |
Knotek, E. S. II (2007). How Useful is Okun's Law? | ✅ Verified — Federal Reserve Bank of Kansas City |
A third citation with a misattributed author | ✏️ Caught and corrected before the draft was finalized |
Nothing unverifiable made it into the final draft. That's the whole point.
verify_citation doesn't just check that a paper exists — it checks OpenAlex's live
retraction registry. A real call against the (in)famous Wakefield MMR-autism paper:
verify_citation("Wakefield, A. J. et al. (1998). Ileal-lymphoid-nodular hyperplasia, "
"non-specific colitis, and pervasive developmental disorder in children."){
"verdict": "retracted",
"is_retracted": true,
"confidence": "high",
"source": "openalex",
"matched_work": {
"title": "RETRACTED: Ileal-lymphoid-nodular hyperplasia, non-specific colitis, ...",
"doi": "10.1016/s0140-6736(97)11096-0",
"year": 1998
},
"notes": "Retracted work — flagged by openalex. Do not cite."
}is_retracted is always a top-level field — impossible for a host model to miss or
rationalize past. A scholarly index can return several records for the same paper (the
original, a retraction notice, clean-looking duplicates); Aurelius specifically resolves
ties in favor of surfacing the retraction rather than picking whichever record looks cleanest.
A title match alone is not a verification. Aurelius corroborates the cited author and year against the matched record, so it catches the subtle case a title-only checker waves through:
verify_citation("Okun, A. M. (1962). Potential GNP: Its Measurement and Significance."){
"verdict": "unverified",
"author_match": false,
"match_score": 1.0,
"matched_work": { "authors": ["Charles I. Plosser", "G. William Schwert"], "year": 1979 },
"notes": "Found a work with this title but different authors (found: Plosser, Schwert; cited: Okun) — likely not the paper you cited."
}The title matches perfectly (1.00), but the only indexed record with that title is a 1979
paper by Plosser & Schwert — not Okun's 1962 original. A title-only checker reports ✓;
Aurelius reports the truth and hands back the corrected_citation for the record it actually
found. When a citation carries a DOI or arXiv id, it's looked up directly for an exact match.
Tool | What it does | Needs |
| Screen a topic against the restricted-domain policy | — |
| Return the accept/reject policy | — |
| Standard academic (Markdown) outline scaffold | — |
| Section-by-section word budget for long-form papers | — |
| Verify against OpenAlex/Crossref/arXiv/Semantic Scholar — DOI-precise, retraction- & author-aware; returns a corrected citation + BibTeX | — (Tavily optional, fallback only) |
| Batch-verify citations/claims into a scored Evidence Ledger | — (Tavily optional, fallback only) |
| Verify a whole References block; returns a scored ledger + cleaned BibTeX | — (Tavily optional, fallback only) |
| Verify a statistic ('GDP grew 2.5% in 2023') against World Bank data | — (Tavily optional, fallback only) |
| Search the global literature across languages (zh/es/de/ja…) via OpenAlex | — |
| Re-check verified citations for new retractions / verification drift | — |
| Recall lessons from past Aurelius research sessions (episodic memory) | — |
| Search the web for evidence about a factual claim | Tavily key |
| Style/readability pass on already-verified content | — (LLM key only if |
| Mermaid scaffold: flowchart / architecture / sequence | — |
| Compile-ready LaTeX article skeleton + BibTeX stub | — |
| Save (or append to) the Markdown draft | — |
| Save | — |
| Save the verification report | — |
| Run the whole linear loop itself | LLM key |
| Run the multi-stage agent DAG (orchestration layer) — audit-trailed, checkpointed | LLM key (verification stays keyless) |
Outputs are written to ~/aurelius_output/ in your home directory (override with
AURELIUS_OUTPUT_DIR) — never to the process's current working directory, since MCP
clients often launch the server from a location you can't write to.
Call plan_paper_length(target_pages=40) for a section-by-section word-count budget, then
draft and verify_claims one section at a time, appending each with
save_draft(content, filename, append=True) so the host model never has to resend the whole
accumulated document. See SKILL.md for the full workflow.
polish_proseIt's a readability pass on already-verified content — it fixes stiff, repetitive LLM phrasing (hedging chains, transition-word stacking, tricolon padding) while preserving every citation, number, and claim verbatim. It is explicitly not an AI-detector-evasion tool; pairing that with long-form academic paper generation would enable academic dishonesty, which is out of scope for a project whose entire premise is showing verifiable receipts.
skill/aurelius/SKILL.md teaches a host model the exact
screen → plan → draft → verify → polish → save workflow, including the long-form
(section-by-section) path. Drop it into your Claude Code/Agent skills so the model uses the
tools rigorously.
export OPENAI_API_KEY=sk-... # or ANTHROPIC_API_KEY / GOOGLE_API_KEY
export TAVILY_API_KEY=tvly-...
aurelius-research "Health effects of microplastics in drinking water" --model gpt-4o-mini-2024-07-18 --rounds 2Provider is auto-detected from the model name (gpt-* → OpenAI, claude-* → Anthropic,
gemini-* → Google).
--graph)Beyond the linear loop, Aurelius can run a staged research DAG driven by a swarm of
specialized agents (literature mining → a parallel hypothesis swarm → feasibility screening
→ experiment design/code → citation verification → adversarial review → drafting → LaTeX →
proof-of-rigor). Every agent action is logged to an audit trail and each stage is
checkpointed under ~/aurelius_output/sessions/, so a run is fully inspectable and resumable.
aurelius-research "Effect of sleep duration on reaction time" --graphOr call the autonomous_research_graph MCP tool from any client. It's built in-house — no
LangGraph/LangChain — reusing the same retraction-aware citation verification as the rest of
Aurelius.
Code sandbox & p-hacking audit (Phase 2). The DAG statically audits the generated analysis
code for questionable-research-practice signals (uncorrected multiple comparisons, missing
random seed, post-hoc outlier removal, optional stopping, HARKing, selective reporting) and
reports a risk score. Add --sandbox to also execute that code in a hardened, network-less
Docker container (CPU/mem/pids caps, read-only fs, dropped capabilities, non-root, timeout) —
opt-in because the code is model-written, and a graceful skip if Docker isn't present:
aurelius-research "your topic" --graph --sandboxCryptographic Proof-of-Rigor (Phase 3). Each run emits a signed, tamper-evident proof
bundle: a SHA-256 content hash of the evidence ledger + full audit trail, signed with ed25519
(or HMAC if you set AURELIUS_PROOF_HMAC_SECRET), written to ~/aurelius_output/proofs/ and
independently checkable with aurelius.proof.verify_proof(...). Optional IPFS pinning
(set PINATA_JWT) and optional on-chain anchoring (pip install aurelius-mcp[chain] + set
AURELIUS_CHAIN_RPC / AURELIUS_CHAIN_PRIVATE_KEY) layer on top; both are graceful no-ops when
unconfigured.
Publishing, DeSci & memory (Phases 4–6). The DAG also packages a submission-ready
preprint bundle (compile-ready LaTeX, a DOI-backed references.bib built from the Evidence
Ledger, and a per-server checklist for arXiv/bioRxiv/medRxiv) — submission itself stays
manual by design, since those servers require human endorsement/moderation. It runs a
patent-freedom screen (PatentsView, a screening aid — not legal advice), and it has
episodic memory: every run is recorded with derived lessons and relevant past runs are
recalled at the start of new ones. check_compliance remains an honest placeholder — see
ARCHITECTURE.md for the full status.
Platform | Status |
Claude Desktop / Code | ✅ Local stdio |
Gemini CLI, Cursor | ✅ Local stdio |
ChatGPT | ⚠️ Needs a remote (HTTP/SSE) deployment — on the roadmap |
Perplexity | ❌ No user-added MCP servers yet |
MIT
Run the FULL research loop autonomously (screen -> draft -> fact-check -> revise).
Requires an LLM API key with quota in the environment (OPENAI_API_KEY / ANTHROPIC_API_KEY / GOOGLE_API_KEY). Use this only when you want Aurelius to drive its own model instead of the host app's model. May take a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | gpt-4o-mini-2024-07-18 | |
| topic | Yes | ||
| provider | No | ||
| max_rounds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It mentions API key requirements, autonomous execution, and expected duration, but omits details on side effects, error handling, or the loop's internal behavior.
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 concise, with the first sentence immediately conveying the core action and steps. The second paragraph adds essential context on requirements and timing without unnecessary verbosity.
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?
Despite having an output schema, the description lacks details on step-by-step behavior, error scenarios, and parameter explanations. Given the tool's complexity (autonomous multi-loop research) and no annotations, more context is needed for full understanding.
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%, and the description provides no additional meaning for any of the 4 parameters (model, topic, provider, max_rounds). The schema itself has only titles and defaults, leaving agents uninformed about parameter 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?
The description clearly states the tool runs the full research loop autonomously, listing the steps (screen -> draft -> fact-check -> revise) and distinguishing it from sibling tools like screen_topic and draft_outline.
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?
It specifies the requirement for an LLM API key, warns about using only when the autonomous model is desired, and notes the time expectation. However, it doesn't explicitly list when to avoid using it or provide direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the multi-stage research DAG (agent swarm) instead of the linear loop.
Chains specialized agents — literature mining, a parallel hypothesis swarm, feasibility screening, experiment design/code generation, a hardened sandbox + static methodology (p-hacking/data-dredging) audit, citation verification (reusing the retraction-aware verifier), adversarial review, drafting, LaTeX, and a signed cryptographic proof-of-rigor attestation (SHA-256 content hash + signature, optional IPFS/on-chain anchoring) — logging every agent action to an audit trail and checkpointing each stage.
Requires an LLM API key with quota for the reasoning agents (OPENAI_API_KEY /
ANTHROPIC_API_KEY / GOOGLE_API_KEY); citation verification and proof signing are keyless.
Set enable_sandbox=True to actually execute the generated analysis code in a hardened,
network-less Docker container (off by default since the code is model-written; requires
Docker). check_compliance, publish_preprints, and patent_freedom remain honest
placeholders. Optionally pass breakpoints (stage names) to pause for human approval.
Returns {status, session_id, checkpoint, final_state, audit_trail}.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | gpt-4o-mini-2024-07-18 | |
| topic | Yes | ||
| provider | No | ||
| breakpoints | No | ||
| enable_sandbox | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the pipeline stages, logging/checkpointing, optional sandbox execution (and its dependency), placeholders, and breakpoints for human approval. It could be improved by mentioning error behavior or resource consumption, but for a complex tool it is fairly transparent.
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 quite long (several sentences) and front-loads the main purpose, but then lists many stages in a single sentence, making it somewhat dense. While every sentence adds value, it could be more structured (e.g., bullet points) for clarity. It is not optimally concise for an AI agent.
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?
Given the tool's complexity (multi-stage DAG, many parameters, optional features), the description is remarkably complete. It covers prerequisites, optional settings, placeholders, and output format. Since an output schema exists, the description's mention of the return structure adds completeness without redundancy.
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 must compensate. It adds meaning for 'enable_sandbox' (requires Docker, off by default) and 'breakpoints' (stage names for human approval). It also implies 'topic' and 'provider' usage. However, 'model' and 'provider' are not explained further, leaving some gaps.
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 it 'runs the multi-stage research DAG (agent swarm) instead of the linear loop,' using a specific verb and resource. It distinguishes itself from the sibling tool 'autonomous_research' by contrasting DAG vs linear loop, and enumerates the stages, making the purpose unambiguous.
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 description provides clear context for use, including prerequisites (LLM API key, optional Docker), and notes that some features are placeholders. However, it does not explicitly state when not to use this tool (e.g., for simple tasks) or list alternatives beyond the linear loop, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a Mermaid syntax scaffold (flowchart | architecture | sequence) to complete and embed in a ```mermaid fenced block.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| diagram_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool returns a scaffold, with no mention of side effects, authentication, limitations, or output behavior beyond the scaffold concept.
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 15-word sentence that is free of fluff and directly states the tool's purpose and output format.
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?
Given the two required parameters with no descriptions, the description is woefully insufficient. An agent cannot determine how to fill 'description' or 'diagram_type', nor understand the return value's structure despite an output schema being present.
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?
With 0% schema description coverage, the description must explain the parameters. It mentions diagram types but does not link them to the 'diagram_type' parameter or describe the 'description' parameter. No parameter details are added.
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 tool returns a Mermaid syntax scaffold for specific diagram types (flowchart, architecture, sequence). It uses a specific verb ('Return') and resource, distinguishing it from sibling tools focused on research and writing.
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 description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a standard academic outline scaffold (Abstract..References) for a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states the tool 'returns' an outline, implying a read-only generation. However, it does not disclose potential side effects, auth requirements, or behavior on invalid input, leaving behavioral gaps.
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 a single sentence that conveys the essential purpose without any extraneous words. It is front-loaded and efficient.
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?
Given the tool's simplicity (1 parameter, no annotations, output schema exists), the description is nearly complete for core usage. However, it lacks usage guidelines and parameter elaboration, which are minor gaps for a straightforward outline generator.
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?
With 0% schema description coverage, the description must add meaning to the single parameter 'topic'. It only mentions 'for a topic' without specifying format, constraints, or examples. This provides minimal additional value beyond the schema's field name.
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 verb 'Return', the resource 'standard academic outline scaffold', and the context 'for a topic'. It effectively distinguishes from siblings like autonomous_research or screen_topic by implying its specific purpose.
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 description implies usage for generating an outline scaffold, but lacks explicit guidance on when to use vs alternatives (e.g., autonomous_research, screen_topic). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Aurelius's admission policy (accepted vs restricted research domains).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the tool as returning policy information, implying a read-only operation, but does not disclose potential side effects, authentication requirements, or error conditions. The description is adequate but lacks behavioral depth beyond the basic operation.
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 a single, well-structured sentence that immediately conveys the tool's purpose with no unnecessary words. It is front-loaded and efficient.
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?
Given the tool's simplicity (no parameters, presence of output schema), the description is complete. It specifies what the tool returns, and the sibling tools are unrelated, so no additional context is needed.
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?
The tool has no parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter information, and none is missing.
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 tool returns Aurelius's admission policy, specifying the focus on accepted vs restricted research domains. The verb 'Return' and resource 'admission policy' are precise, and the purpose distinguishes it from sibling tools like autonomous_research or screen_topic, which involve active research tasks.
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 description implies usage context: use this tool when you need the admission policy. It does not explicitly state when not to use or mention alternatives, but given no sibling tool serves the same purpose, clarity is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a compile-ready LaTeX skeleton (Abstract..References) + a BibTeX entry
stub. template: "article" (single-column preprint), "twocolumn"
(conference/IEEE-style), or "report" (chaptered long-form).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| template | No | article |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it returns content with no side effects or behavioral details (e.g., read-only, no destruction). Lacks transparency on auth needs, rate limits, or prerequisites.
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?
Two clear, front-loaded sentences with no fluff. Each sentence serves a distinct purpose: main function and template details.
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?
Adequate for a simple tool with output schema present, but misses usage context, behavioral details, and topic parameter meaning. Lacks completeness for a new user.
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?
The description adds value for the template parameter by listing allowed values and their meanings (article, twocolumn, report). However, the required topic parameter is not explained beyond its name, and schema coverage is 0%.
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 it returns a compile-ready LaTeX skeleton (Abstract..References) plus a BibTeX stub, with specific verb 'Return' and resource. It distinguishes from siblings like draft_outline by specifying LaTeX format.
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 description implies usage for generating LaTeX skeletons with given templates but does not provide explicit when-to-use or exclusions vs. sibling tools like draft_outline or save_latex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the global scholarly literature across languages via OpenAlex (keyless).
languages are ISO 639-1 codes (default: zh, es, de, ja). With an LLM key configured
the query is translated per language for better native recall; without one the original
query is used (fewer, but still real, results). Use to surface non-English work
(Chinese, Spanish, German, Japanese...) that an English-only search misses.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| per_lang | No | ||
| languages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses keyless access, ISO 639-1 language codes, default languages, translation behavior with/without key, and that results are real but fewer without key. It lacks details on rate limits or pagination but is otherwise transparent.
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 concise, with front-loaded main action and no wasted sentences. It uses parenthetical clarifications effectively. Could be more structured (e.g., bullet points) but remains clean and readable.
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?
Given 3 parameters, no annotations, and an output schema (return values covered), the description covers core purpose, parameter details for two of three params, usage guidelines, and behavioral nuances. It feels fairly complete for a search tool, though 'per_lang' is a gap.
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 coverage is 0%. The description explains 'languages' as ISO 639-1 codes with defaults, and 'query' implication for translation. However, 'per_lang' (integer, default 3) is not explained; its meaning (presumably results per language) is left ambiguous, requiring the agent to infer or guess.
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 tool's function: 'Search the global scholarly literature across languages via OpenAlex (keyless).' It uses a specific verb ('search') and resource ('scholarly literature'), and differentiates from sibling tools like web_search by focusing on multilingual and non-English works.
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 description explicitly says when to use: 'Use to surface non-English work... that an English-only search misses.' It also explains behavior differences with/without an LLM key. While it doesn't list when not to use or explicit alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a section-by-section word-count budget for a target page count.
Use for long-form papers (e.g. 20-80 pages): call this first, then draft and verify section by section, appending each via save_draft(..., append=True).
| Name | Required | Description | Default |
|---|---|---|---|
| target_pages | No | ||
| words_per_page | No | ||
| target_pages_max | No | ||
| target_pages_min | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool creates a budget/plan, but does not mention side effects, auth requirements, or whether it is read-only. Since it is a planning tool, the lack of explicit safety guarantees is a gap.
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?
Two sentences, front-loaded with key purpose, no redundant words. Every sentence adds value.
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?
The description covers purpose and workflow well, but given 0% parameter documentation and no behavioral details beyond the plan computation, it feels incomplete. The presence of an output schema slightly reduces the need for return value explanation, but parameter semantics are missing.
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%, and the description does not explain any of the 4 parameters (target_pages, words_per_page, etc.). It adds no meaning beyond the raw schema fields.
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 it computes a section-by-section word-count budget for a target page count, distinguishing it from sibling tools like draft_outline by specifying it's for long-form papers (20-80 pages) and to be called first.
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?
Explicitly states when to use (for long-form papers, call first) and gives workflow guidance: then draft and verify section by section, appending via save_draft. This effectively differentiates usage from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Improve prose style/readability of an ALREADY FACT-CHECKED draft -- never alters citations, numbers, or claims. This is a readability pass, not an AI-detector evasion tool. Default returns guidelines for you to apply yourself; set use_llm=True to have Aurelius rewrite it (needs an LLM key; falls back to guidelines if none is configured).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | gpt-4o-mini-2024-07-18 | |
| content | Yes | ||
| use_llm | No | ||
| provider | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: never alters citations/numbers/claims, not an evasion tool, default returns guidelines, LLM mode needs a key and falls back. Could mention output format but output schema exists.
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?
Two efficient sentences convey all core information without waste. Essential caveats are front-loaded (no fact alteration, not evasion) followed by behavior options.
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?
Core behavior is covered, and output schema exists. However, no details about the format or content of the returned guidelines, or limitations on content length/type, leaving minor gaps for a tool with 0% schema coverage.
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 coverage is 0% and description only explains use_llm and its fallback. Remaining parameters (model, provider, content) are not described beyond their schema defaults, leaving the agent to infer meanings.
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 tool's purpose: to improve prose style and readability of a fact-checked draft without altering facts. It explicitly distinguishes itself from AI-detector evasion tools and presence of sibling tools confirm no direct polish alternative exists.
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 description provides when to use (after fact-checking), default behavior (returns guidelines), and optional LLM rewrite with prerequisite. It implies not for raw drafts but lacks explicit exclusion for non-readability tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall past Aurelius research sessions relevant to a topic (episodic memory).
Returns up to k past episodes — hypothesis, verification score, methodology risk,
and derived lessons — so new research can build on successes and avoid repeating
failures. Episodes are recorded automatically by the research graph.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full responsibility. It discloses return components (hypothesis, verification score, methodology risk, derived lessons) and notes automatic recording. While it doesn't cover every behavioral aspect, it provides sufficient transparency for a read-only memory recall.
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?
Description is concise and to the point, with no extraneous information. Every sentence adds value: purpose, return content, and benefit.
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?
Given the tool's simplicity (2 params, read-only, output schema present), the description covers all essential aspects: what it does, what it returns, and why to use it. It is complete and informative.
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?
With 0% schema description coverage, the description compensates by explaining 'k' as 'up to k past episodes' and 'topic' as relevance filter. This adds meaning beyond the schema's type and default, though a brief note on topic format could elevate it.
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?
Description clearly states it recalls past research sessions relevant to a topic. It specifies the verb 'recall' and the resource 'Aurelius research sessions', and distinguishes itself from sibling tools like autonomous_research or web_search by focusing on episodic memory.
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?
Description implies using this tool before starting new research to leverage past learnings. It explains the benefit ('build on successes and avoid repeating failures') but does not explicitly state when not to use or suggest alternatives, which is acceptable given the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-check previously verified citations for retractions or verification drift.
Pass citation strings to re-verify them now, or omit references to scan every saved
Proof-of-Rigor bundle and re-check all citations recorded there. Returns alerts for
anything newly retracted or no longer verifiable — a paper cited last month can be
retracted today.
| Name | Required | Description | Default |
|---|---|---|---|
| references | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns alerts for newly retracted or no longer verifiable items and explains the two operational modes. It does not mention permissions or side effects, but for a checking tool, this is acceptable.
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 very concise with two sentences and an introductory line. It is front-loaded with the purpose, and every sentence adds value without redundancy.
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 an output schema present, the description need not detail return values. It mentions 'alerts' as return type and covers the two usage modes. Given sibling tools' focus on verification, this description is sufficiently complete.
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 has one optional parameter (references) with 0% coverage. Description adds full meaning: passing strings re-verifies specific citations, omitting scans all bundles. This provides clear usage guidance 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 tool re-checks previously verified citations for retractions or verification drift. It distinguishes itself from sibling tools like verify_citation and verify_bibliography by focusing on re-verification over time.
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 description explicitly says when to use: to re-check citations for retractions. It provides context on two modes: passing specific references or omitting to scan all bundles. It lacks explicit alternatives or when-not-to-use instructions, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save (or, with append=True, append to) a Markdown research draft. Use append=True for long-form papers so you never resend the whole accumulated draft.
| Name | Required | Description | Default |
|---|---|---|---|
| append | No | ||
| content | Yes | ||
| filename | No | draft.md |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the append overwrite behavior and that it saves a Markdown draft. However, it doesn't mention permissions, file location, or whether it creates or overwrites by default, but the append hint mitigates this.
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?
Extremely concise: one sentence describing the action and one usage tip. No wasted words, front-loaded with the main action.
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?
Given the tool's simplicity (3 parameters, 1 required), the description covers the core functionality and append use case. Output schema exists but is not shown; however, for a save tool, return values are likely straightforward. Could mention that it saves to a persistent location, but generally complete.
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 description must compensate. It explains the append parameter well, but content and filename (with default) are not described. The append explanation adds value, but other parameters lack detail.
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 verb 'Save' and the resource 'Markdown research draft'. It also distinguishes between saving and appending with append=True, which differentiates it from sibling tools like save_latex or save_report.
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?
Provides explicit guidance on when to use append=True ('for long-form papers so you never resend the whole accumulated draft'). Could be more specific about when not to use this tool versus alternatives like save_report, but enough for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save LaTeX (.tex) or BibTeX (.bib) source to the Aurelius output directory.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| filename | No | paper.tex |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'save' (a write operation) but provides no details on side effects like overwriting behavior, file permissions, or output schema implications. No annotations exist to compensate.
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 one sentence, which is concise but at the expense of completeness. It lacks structured information and fails to front-load critical details.
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?
While the tool is simple and has an output schema, the description omits parameter explanations and behavioral context. It is incomplete for an agent to use effectively without additional knowledge.
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%, and the description does not explain the 'content' or 'filename' parameters. The agent has no insight into expected formats, defaults, or constraints 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 tool saves LaTeX or BibTeX source files, specifying the action and resource. It implicitly distinguishes from sibling save tools like save_draft and save_report by focusing on .tex/.bib formats.
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?
No guidance on when to use this tool versus alternatives such as save_draft or save_report. The description does not mention prerequisites, constraints, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a fact-checking report (first line 'STATUS: VERIFIED'/'STATUS: REJECTED').
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| filename | No | verification.md |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Mentions the required first line format but does not disclose error handling, overwrite behavior, or side effects.
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?
Single sentence, front-loaded with purpose. No unnecessary verbiage, though slightly more detail could be added without losing conciseness.
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?
Lacks details on return value (output schema exists but not described), prerequisites, and error conditions. Minimal support for a tool with two parameters and no annotations.
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 coverage is 0%. Description adds meaning for 'content' (required status line) but not for 'filename' beyond its default. Does not explain format or constraints on content beyond the first line.
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?
Clearly states the action 'Save' and the resource 'fact-checking report', and specifies the required first line format. Distinguishes from siblings like save_draft and verify_citation.
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?
No explicit guidance on when to use this tool versus alternatives. Implies it's for saving verified/rejected reports but lacks context like prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a research topic against the restricted-domain policy before drafting.
Returns a heuristic flag plus the full policy; you make the final accept/reject call.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it's a heuristic screening tool returning a flag and policy, but doesn't detail side effects, permissions, or read-only nature.
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?
Two sentence description: first sentence states purpose, second describes output and decision ownership. No wasted words.
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?
Tool has one parameter and no nested objects; description covers purpose and output sufficiently. Slight gap in not explaining how to interpret the heuristic flag.
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 coverage is 0%. Description does not explain the 'topic' parameter beyond its name; no format, examples, or constraints added.
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?
Description clearly states the action (screen), resource (research topic), and context (against restricted-domain policy before drafting). Distinguishes from siblings like 'draft_outline' and 'get_research_policy'.
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?
Explicitly says 'before drafting', indicating when to use. Implicitly contrasts with siblings, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an entire References/Bibliography block at once. Splits it into individual
citations, verifies each (DOI-precise, retraction- and author-aware), and returns a
scored ledger plus a cleaned DOI-backed corrected_bibtex and corrected_references.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool splits citations, verifies each with DOI-precise and retraction-aware checks, and returns a scored ledger with corrected BibTeX and references. This is thorough for a read-only verification tool.
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 three sentences, each serving a purpose: what it does, how it works, and what it returns. No wasted words; front-loaded with the core action.
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?
Given the complexity of splitting and verifying multiple citations, the description covers input, process, and output (scored ledger, corrected BibTeX, corrected references). An output schema exists, so return values are further explained; the description is complete for an agent to understand the tool's role.
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 coverage is 0%, but the description adds context by stating the input is 'an entire References/Bibliography block'. It does not specify exact formatting or expected structure, which would be helpful. Baseline 3 with low coverage is justified as the description adds some meaning 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 'Verify an entire References/Bibliography block at once', specifying the verb 'Verify' and the resource 'entire References/Bibliography block'. It distinguishes from sibling tool verify_citation by emphasizing the batch operation over a single citation.
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 description implies usage for full bibliography blocks, contrasting with verify_citation for individual citations. However, it does not explicitly list when not to use or provide alternative tools, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an academic citation against OpenAlex and Crossref (falls back to a web
search if the work isn't indexed there). Surfaces retraction status explicitly via
is_retracted -- a retracted paper is never quietly treated as verified.
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses fallback to web search and explicit retraction handling ('a retracted paper is never quietly treated as verified'), which are key behaviors. However, it does not mention authentication needs or rate limits.
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 concise (two sentences), front-loaded with the purpose and key behavior, with no wasted words.
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?
Given the tool has an output schema (so return format is covered) and only two parameters (one required), the description adequately covers verification scope, data sources, fallback, and retraction handling, making it complete for its purpose.
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%, meaning the description adds no explanation for parameters. The only parameter implicitly mentioned is 'citation', but 'max_results' is not described. The schema provides titles and defaults, so the description adds minimal semantic value beyond what is already in the JSON 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 tool's action ('Verify an academic citation'), specifies the resources (OpenAlex and Crossref with fallback to web search), and distinguishes it from siblings like verify_bibliography, verify_claims, and verify_stat by focusing on citation verification and retraction detection.
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 description implies usage for verifying a single citation and mentions fallback behavior, but it does not explicitly state when not to use this tool or provide guidance on selecting among sibling tools such as verify_bibliography, verify_claims, or verify_stat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch-verify a list of citations and/or factual claims in one call. Produces a scored evidence ledger (verification_score, per-item verdicts + sources) and a save_report-ready Markdown summary with unverified/retracted items struck through.
| Name | Required | Description | Default |
|---|---|---|---|
| claims | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output format: 'scored evidence ledger... Markdown summary with unverified/retracted items struck through.' However, it does not mention whether the operation is read-only (likely) or any side effects, permissions, or rate limits.
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?
Two sentences with no redundancy. The first sentence states the purpose, the second describes the output. Every phrase adds value.
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?
Given the presence of an output schema (mentioned but not shown), the description needn't detail return values, yet it does. It omits error handling, prerequisites, or usage context, but for a batch verification tool, the coverage is strong.
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?
The input schema has one parameter 'claims' with description coverage 0%. The description adds that it expects a 'list of citations and/or factual claims', which provides context beyond the schema's type/array definition. However, it does not specify string format, validation, or constraints.
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 'Batch-verify a list of citations and/or factual claims in one call.' It specifies the action (verify) and the resource (a list of citations/claims), distinguishing it from sibling tools like verify_citation, verify_stat, and verify_bibliography, which handle individual items.
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 description implies batch use ('in one call') but does not explicitly state when to use this tool versus the individual verification siblings. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a numeric/statistical claim (e.g. 'US GDP grew 2.5% in 2023') against World Bank primary data. Pass country/year/claimed_value (and optionally a World Bank indicator code) for precision; falls back to web search if the data source is unavailable. Returns verdict verified/contradicted/unverified with the actual value.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| claim | Yes | ||
| country | No | ||
| indicator | No | ||
| claimed_value | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses fallback to web search, data source (World Bank), and return type (verdict with actual value). This is sufficient for a safe, non-destructive tool.
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?
Two clear sentences with no extraneous words. The action verb and purpose are front-loaded. Every sentence adds essential information.
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?
Given 5 parameters (one required) and an output schema, the description covers the core behavior, return values, and fallback. It does not detail error cases or edge conditions, but it is adequate for correct tool selection and invocation.
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?
With 0% schema description coverage, the description compensates by explaining the roles of country, year, claimed_value, and indicator. The 'claim' parameter is implied by the example. This adds meaning beyond the raw 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 explicitly states it verifies numeric/statistical claims against World Bank data, with a concrete example. This clearly distinguishes it from siblings like 'verify_claims' or 'verify_citation' which handle other types of claims.
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 description advises passing country/year/claimed_value and optionally an indicator for precision, and notes fallback behavior. It provides clear usage context but lacks explicit when-not-to-use or comparison to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web (Tavily) for evidence about a factual claim or question.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| academic_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the underlying service (Tavily) but fails to disclose rate limits, pagination, result format, or any side effects. As a read operation, lacks essential behavioral context for safe invocation.
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 a single concise sentence with no wasted words. It front-loads the core action and purpose, making it easy 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?
Despite having an output schema (which reduces the burden of explaining return values), the description lacks details on result format, limitations, or typical use cases. Given the tool's simplicity and the presence of an output schema, the description is adequate but not rich.
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?
The input schema has three parameters but zero description coverage in the schema itself. The tool description does not explain the meaning or usage of 'query', 'max_results', or 'academic_only' beyond their titles, leaving the agent without guidance on how to properly set these parameters.
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 verb 'search' and the resource 'web', specifying the purpose as 'for evidence about a factual claim or question.' It is specific enough to distinguish from siblings like 'autonomous_research', though not explicitly differentiated.
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 description implies when to use the tool (when needing evidence for a factual claim or question) but does not provide guidance on when not to use it or contrast with sibling tools like 'autonomous_research.' No alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.6.0latex_outline1 field changedInput schema / properties / templateAdded value: +{
+ "default": "article",
+ "title": "Template",
+ "type": "string"
+}multilingual_searchresearch_memoryretraction_watchv0.5.0autonomous_research_graphdiagram_templatelatex_outlineplan_paper_lengthpolish_prosesave_draft1 field changedInput schema / properties / appendAdded value: +{
+ "default": false,
+ "title": "Append",
+ "type": "boolean"
+}save_latexverify_bibliographyverify_claimsverify_statv0.1.2autonomous_researchdraft_outlineget_research_policysave_draftsave_reportscreen_topicverify_citationweb_searchScored across 20 tools
Most tools have distinct purposes, like verify_citation vs verify_claims vs verify_bibliography vs verify_stat. However, autonomous_research and autonomous_research_graph could be confused if descriptions are not read carefully.
Names mix verb_noun (get_research_policy, save_draft) and noun_noun (diagram_template, retraction_watch) patterns without a consistent convention. Some tools start with adjectives (autonomous_research) or other parts of speech.
20 tools is slightly high but justifiable for a research assistant covering screening, searching, verification, drafting, and automation. Each tool serves a distinct function without redundancy.
The tool set covers the full research lifecycle: screening, policy, multilingual search, web search, citation/claim/stat verification, drafting (outline, LaTeX, word budget, prose polish), saving, and autonomous research loops. No obvious gaps.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
An MCP server for deep research or task groups
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
