Skip to main content
Glama

add_entry

Add a BibTeX entry to the currently open JabRef library, triggering JabRef's duplicate detection and import prompt. Requires JabRef running with remote operation enabled.

Instructions

Add a new entry to the JabRef library - the ONLY supported way of adding entries.

This requests an import through JabRef's official CLI API (jabref --importBibtex), which means:

  • the entry is sent to the library that is OPEN in JabRef, with JabRef's own duplicate detection;

  • JabRef may ask you to accept the import before you save the library;

  • the .bib file is never modified by this server. Requires JabRef to be running with 'Listen to remote operation on port' enabled (Preferences -> Network), same as for the official browser extension.

Args: bibtex: a complete BibTeX entry, e.g. '@article{key, title={...}, author={...}, year={2024}}'. timeout: optional override of the import timeout in seconds.

Returns the canonical BibTeX that was sent to JabRef. A successful return confirms dispatch to JabRef, not that the entry has already been accepted and saved.

Workflow after successful dispatch:

  • Ask the user to accept and save the import in JabRef if prompted, and to confirm when the library has been saved before attempting verification.

  • Do not claim that the entry is persisted yet.

  • After the user confirms saving, verify with search using stable metadata such as title, DOI, or author, rather than relying only on the submitted citation key.

  • JabRef may replace the submitted citation key; use the key returned by search when calling get_entry or get_pdf.

  • Read tools automatically detect the saved file. Do not ask for an MCP restart.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bibtexYes
timeoutNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full burden and meets it: it exposes the CLI mechanism, duplicate detection, the possibility of a user accept prompt, the fact that the .bib file is not modified by the server, and that success means dispatch only, not persistence. This discloses side-effect and reliability semantics that annotations would otherwise hide.

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 front-loaded with the one-line purpose, then uses labelled sections (Args, Returns, Workflow) and bullets for behavioral caveats. Although long, the length is justified because the tool has asynchronous, user-interactive behavior that cannot be safely summarized in one line.

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

Completeness5/5

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

For a mutation-like tool with no annotations and an important asynchronous caveat, the description covers prerequisites, invocation semantics, return meaning, post-call workflow, verification strategy, and even restart behavior. Nothing necessary for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the schema alone gives no meaning. The description compensates by defining bibtex as 'a complete BibTeX entry' with a concrete example, and by explaining timeout as 'optional override of the import timeout in seconds'. Both parameters are semantically fully specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb + resource: 'Add a new entry to the JabRef library', and adds 'the ONLY supported way of adding entries', which differentiates it from all sibling tools that either read or search entries. There is no ambiguity about what the tool does.

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

Usage Guidelines5/5

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

It states a hard prerequisite ('JabRef must be running with Listen to remote operation on port enabled'), and notes that this is the only supported add path, so there is no alternative tool to choose. The post-dispatch workflow also tells the agent when to verify via search and when to ask the user to save, which is precise usage guidance.

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