This server generates, looks up, and formats citations and bibliographies inside an MCP-compatible AI app, with no account and no stored data.
Format individual citations for journal articles, books, websites, book chapters, theses, reports, datasets, and preprints from typed details.
Look up and cite sources from DOIs (Crossref), ISBNs (Open Library), and web URLs.
Create in-text citations in parenthetical or narrative form, with optional page numbers.
Build alphabetized works cited lists or IEEE-numbered bibliographies from multiple typed sources, DOIs, ISBNs, and URLs.
Find DOIs by title, optionally narrowed by author family name.
Support APA 7, MLA 9, Chicago author date, Harvard, and IEEE; some tools can return APA 7, MLA 9, and Chicago all at once.
Run read-only tools with no sign-in, API key, or source storage.
Allows looking up DOI metadata through Crossref to generate formatted citations and in-text citations in APA 7, MLA 9, and Chicago author date.
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., "@Citations MCP Cite 10.1038/nature14539 in APA 7 with an in-text citation."
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.
Paste a DOI or an ISBN into your AI app and get a formatted citation back in APA 7, MLA 9, Chicago author date, Harvard or IEEE, ready to paste into your works cited list. It is a citation generator that runs inside the app you are already writing in, so there is no web page to fill in and no account to create. You can also type the details yourself, or give the DOI or the ISBN, and get the matching in text citation, either in brackets or in the narrative form for a sentence where you name the author. Give several sources in one call and you get them back as an alphabetised works cited list. The wording and punctuation come from tested code, so they are the same every time. Free and open source, no account, no key and nothing stored. It works with Claude, ChatGPT, Cursor, VS Code Copilot and any other app that supports MCP.
BibGuru and Citation Machine are web pages you fill in and copy from. Citations MCP sits inside the AI app you are already writing in, and it takes a DOI or an ISBN as well as typed details. Here is the side by side.
Citations MCP | |||
Where you use it | In the AI app you already have open | In a web page in your browser | In a web page in your browser |
What you type in | A DOI, an ISBN, or the details of the source | A URL, a title or an author to search for, or the details you type | The details you type, or a citation you paste in |
Styles you get back | APA 7, MLA 9, Chicago author date, Harvard, IEEE | APA, MLA, Harvard and many more styles | APA, MLA, Chicago, Harvard and thousands more styles |
In text citation | Yes, with an optional page number, in the parenthetical or the narrative form | Yes | Yes |
Keeping your sources | Nothing is stored | BibGuru Plus saves sources in projects and folders | The paid tier saves your citations |
Cost | Free, MIT license, open source | Free, with a paid plan | Free, with a paid tier |
Signing in | Never | Only to save your sources | Only to save your citations |
Both other tools cover many more styles than this one does. What you get here is a citation in the chat you are writing in, from a DOI or an ISBN, with nothing to sign up for.
Related MCP server: Scholar Sidekick
The other MCP servers for citations are the Zotero ones: zotero-mcp, @oscardvs/zoteus and @xbghc/zotero-mcp. They are the closer competition, because they run inside your app as well. They are also built around a library you keep in Zotero, so they ask more of you first. Here is the side by side.
Citations MCP | ||||
What it works with | A DOI, an ISBN, or the details you type | Your Zotero library | Your Zotero library | Your Zotero library |
What you need first | Node.js 20 or newer, nothing else | Zotero on your computer, with the plugin the project ships | Zotero on your computer, or an account at zotero.org | An account at zotero.org, with an API key and a user ID |
Signing in | Never | Only if you use the Zotero web library | Only for sync and group libraries | Always, the API key is how it reaches your library |
Citation styles | APA 7, MLA 9, Chicago author date, Harvard, IEEE | None of its own, it passes your items to your app | Any CSL style, through the citeproc-js library | Entries as BibTeX, RIS or CSL JSON |
What you get back | A finished citation, and the in text form with a page number | Items, notes and PDF text from your library | Items, PDF passages with page numbers, and formatted bibliographies | Items and PDF text, plus exports for a bibliography tool |
Reading your library | No, it looks up one source at a time | Search, collections, annotations and PDF text | Search by word or by meaning, PDF passages, annotations and bibliography imports | Search, details, full text, and filtering by group or tag |
Writing to your library | No, every tool is read only | Notes, tags, metadata and new items | Adds, edits, tags, groups and files | Creates, edits, deletes, tags, groups and attachments |
Where your sources live | Nowhere, nothing is stored | In your Zotero library | In your Zotero library | In your Zotero library |
Good for | One citation now, with nothing to set up | Working inside a library you already keep in Zotero | The same, with a deeper read of your PDFs and many more styles | The same, with export formats your bibliography tool can read |
All three are open source under the MIT license, as this one is. Two of them talk to the Zotero desktop app, so you install Zotero and keep it running while you work. The third goes through the Zotero web API, so you sign in at zotero.org and paste an API key and your user ID.
That is the trade. The Zotero servers do more with a library you already keep. They search it, read your PDFs, give you a passage with its page number and write notes and tags back into it. Citations MCP covers the other half of the job. You give it a DOI, an ISBN or the details of a source, and it gives you the citation and the in text form, in the chat, with nothing to install, no account and nothing stored. If your course needs one of the many styles Zotero can produce, take one of the Zotero servers. If you need the reference for one essay, this is the shorter path.
Each project keeps its own setup guide: cookjohn/zotero-mcp, oscardvs/zoteus and xbghc/zotero-mcp.
Here is the same paper in all three styles, with the in text citation and the narrative form for each one. The narrative form is for a sentence where you name the author, as in "LeCun et al. (2015, p. 436) argue that ...". Copy the lines you need.
Deep learning
LeCun, Yann, Yoshua Bengio and Geoffrey Hinton
Nature, 2015, volume 521, issue 7553, pages 436 to 444
DOI 10.1038/nature14539
APA 7
LeCun, Y., Bengio, Y., & Hinton, G. (2015). Deep learning. *Nature*, *521*(7553), 436-444. https://doi.org/10.1038/nature14539
In text: (LeCun et al., 2015, p. 436)
Narrative: LeCun et al. (2015, p. 436)
MLA 9
LeCun, Yann, et al. "Deep learning." *Nature*, vol. 521, no. 7553, 2015, pp. 436-444, https://doi.org/10.1038/nature14539.
In text: (LeCun et al. 436)
Narrative: LeCun et al. (436)
Chicago author date
LeCun, Yann, et al. 2015. "Deep learning." *Nature* 521 (7553): 436-444. https://doi.org/10.1038/nature14539.
In text: (LeCun et al. 2015, 436)
Narrative: LeCun et al. (2015, 436)If you are comparing styles, pass style as all to format_citation or cite_from_doi. You get one labelled citation for APA 7, MLA 9 and Chicago author date in one reply, instead of three calls. The label above each citation is the style name, so you can pick the one you want. format_bibliography, cite_from_isbn and in_text_citation still take one style at a time.
npx -y student-citations-mcpNothing else to install. You need Node.js 20 or newer. The config block for your app is further down this page.
Tool | What it does |
| Format a journal article, book, website, book chapter, thesis, report, dataset or preprint from details you type, in APA 7, MLA 9, Chicago author date, Harvard or IEEE. For books you can name the editors and the translators too. Pass |
| Format several sources as one works cited list, alphabetised by author in APA 7, MLA 9, Chicago author date or Harvard, or numbered in the order you give them in IEEE. Each source takes the same fields as |
| Look up a DOI on Crossref and format the citation. The Crossref record decides the shape, so a book chapter comes back as a chapter and a dissertation comes back as a thesis. Pass |
| Search Crossref by title, and optionally an author's family name, and list the best matches with their DOIs. Pass the one you want to |
| Look up an ISBN on Open Library and format the citation |
| Fetch a web page and cite it as a website in APA 7, MLA 9, Chicago author date, Harvard or IEEE. It reads the page title, site name and date, and you can override any of them |
| The in text citation that matches a source, with an optional page number, in the parenthetical or the narrative form. It takes the authors and year you type, or a DOI or an ISBN and looks up the authors and year for you |
All seven tools are read only.
Prompt | What it does |
| Start a citation in APA 7, MLA 9 or Chicago author date from a DOI, an ISBN or details you type. It fills in the wording the tools use, so you can edit the source and send it |
A client that supports prompts, such as Claude Desktop or VS Code, shows it in the chat as a command you can run. In Claude Desktop it is /cite_this.
The prompt looks nothing up. It only writes out the request, so you can check it before you send it. Here is the message it puts in the chat when you run it with no arguments:
Cite this source in APA 7.
Use the tool that fits the source: cite_from_doi for a DOI, cite_from_isbn for an ISBN, cite_from_url for a web address, format_citation for details you type and in_text_citation for the in text form.
Example prompts:
- "Cite this journal article in APA 7: Learning to learn by John Kenneth Smith and Alice Jones, 2020, Journal of Study Skills, volume 4, issue 2, pages 11-25."
- "Cite 10.1038/nature14539 in APA."
- "Cite ISBN 978-0-262-03384-8 in APA 7."
- "Give the APA in text citation for Smith and Jones 2020 on page 14."It takes two arguments. style picks the style, which is APA 7 unless you say otherwise, and source is the DOI, the ISBN or the details you want to cite. Give it a DOI and the message says so and points at cite_from_doi.
"Cite 10.1038/nature14539 in APA."
"Cite 10.1038/nature14539 in all three styles."
"Cite this web page in APA: https://example.edu/study."
"Cite the DOI of this book chapter in APA, with the editors of the book."
"Make an MLA citation for ISBN 9780262033848."
"Format this as Chicago: Smith and Jones, 2020, Learning to Learn, Journal of Study Skills, volume 4, issue 2, pages 11 to 25."
"What's the in text citation for a quote on page 14 of that paper?"
"Give me the APA in text citation for DOI 10.1038/nature14539 on page 436."
"What's the MLA in text citation for ISBN 9780262033848?"
"Give me the APA citation for that in narrative form, so I can name the author in my sentence."
"Format this book in MLA with the editors taking the author's place: A dictionary of study words by Jamie Patel and Robin Cole, 2019, North Gate Press."
"Cite this translated book in APA: My brilliant friend by Elena Ferrante, translated by Ann Goldstein, 2012, Europa Editions."
"Cite this thesis in APA: Learning to learn by Jane Doe, 2021, North Gate University, Ph.D. dissertation."
"Put these sources into one APA works cited list, alphabetised by author."
Ask for "Cite 10.1038/nature14539 in APA." and the server gives back:
LeCun, Y., Bengio, Y., & Hinton, G. (2015). Deep learning. *Nature*, *521*(7553), 436-444. https://doi.org/10.1038/nature14539
(From Crossref. Check it against your style guide.)Italics come back as asterisks so your app can style them.
If this saved you a formatting headache, please give the repo a star. It sits at 0 stars, and one star helps the next student find it.
Edited and translated books are common in coursework, and each style puts those names in its own spot. format_citation takes editors and translators in the same shape as authors. When a book has editors and no authors, the editors take the author's place. When the book has an author as well, the extra names go after the title, next to the edition. Here is one edited book and one translated book in all three styles.
A dictionary of study words
Jamie Patel and Robin Cole, editors, 2019, North Gate Press
APA 7
Patel, J., & Cole, R., Eds. (2019). *A dictionary of study words*. North Gate Press.
MLA 9
Patel, Jamie, and Robin Cole, editors. *A dictionary of study words*. North Gate Press, 2019.
Chicago author date
Patel, Jamie, and Robin Cole, eds. 2019. *A dictionary of study words*. North Gate Press.
My brilliant friend
Elena Ferrante, 2012, translated by Ann Goldstein, Europa Editions
APA 7
Ferrante, E. (2012). *My brilliant friend* (Goldstein, A., Trans.). Europa Editions.
MLA 9
Ferrante, Elena. *My brilliant friend*. Translated by Ann Goldstein, Europa Editions, 2012.
Chicago author date
Ferrante, Elena. 2012. *My brilliant friend*. Translated by Ann Goldstein. Europa Editions.With a DOI the server reads the Crossref record and follows the type it finds. A book does not come back as a journal article with a volume and an issue it does not have.
Crossref type | What you get back |
| A journal article, with its volume, issue and pages |
| A book, and the editors take the author's place when the book has no author |
| A chapter in its book, with the pages it covers |
| A thesis, with the degree and the university |
| A report, with its report number |
| A data set |
| A preprint, with the repository it was posted in |
format_citation takes the same kinds of source, so you can type the details of a chapter, a thesis, a report, a data set or a preprint when there is no DOI to look up. A journal article and a chapter also need container, the journal name or the book title they appear in. Without it the server returns an error that names the container, instead of a citation with a missing part.
format_bibliography takes several sources in one call and returns them as one list, alphabetised by the first author's family name. A source with no author is alphabetised by its title, and a leading "A", "An" or "The" is skipped. Each source takes the same fields as format_citation, so a journal article, a book and a website can sit in the same list. You can also pass dois and isbns lists, which are looked up on Crossref and Open Library and added to the list, up to 50 in one call. If one lookup fails, the reply is an error that names it. Here are those three sources in APA 7.
Cormen, T. H. (2009). *Introduction to algorithms* (3rd ed.). MIT Press.
Smith, J. K., & Jones, A. (2020). Learning to learn. *Journal of Study Skills*, *4*(2), 11-25.
*The water cycle*. Example Uni. https://example.edu/waterClaude Desktop. Put it in claude_desktop_config.json.
{
"mcpServers": {
"citations": {
"command": "npx",
"args": ["-y", "student-citations-mcp"]
}
}
}Cursor. Put it in .cursor/mcp.json.
{
"mcpServers": {
"citations": {
"command": "npx",
"args": ["-y", "student-citations-mcp"]
}
}
}VS Code. Put it in .vscode/mcp.json. VS Code uses a servers key, not mcpServers.
{
"servers": {
"citations": {
"type": "stdio",
"command": "npx",
"args": ["-y", "student-citations-mcp"]
}
}
}Restart your AI app, then try one of the questions above. For Claude Code, run claude mcp add citations -- npx -y student-citations-mcp.
Does it work with Cursor?
Yes. It runs over MCP, so it works in Cursor, Claude Desktop, VS Code with Copilot, ChatGPT and any other app that supports MCP. The config block is the same for every app, only the file it goes in changes. Copy that block into your app's MCP config, restart the app and ask for a citation.
Is it free?
Yes. It is MIT licensed and free to use. There is no account, no key, no paid plan and no trial that runs out. The DOI and ISBN lookups go to Crossref and Open Library, and the server sends no key, so there is nothing else to sign up for.
Do I need an account or an API key?
No. There is no sign up step and no key to paste into a config file. The install command is the whole setup.
How is this different from the Zotero MCP servers?
They are the other MCP servers for citations, and they are the closer competition, because they run inside your app as well. They are built around a Zotero library, so they need Zotero installed or a Zotero account, and they can search that library, read your PDFs and write back to it. This server works on one source at a time. You give it a DOI, an ISBN or the details and it gives you the citation, with nothing to install, no account and nothing stored. The comparison table above has the details.
What happens to my data?
Nothing is stored. The server keeps no list of your sources, writes no files and sends no usage data anywhere. It takes the details you type in the chat and, for a DOI, an ISBN or a web page URL, sends that identifier or address to Crossref, Open Library or the page itself to fetch the record or the page. The request also carries a user agent line with the server name and version, plus your email address if you set CROSSREF_EMAIL.
How do I install it?
Run npx -y student-citations-mcp. You need Node.js 20 or newer, and that is the only thing to install. npx fetches the package into the npm cache and runs it, so nothing is added to your project. Then add the config block to your app and restart it.
Does it work without internet?
Partly. format_citation works offline, because it formats the details you type. in_text_citation works offline too when you type the authors and the year. It also takes a DOI or an ISBN, and those lookups need a connection, as do cite_from_doi, cite_from_isbn and cite_from_url, which fetch the record or the page from Crossref, Open Library or the web address you give.
Which styles can I ask for?
APA 7, MLA 9, Chicago author date, Harvard and IEEE. Ask for "APA", "MLA 9", "Chicago" or "Harvard" in the chat and the server works out the style name. In IEEE, format_bibliography numbers the list [1], [2] and so on in the order you give the sources, and in_text_citation gives [1], so change the number to the one the source has in your list. format_citation, cite_from_doi and cite_from_url also take all, which returns APA 7, MLA 9 and Chicago author date in one reply. A request for a style it does not have comes back with an error that names the styles it knows.
What can I cite?
A journal article, a book, a book chapter, a thesis, a report, a dataset, a preprint or a website. With a DOI the server reads the Crossref record and follows the type it finds, so a journal article comes back as an article, an edited book comes back as a book with its editors, a book chapter or a conference paper comes back as a chapter, a dissertation comes back as a thesis, and a preprint comes back with the repository it was posted in. With an ISBN it reads the Open Library record for the book. If the lookup fails, or the source has no DOI, format_citation takes the details you type and formats them.
Can I cite a book with editors or translators?
Yes. format_citation takes editors and translators in the same shape as authors, and each style puts those names where it wants them. The Editors and translators section above shows a worked example for each style.
Does it check the citation against my style guide?
No. It formats from fixed rules in the code, and every style has cases it does not cover, such as editors and translators inside a journal article, chapter numbers and multi volume sets. Check the result against your course's style guide or your instructor's rules.
Will it touch my files or my bibliography?
No. The tools only return text in the chat. Nothing is written to your project and nothing is added to your reference list, so copy a citation into your own bibliography if you want to keep it.
Can I use it to build a works cited list?
Yes. format_bibliography takes several sources and returns them alphabetised as one list, in APA 7, MLA 9 or Chicago author date, ready to paste into your document. Each source takes the same fields as format_citation. The server keeps no list of your sources, so your works cited list stays where you put it.
How do I remove it?
Take the block out of your app's MCP config and the server stops running. There is nothing else to uninstall, since npx keeps its copy in the npm cache rather than in your project.
Can I paste a DOI link or an ISBN with dashes?
Yes. cite_from_doi and in_text_citation take a plain DOI like 10.1038/nature14539 or a doi.org link, and cite_from_isbn and in_text_citation take a 10 or 13 digit ISBN with or without dashes.
Is the source code open?
Yes. The MIT license and the full source are on GitHub, and the formatting rules live in src/format.ts if you want to read them.
Always check the result against your course's style guide or your instructor's rules. Styles have many special cases this tool does not cover, such as editors and translators inside a journal article, chapter numbers and multi volume sets.
Titles are used as the source gives them. APA wants sentence case for article titles, so fix capitals if your style needs it.
Optional environment variables, CROSSREF_EMAIL puts your address in lookups so Crossref can reach you about heavy use, and CROSSREF_BASE_URL and OPENLIBRARY_BASE_URL point to other servers for testing.
npm install
npm run build
npm testTests run against fake Crossref and Open Library servers, so they need no network. The test runner needs Node.js 22.12 or newer, and the CI workflow uses Node 22.
The CI workflow installs the dependencies, builds the server and runs the tests on every push to main and on every pull request. One of those tests checks that the version is the same in package.json, server.json, llms.txt and glama.json, so the npm release and the registry entry stay in step. Another one checks that the paste ready example above is exactly what cite_from_doi returns for that DOI, so the page and the code stay in step. One more checks that the npm keywords and the descriptions keep the words students type when they look for a citation tool. A test also checks that the cite_this prompt is registered and that the message it returns carries the same example wording as the citation tool descriptions.
All free, open source and read only where they touch your accounts. Browse the full list at brightspacemcp.com/more-mcps.
Server | What it does |
D2L Brightspace for AI. Due dates with real submission status, grades, a target grade calculator and course files. | |
Canvas LMS for AI, read only. Due dates, missing work, grades and announcements. | |
Moodle for AI, read only. Due dates, overdue work, grades and announcements. | |
Google Classroom for AI, read only. Todos, due dates, missing work and grades. | |
GPA, grade conversion and the grade you need on the final, for AI. Works offline, no account. | |
Exam study schedules, spaced repetition dates, pomodoro plans and assignment milestones. Works offline. | |
Search scholarly papers, find open access copies and related work through OpenAlex. No key needed. | |
Clean, convert, dedupe and lint BibTeX, RIS and CSL JSON reference lists, and make cite keys. Works offline. | |
Find free legal copies of textbooks on OpenStax, DOAB and Open Library, look up editions by ISBN and suggest cheaper older ones. | |
Chemistry and physics homework math: molar mass, balancing equations, grams to moles, unit conversion and significant figures. Works offline. | |
Offline writing metrics for essays. Word and page counts, readability scores, passive voice, repeated openers, filler words, long sentences and word limit checks, so students can check their work against assignment requirements. No account, no network. | |
Syllabus to calendar MCP server. Extract dates from syllabus text, build an ics calendar, expand recurring classes and merge calendars. Works offline, no account. | |
Job application tracker MCP server. Track internships, jobs, interviews and deadlines offline, see what is coming up, and export your list as CSV or Markdown. No account and no API keys. |
MIT
Look up a DOI on Crossref and format the citation. The Crossref record decides the shape: a journal article, a book or an edited book, a book chapter or a conference paper, a thesis, a report, a dataset or a preprint. Inputs: doi (a DOI like 10.1038/nature14539 or a doi.org link) and style (apa7, mla9, chicago-ad, ieee or all). Pass all to get all three styles in one reply, each one with its style name on the line above it. Example prompt: "Cite 10.1038/nature14539 in APA."
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | A DOI like 10.1038/nature14539, or a doi.org link. | |
| style | No | Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee, or all to get APA 7, MLA 9 and Chicago author date in one reply with a label above each one. | apa7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuine context beyond the readOnly/openWorld annotations: the external Crossref dependency (which explains openWorldHint) and the fact that the record type determines the citation shape. But it omits practical behavior like what happens when the DOI is not found, rate limits on Crossref, or whether a failed lookup returns an error or a partial citation.
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?
Front-loaded with the core action, then inputs, then the 'all' behavior and an example — every element is scannable. The record-type enumeration is slightly long but earns its place by setting expectations for output shape.
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 no output schema, the description carries the return-value burden and does so for the multi-style case (labeled lines above each citation), plus it signals that output shape varies by record type. What a single-style response looks like (bare citation string vs. labeled) is left unstated.
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 100%, so both parameters are already documented; the description mostly repeats 'doi' and 'style'. It does add the 'all' output behavior (three styles, each labeled above), but its style list ('apa7, mla9, chicago-ad, ieee or all') omits the 'harvard' value the schema declares, a small inconsistency an agent could trip on.
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?
States a specific verb+resource pair ('Look up a DOI on Crossref and format the citation') and enumerates the record types the lookup can resolve, so an agent knows exactly what comes back. It never names the sibling input-variant tools (cite_from_url, cite_from_isbn), so the differentiation is only implicit in the 'doi' parameter.
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?
Gives clear context for invocation: accepted DOI formats, the valid style values, the special 'all' case, and an explicit example prompt ('Cite 10.1038/nature14539 in APA'). It stops short of exclusions — nothing says to use cite_from_url when the identifier is a publisher URL rather than a DOI, which is the one real ambiguity given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an ISBN on Open Library and format the book citation in APA 7, MLA 9, Chicago author date or IEEE. Inputs: isbn (a 10 or 13 digit ISBN, dashes are fine) and style (apa7, mla9, chicago-ad or ieee). Example prompt: "Cite ISBN 978-0-262-03384-8 in MLA 9."
| Name | Required | Description | Default |
|---|---|---|---|
| isbn | Yes | A 10 or 13 digit ISBN. Dashes are fine. | |
| style | No | Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee. | apa7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true; the description usefully confirms the external source ('Open Library'), which is consistent with openWorldHint. It does not disclose what happens on an invalid/unknown ISBN, rate limits, or lookup failures — behavioral gaps that matter for a network-dependent 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?
Three compact sentences: purpose first, then inputs, then a concrete example. Every sentence carries information and nothing is padded.
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 no output schema, the description adequately signals the return ('format the book citation' in a given style) and names the data source. Missing only edge-case behavior for unresolvable ISBNs or unsupported styles, which would round it out.
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 100%, so both parameters are already documented, and the description largely restates them. Notably it lists only apa7, mla9, chicago-ad and ieee while the schema also accepts harvard, a small inconsistency that could mislead on valid values; the dash-tolerance note is repeated from 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?
States a specific verb+resource pair: 'Look up an ISBN on Open Library and format the book citation' in four named styles. The ISBN focus implicitly separates it from the DOI/URL siblings, but it never names those alternatives, so sibling differentiation is left to inference.
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 'Inputs: isbn ... and style ...' line plus the worked example prompt ('Cite ISBN 978-0-262-03384-8 in MLA 9') give a clear picture of when and how to call it. No exclusions are stated — nothing tells the agent to use cite_from_doi or cite_from_url instead when it holds a DOI or URL rather than an ISBN.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page and format it as a website citation in APA 7, MLA 9, Chicago author date or IEEE. It reads the page title, the site name and the date from the page. Inputs: url (a full web address), style (apa7, mla9, chicago-ad, ieee or all), and optional title, site_name and date to replace what the page gives. Pass all to get all three styles in one reply, each one with its style name on the line above it. Example prompt: "Cite this page in APA: https://example.edu/study."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A full web address, like https://example.edu/study. | |
| date | No | Use this date instead of the one on the page, like 2026-10-14 or October 14, 2026. | |
| style | No | Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee, or all to get APA 7, MLA 9 and Chicago author date in one reply with a label above each one. | apa7 |
| title | No | Use this title instead of the one on the page. | |
| site_name | No | Use this site name instead of the one on the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond openWorldHint/readOnlyHint, the description discloses real behavior: it fetches the live page and extracts title, site name and date, and those values can be overridden by the optional params. It also describes the multi-style response shape ('each one with its style name on the line above it'), which matters because there is no output schema. It omits what happens on an unreachable or unparseable page.
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 purpose and style list are front-loaded, and the example prompt is a compact, useful addendum. The middle 'Inputs: ...' clause largely duplicates the schema and is the one part that does not earn its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an open-world fetch-and-format tool with no output schema, the description covers the fetch, the auto-extracted fields, the override path, the style set, and the shape of a multi-style reply. Nothing essential for a correct call is 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 coverage is 100%, so every parameter is already documented, including the 'all' option and date format examples. The description restates the parameter list and override semantics without adding syntax or constraints the schema lacks, so the baseline of 3 applies. It also lists styles without harvard, which the schema accepts, though the schema still covers 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?
Opens with a specific verb and resource: fetch a web page and format it as a website citation in four named styles. The 'web page' framing implicitly separates it from the DOI/ISBN siblings, but no sibling is ever named, so the distinction is left for the agent to infer.
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 example prompt ('Cite this page in APA: https://example.edu/study') gives a concrete usage scenario, which is more than nothing. However, there is no explicit statement of when to prefer this over cite_from_doi, cite_from_isbn, or format_citation, and no preconditions or failure cases are noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Crossref for the DOI of a paper or a book when you have its title but no DOI. Returns the best matches, 5 by default, each with its title, authors, year, container and DOI, so you can pick the right one and pass the DOI to cite_from_doi. Inputs: title (the title, or as much of it as you know), optional author (a family name to narrow the search) and optional limit (1 to 10 matches). Example prompt: "Find the DOI for the paper Deep learning by LeCun."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many matches to return, 1 to 10. | |
| title | Yes | The title of the paper or book, or as much of it as you know. | |
| author | No | An author's family name, to narrow the search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds real value: the data source (Crossref), the default result count of 5, and the returned fields (title, authors, year, container, DOI). It doesn't mention fuzzy-match behavior for partial titles beyond implying it, which keeps it just below a 5.
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?
Front-loaded with purpose then return shape then inputs, with zero filler. The example-prompt sentence is a nice addition but slightly redundant given the rest of the text.
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 no output schema, the description correctly compensates by enumerating the returned fields and default result count. Combined with the source and next-step tool, an agent has everything needed to call it and use the result.
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 100%, so all three parameters are already documented with matching wording ("family name", "as much of it as you know", limit 1-10). The description largely restates the schema rather than adding new syntax or edge-case guidance, so the baseline 3 applies.
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?
States a specific verb and resource ("Search Crossref for the DOI") and names the input precondition (title but no DOI). It also distinguishes itself from sibling cite_from_doi by positioning this tool as the lookup step that feeds that one.
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?
Gives a clear trigger condition ("when you have its title but no DOI") and routes downstream to cite_from_doi. It does not explicitly contrast with cite_from_url or cite_from_isbn, so the agent must infer that those handle non-title identifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format several sources at once as one works cited list, alphabetised by the first author's family name in APA 7, MLA 9 or Chicago author date, or numbered in citation order in IEEE. A source with no author is alphabetised by its title. Inputs: sources (an array of objects, each with the same fields as format_citation: type, title and optional authors, year, container, publisher, city, edition, editors, translators, volume, issue, pages, doi, url, date_text, accessed, institution, degree, repository and report_number), dois (a list of DOIs to look up on Crossref), isbns (a list of ISBNs to look up on Open Library), urls (a list of web addresses to fetch and cite as websites) and style (apa7, mla9, chicago-ad or ieee). Give sources, dois, isbns, urls or any mix, up to 50 lookups in one call. If one lookup fails the reply is an error that names it. Example prompt: "Put these three sources into an APA works cited list: a journal article by Smith and Jones from 2020, a book by Cormen from 2009 and a website from example.edu."
| Name | Required | Description | Default |
|---|---|---|---|
| dois | No | DOIs to look up on Crossref and add to the list, each one a DOI like 10.1038/nature14539 or a doi.org link. | |
| urls | No | Web addresses to fetch and add to the list as websites. Each one a full URL like https://example.edu/study. | |
| isbns | No | ISBNs to look up on Open Library and add to the list as books. Dashes are fine. | |
| style | No | Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee. | apa7 |
| sources | No | The sources for the list. Each one takes the same fields as format_citation, so a journal article, a book, a website, a chapter, a thesis, a report, a dataset and a preprint can share one list. Optional when you give dois, isbns or urls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly and openWorld; the description adds real behavioral detail beyond that: alphabetisation by first author's family name, title-based ordering when no author exists, IEEE numbering by citation order, and the all-or-nothing error behaviour when any single lookup fails. These are exactly the traits an agent needs before committing 50 lookups to one call.
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 core behaviour and per-style ordering rules are front-loaded, and the ending example prompt is useful. The long enumeration of nested source fields largely repeats the schema and is the one portion that does not earn its space.
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 no output schema, the description still covers the important return behaviour (a failed lookup yields an error naming it), plus input mixing rules and the lookup cap. It also states prerequisites implicitly via 'required for a journal article and chapter' container notes in schema, so nothing an agent needs to call it correctly is 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 100%, so every parameter and nested field is already documented, making 3 the baseline. The description adds only marginal meaning (that the source object mirrors format_citation and that doi/isbn/url lists are looked up remotely), and it lists style values without mentioning harvard, which the schema accepts.
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?
Opens with a specific verb and resource ('Format several sources at once as one works cited list') and immediately names the sorting rules per style, which separates it from the single-item sibling format_citation. An agent can tell from the first sentence that this is the batch/list tool.
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 that sources, dois, isbns, urls or any mix are acceptable, caps it at 50 lookups per call, and gives a worked example prompt. It stops short of telling the agent when to prefer format_citation or cite_from_doi over this tool, so no true exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format a journal article, book, website, book chapter, thesis, report, dataset or preprint as a citation in APA 7, MLA 9, Chicago author date or IEEE, from details you provide. Inputs: type (journal, book, website, chapter, thesis, report, dataset or preprint), title, and optional authors (family plus given names), year, container, publisher, city, edition, editors, translators, volume, issue, pages, doi, url, date_text, accessed, institution, degree, repository, report_number and style (apa7, mla9, chicago-ad, ieee or all). Pass all to get all three styles in one reply, each one with its style name on the line above it. Editors and translators are for books and take the same shape as authors: a book with editors and no authors puts the editors where the author goes, and a book with authors too carries the other names after the title, in the spot each style uses. Example prompt: "Cite this journal article in APA 7: Learning to learn by John Kenneth Smith and Alice Jones, 2020, Journal of Study Skills, volume 4, issue 2, pages 11-25."
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | ||
| url | No | ||
| city | No | Publisher city, used by Chicago for books. | |
| type | Yes | ||
| year | No | ||
| issue | No | ||
| pages | No | For example "11-25". | |
| style | No | Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee, or all to get APA 7, MLA 9 and Chicago author date in one reply with a label above each one. | apa7 |
| title | Yes | ||
| degree | No | The degree of a thesis, like "Ph.D.". | |
| volume | No | ||
| authors | No | ||
| edition | No | For example "2nd". | |
| editors | No | Editors of a book or a chapter, same shape as authors. When a book has editors and no authors, they take the author's place in the citation. | |
| accessed | No | MLA access date, like "14 Oct. 2026". | |
| container | No | Journal name, the book title for a chapter, or website name. Required for a journal article and for a chapter, since without it the citation would be missing the work it appears in. | |
| date_text | No | Website date as you want it shown, like "2026, October 14" for APA or "14 Oct. 2026" for MLA. | |
| publisher | No | ||
| repository | No | Where a preprint was posted, like arXiv. | |
| institution | No | The university or organisation behind a thesis, a report or a dataset. | |
| translators | No | Translators of a book, same shape as authors. | |
| report_number | No | The number of a report or a standard. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds real behavioral detail: 'Pass all to get all three styles in one reply, each one with its style name on the line above it' discloses the output shape, and the editors/translators placement rule explains non-obvious formatting behavior. Minor inconsistency remains: it lists four styles up front but says 'all' returns three, which could confuse an agent about what 'all' covers.
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 purpose and inputs are front-loaded and the example prompt is useful, but the paragraph is dense and the editors/translators sentence is convoluted. The 'all three styles' restatement duplicates the style parameter's own schema description rather than earning new space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 22-parameter tool with no output schema, the description covers the input vocabulary, the multi-style return format, and the trickiest author/editor interaction, which is nearly enough to call it correctly. It stops short of saying which fields each source type actually needs beyond the container note, leaving type-specific requirements partly implicit.
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 only 59% schema coverage, the description compensates by naming nearly every parameter and glossing its meaning (authors as family plus given names, container, year, edition, etc.), plus a substantive rule about how editors and translators map into the citation when authors are present or absent. A few parameters (doi, url, volume, issue) are named without added semantics, keeping it below 5.
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?
States a specific verb (format) and resource (a citation), enumerates the supported source types and the four styles, so the tool's job is unmistakable. It only hints at the sibling distinction via 'from details you provide' rather than naming cite_from_doi/cite_from_url/cite_from_isbn as the identifier-based alternatives.
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?
'from details you provide' implies the manual-entry case versus the identifier-driven siblings, and the example prompt shows a realistic invocation. But there is no explicit when-not guidance or naming of the alternatives, so an agent must infer the routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The in text citation that goes with a source, with an optional page number and an optional narrative form for a sentence where the author is named. Give authors and year, or a doi or an isbn and the record fills them in. Inputs: authors (family name plus optional given names), year, doi, isbn, page, form (parenthetical or narrative) and style (apa7, mla9, chicago-ad or ieee). A doi or an isbn cannot be combined with the other one. Example prompt: "Give the APA in text citation for Smith and Jones 2020 on page 14."
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | A DOI like 10.1038/nature14539, or a doi.org link. The lookup fills in the authors and the year. | |
| form | No | parenthetical is the usual brackets, like (Smith & Jones, 2020, p. 14). narrative puts the author in your sentence and keeps the rest in brackets, like Smith and Jones (2020, p. 14). | parenthetical |
| isbn | No | A 10 or 13 digit ISBN. Dashes are fine. The lookup fills in the authors and the year. | |
| page | No | ||
| year | No | ||
| style | No | Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee. | apa7 |
| authors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only and open-world behavior, and the description adds meaningful context: DOI/ISBN lookup fills in authors and year, and DOI and ISBN are mutually exclusive. It still does not describe the return format or lookup failure behavior, so it is strong but not exhaustive.
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 front-loaded and reasonably sized, with the purpose and key behavior stated first and an example at the end. The explicit input list partly repeats the schema, but it earns its place by adding meaning such as author formatting and style aliases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a seven-parameter citation generator with no output schema and many sibling tools, the description covers inputs, styles, form, and the DOI/ISBN exclusivity constraint. It omits explicit sibling routing and does not state what the return value looks like, leaving meaningful gaps for an agent selecting among citation tools.
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 57% schema description coverage, the description meaningfully supplements the schema by explaining author family/given names, parenthetical versus narrative form, accepted styles, and DOI/ISBN lookup behavior. Parameter names page and year remain unexplained beyond their names, but the overall semantic coverage is good.
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 identifies a specific output, an in-text citation, and adds the optional page number and narrative form. It is clear enough to distinguish the tool from a bibliography generator, but it never explicitly names or contrasts itself with siblings such as format_citation, so it falls 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that the user can provide authors and year, or a DOI or ISBN, and that DOI and ISBN cannot be combined, plus gives an example prompt. However, it does not say when to choose this tool over format_citation, format_bibliography, cite_from_doi, or cite_from_isbn, so usage guidance is implied rather than explicit.
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.1.6cite_from_doi1 field changedInput schema / properties / style / descriptionPrevious value: -"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date)."New value: +"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee, or all to get APA 7, MLA 9 and Chicago author date in one reply with a label above each one."cite_from_isbn1 field changedInput schema / properties / style / descriptionPrevious value: -"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date)."New value: +"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee."cite_from_urlfind_doiformat_bibliography8 fields changedInput schema / properties / doisAdded value: +{
+ "default": [],
+ "description": "DOIs to look up on Crossref and add to the list, each one a DOI like 10.1038/nature14539 or a doi.org link.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / isbnsAdded value: +{
+ "default": [],
+ "description": "ISBNs to look up on Open Library and add to the list as books. Dashes are fine.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / sources / defaultAdded value: +[]Input schema / properties / sources / descriptionPrevious value: -"The sources for the list. Each one takes the same fields as format_citation, so a journal article, a book, a website, a chapter, a thesis, a report, a dataset and a preprint can share one list."New value: +"The sources for the list. Each one takes the same fields as format_citation, so a journal article, a book, a website, a chapter, a thesis, a report, a dataset and a preprint can share one list. Optional when you give dois, isbns or urls."Input schema / properties / sources / items / properties / container / descriptionPrevious value: -"Journal name, the book title for a chapter, or website name."New value: +"Journal name, the book title for a chapter, or website name. Required for a journal article and for a chapter, since without it the citation would be missing the work it appears in."Input schema / properties / style / descriptionPrevious value: -"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date)."New value: +"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee."Input schema / properties / urlsAdded value: +{
+ "default": [],
+ "description": "Web addresses to fetch and add to the list as websites. Each one a full URL like https://example.edu/study.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / requiredRemoved value: -[
- "sources"
-]format_citation2 fields changedInput schema / properties / container / descriptionPrevious value: -"Journal name, the book title for a chapter, or website name."New value: +"Journal name, the book title for a chapter, or website name. Required for a journal article and for a chapter, since without it the citation would be missing the work it appears in."Input schema / properties / style / descriptionPrevious value: -"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date)."New value: +"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee, or all to get APA 7, MLA 9 and Chicago author date in one reply with a label above each one."in_text_citation1 field changedInput schema / properties / style / descriptionPrevious value: -"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date)."New value: +"Citation style. Aliases such as APA, MLA 9 and Chicago are accepted. Valid styles: apa7, mla9, chicago-ad (Chicago author date), harvard and ieee."v0.1.3cite_from_doicite_from_isbnformat_bibliographyformat_citationin_text_citationScored across 7 tools
Most tools have clearly distinct roles: manual formatting, batch bibliography, identifier lookups, DOI discovery, URL citation, ISBN citation, and in-text citation. There is some overlap because format_bibliography can batch what cite_from_doi/cite_from_isbn/cite_from_url do individually, and format_citation can format from details that overlap with the specialized cite tools, but descriptions mostly disambiguate.
All names use snake_case, and most follow a verb_noun or verb_from_noun pattern such as format_citation, format_bibliography, cite_from_doi, cite_from_url, cite_from_isbn, and find_doi. in_text_citation is a noun phrase rather than a verb-led name, a minor deviation that remains readable.
Seven tools is well-scoped for a citation-formatting server. Each tool supports a distinct workflow: single citation formatting, batch bibliography generation, DOI/ISBN/URL lookup-and-cite flows, DOI discovery, and in-text citations.
The set covers manual citation formatting, batch bibliographies, DOI/ISBN/URL lookup-based citations, DOI discovery by title, and in-text citations, which covers the core citation lifecycle. Minor gaps include no BibTeX/RIS export and no title-based book lookup when an ISBN is unknown, but these are workable gaps rather than dead ends.
DOIs and ISBNs to APA & MLA
Search research, revise drafts, format references and export your Citation documents.
Catch AI-fabricated citations (real DOI + fake title). Retraction, open-access, 10,000+ CSL styles.
Search papers, format citations in 60 styles, and verify bibliographies against scholarly sources.
