A
licenseB
qualityD
maintenanceMCP server that enables searching books by author via Open Library API and searching keywords inside local text files.
2
326
MIT
mcp-databnf
by smeet666
The mcp-databnf server provides read-only access to the Bibliothèque nationale de France (BnF) open linked-data catalogue, with no API key or account required. It offers seven tools:
search_authors: Search for persons in the BnF authority file by name, returning identifiers, birth/death years, roles, and source URLs; helps distinguish homonyms.
get_author: Retrieve a detailed author record with biographical data (dates, places, occupation, languages, countries, fields of activity, Dewey classes) and external identifiers (VIAF, IdRef, DBpedia, Wikidata, ISNI).
search_works: Find works by words in the title, including creators, dates, and record status (established/provisional).
get_work: Access a work's full record: title, creators, date, language, forms, subjects, Dewey classes, and expression count.
list_works: List works attributed to a person, with title, date, form codes, and status.
list_editions: Discover published editions of a work with publisher, place, year, edition statement, extent, ISBN, catalogue link, and digitised-copy links where available.
find_digitised: Gather all digitised documents (reproductions, OCR texts, depictions) linked to a person or work, providing direct Gallica links.
All responses include retrieved_at timestamps for data provenance, and the server enforces polite usage (one request at a time, minimum intervals, caching) to respect BnF licensing and rate limits.
Click on "Install 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., "@mcp-databnfFind the author Marcel Proust and list his works"
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.
mcp-databnf
data.bnf.fr is the open data service of the Bibliothèque nationale de France. It publishes the authority records the national library maintains: the people it catalogues, with their dates, their places, their languages and their fields of activity; the works they wrote, with the editions each work was published in; and the links to the copies digitised in Gallica. A record states whether the library considers it established or still provisional.
This server connects a chat client to that service. You can search for an author or a work by name, read a record in full, list what an author wrote, list the editions of a work, and find the digitised copies attached to either. It needs no API key and no account.
Install
One-click install
Claude Code
claude mcp add databnf -- npx -y mcp-databnfClaude Desktop, Cursor, and any client using the standard config format
{
"mcpServers": {
"databnf": {
"command": "npx",
"args": ["-y", "mcp-databnf"]
}
}
}Node 24 or later is required, and no environment variable has to be set.
With Docker
{
"mcpServers": {
"databnf": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-databnf:2.1.2"]
}
}
}-i keeps stdin open, which is where the protocol travels, and -t is left out
because a TTY rewrites the stream. The container needs outbound HTTPS to
data.bnf.fr, and nothing else: no volume, no port, no credential.
Bundle, without npm
Download mcp-databnf-2.1.2.mcpb from
the latest release and
open it. A client that supports MCP bundles installs it on its own, with no npm
and no configuration file to edit. The bundle carries its dependencies, so
nothing is fetched at install time.
Related MCP server: sru-mcp
What you can ask
« Que dit la BnF de Colette ? »
"List everything Marguerite Duras wrote."
"Which editions of that work does the library hold?"
"Are any of them digitised in Gallica?"
"When was that record last established?"
The ordinary path runs from a search to a record: a row carries an id, and
get_author or get_work reads it.
Tools
Tool | What it does |
| Finds people by name in the authority records. |
| Reads one person's record in full. |
| Finds works by title. |
| Reads one work's record in full. |
| Lists the works one person is credited with. |
| Lists the editions of one work. |
| Finds the copies digitised in Gallica for a person or a work. |
search_authors
Finds people by name in the authority records.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The name to look for. |
| integer, 1 to 50, default | no | Rows to serve. |
| integer, 1 to 100, default | no | Which page of rows. |
In return: authors, each carrying id, which get_author, list_works
and find_digitised take; name as the service writes it; label, the
authority heading, usually with the dates; birth_year and death_year, null
where the record states none; role; and source_url. words_searched says
what was actually sent, has_more whether further pages exist, and
index_window_full that the index served everything it will serve for this
search.
get_author
Reads one person's record in full.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The identifier a row carries. |
| boolean, default | no | Add the portraits the record points to. |
In return: the person with name, label, given_name, family_name,
other_names, birth_date and death_date as published, birth_year and
death_year as numbers, birth_place, death_place,
biographical_information, occupation, languages as ISO 639-2 codes,
countries and fields in the words of the record. A field the record leaves
empty is null.
search_works
Finds works by title.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The words of the title to look for. |
| integer, 1 to 50, default | no | Rows to serve. |
| integer, 1 to 100, default | no | Which page of rows. |
In return: works, each carrying id, which get_work, list_editions and
find_digitised take; title; date, the year the record gives the work, as
published; creators; status, reading established or provisional; and
source_url. The envelope carries the same words_searched, has_more and
index_window_full a search of people returns.
get_work
Reads one work's record in full.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The identifier a row carries. |
| boolean, default | no | Add the illustrations the record points to. |
In return: the work with title, label, date as published, first_year,
creators as { id, name }, languages, forms, subjects and
dewey_classes in the words of the record, expression_count, same_as for the
registers the BnF aligns it with, and catalogue_url. status reads
established or provisional, and status_statement says what the library
means by it: a provisional record is one the library has not finished checking.
list_works
Lists the works one person is credited with.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The person's identifier. |
| integer, 1 to 50, default | no | Rows to serve. |
| integer, 1 to 100, default | no | Which page of rows. |
In return: works, each carrying id, title, date as published, year
as a number where the record has one, forms, status and source_url, with
has_more to continue.
list_editions
Lists the editions of one work.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The work's identifier. |
| integer, 1 to 50, default | no | Rows to serve. |
| integer, 1 to 100, default | no | Which page of rows. |
In return: editions, each carrying its own id in the BnF catalogue, the
title this edition bears, date and year, publisher, place,
edition_statement, extent, isbn, note as the cataloguer wrote it,
catalogue_url, digitised and source_url. A field the record leaves empty is
null.
find_digitised
Finds the copies digitised in Gallica attached to a person or a work.
Argument | Type | Required | What it does |
| string, 1 to 200 characters | yes | The identifier of a person or of a work. |
|
| no | What the identifier stands for. |
| integer, 1 to 200, default | no | Links to serve. |
In return: kind, saying what the catalogue types the record as, and links,
each carrying the Gallica ark, its url, its rendering and the role the
person holds on it. links_returned_by_role counts them per role. This server
describes a digitised document and never opens one.
Established and provisional records
A record carries a status. established means the library has checked it;
provisional means it has not finished, and status_statement says so in the
library's own words. Report the status alongside anything taken from a
provisional record.
The licence, and what it asks
The BnF states one condition on these metadata:
L'utilisation de ces métadonnées est libre et gratuite sous réserve du maintien de la mention de leur source et de l'indication de leur date de récupération.
Use is free of charge, provided the source is named and the date of retrieval is
stated. Every answer carries retrieved_at in its payload and ends its text with
the source and that date. A cached answer reports the moment it was originally
read, since that is when it was retrieved. Repeat both wherever what you got is
shown.
Configuration
Every variable is optional. Set them in the env block of your client config.
Variable | Default | What it does |
| the project identity | Names your application to the BnF, with an address where a person can be reached. |
|
| Gap between two requests, from 3000 to 120000. |
|
| Deadline for one request, from 1000 to 300000. |
|
| Attempts after a transient failure, from 0 to 8. |
|
| How long an answer stays in memory, from 0 to 86400000. |
|
| Answers held in memory at once, from 1 to 5000. |
|
|
|
A value outside its range falls back to the default, and the reason is written to stderr.
Errors
Every failure carries one of six codes, a message, and where it helps a hint naming the next move.
Code | What happened | What to do |
| The service answered, and holds no such record. | Check the identifier with |
| The arguments were refused before any request went out. | Read the message, which names the argument. |
| The service asked this client to slow down. | Wait the number of seconds the hint names and call again with the same arguments. The record is still there. |
| The answer arrived in a shape this client cannot read. | Report it at the issue tracker. |
| The request did not complete. | Try again shortly. |
| The request passed its deadline. | Raise |
As a library
The layer reading the service is published on its own, with its pacing, its cache and its errors, and with no protocol attached.
import { BnfClient } from "mcp-databnf/client";
const client = new BnfClient();
const { data, cached } = await client.getAuthor("cb11907966z");
console.log(data.label, cached);getAuthor and getWork each answer { data, cached }, and throw an error
carrying one of the six codes. The three-second floor between two requests holds
here as well.
Pacing and attribution
Requests go out one at a time with at least three seconds between them, and that
floor holds however the server is configured. Each question is answered by a
SPARQL query against a public endpoint the BnF runs at its own expense, which is
why the interval is wide and the deadline long. The User-Agent always ends with
the project identity and an address where a person can be reached.
Every answer carries the source and retrieved_at, which the licence asks to be
stated wherever the metadata are shown.
This MCP server is an unofficial project, with no affiliation to the Bibliothèque nationale de France.
Privacy
This server collects nothing about you and sends nothing to its author. It runs
on your machine, contacts data.bnf.fr and nothing else, holds its answers in memory
while it runs, and writes nothing to disk.
PRIVACY.md states what a request carries and which settings change
any of it.
Development
npm install
npm run build:fixtures
npm test
npm run checkTests run against generated fixtures and make no network request. The live suite,
npm run test:live, makes one request per route and runs nightly against the
service itself.
Contributing
Bugs, questions and ideas belong in the issue tracker. Pull requests are welcome; opening an issue first helps agree on the shape of the change. See CONTRIBUTING.md.
License
MIT, see LICENSE. The metadata belong to the Bibliothèque nationale de France, free to use provided the source and the date of retrieval are stated.
mcp-databnf (français)
data.bnf.fr est le service de données ouvertes de la Bibliothèque nationale de France. Il publie les notices d'autorité que la bibliothèque nationale entretient : les personnes qu'elle catalogue, avec leurs dates, leurs lieux, leurs langues et leurs domaines d'activité ; les œuvres qu'elles ont écrites, avec les éditions dans lesquelles chaque œuvre a paru ; et les liens vers les exemplaires numérisés dans Gallica. Une notice indique si la bibliothèque la tient pour établie ou encore provisoire.
Ce serveur relie un client de conversation à ce service. On peut y chercher un auteur ou une œuvre par son nom, lire une notice en entier, lister ce qu'un auteur a écrit, lister les éditions d'une œuvre, et trouver les exemplaires numérisés attachés à l'un ou l'autre. Aucune clé d'API, aucun compte.
Installation
Installation en un clic
Claude Code
claude mcp add databnf -- npx -y mcp-databnfClaude Desktop, Cursor, et tout client au format de configuration standard
{
"mcpServers": {
"databnf": {
"command": "npx",
"args": ["-y", "mcp-databnf"]
}
}
}Node 24 ou plus récent est nécessaire, et aucune variable d'environnement n'est à renseigner.
Avec Docker
{
"mcpServers": {
"databnf": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-databnf:2.1.2"]
}
}
}-i garde l'entrée standard ouverte, qui est le canal du protocole, et -t est
omis parce qu'un TTY réécrit le flux. Le conteneur a besoin d'un accès HTTPS
sortant vers data.bnf.fr, et de rien d'autre : aucun volume, aucun port, aucun
identifiant.
Bundle, sans npm
Téléchargez mcp-databnf-2.1.2.mcpb depuis
la dernière publication
et ouvrez-le. Un client qui gère les bundles MCP l'installe seul, sans npm et
sans fichier de configuration à modifier. Le bundle emporte ses dépendances, donc
rien n'est téléchargé à l'installation.
Ce qu'on peut demander
« Que dit la BnF de Colette ? »
« Liste tout ce qu'a écrit Marguerite Duras. »
« Quelles éditions de cette œuvre la bibliothèque conserve-t-elle ? »
« Y en a-t-il de numérisées dans Gallica ? »
« Cette notice est-elle établie ou provisoire ? »
Le chemin ordinaire va d'une recherche à une notice : une ligne porte un id, et
get_author ou get_work la lit.
Les outils
Outil | Ce qu'il fait |
| Trouve des personnes par leur nom dans les notices d'autorité. |
| Lit la notice d'une personne en entier. |
| Trouve des œuvres par leur titre. |
| Lit la notice d'une œuvre en entier. |
| Liste les œuvres attribuées à une personne. |
| Liste les éditions d'une œuvre. |
| Trouve les exemplaires numérisés dans Gallica d'une personne ou d'une œuvre. |
search_authors
Trouve des personnes par leur nom dans les notices d'autorité.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | Le nom cherché. |
| entier, 1 à 50, défaut | non | Lignes à servir. |
| entier, 1 à 100, défaut | non | Quelle page de lignes. |
En retour : authors, chacun portant id, que get_author, list_works et
find_digitised reprennent ; name tel que le service l'écrit ; label, la
vedette d'autorité, généralement avec les dates ; birth_year et death_year,
null là où la notice n'en indique pas ; role ; et source_url.
words_searched dit ce qui a réellement été envoyé, has_more s'il existe
d'autres pages, et index_window_full que l'index a servi tout ce qu'il servira
pour cette recherche.
get_author
Lit la notice d'une personne en entier.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | L'identifiant que porte une ligne. |
| booléen, défaut | non | Ajoute les portraits vers lesquels la notice pointe. |
En retour : la personne avec name, label, given_name, family_name,
other_names, birth_date et death_date tels que publiés, birth_year et
death_year en nombres, birth_place, death_place,
biographical_information, occupation, languages en codes ISO 639-2,
countries et fields dans les mots de la notice. Un champ que la notice laisse
vide vaut null.
search_works
Trouve des œuvres par leur titre.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | Les mots du titre cherché. |
| entier, 1 à 50, défaut | non | Lignes à servir. |
| entier, 1 à 100, défaut | non | Quelle page de lignes. |
En retour : works, chacune portant id, que get_work, list_editions et
find_digitised reprennent ; title ; date, l'année que la notice donne à
l'œuvre, telle que publiée ; creators ; status, valant established ou
provisional ; et source_url. L'enveloppe porte les mêmes words_searched,
has_more et index_window_full qu'une recherche de personnes.
get_work
Lit la notice d'une œuvre en entier.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | L'identifiant que porte une ligne. |
| booléen, défaut | non | Ajoute les illustrations vers lesquelles la notice pointe. |
En retour : l'œuvre avec title, label, date telle que publiée,
first_year, creators en { id, name }, languages, forms, subjects et
dewey_classes dans les mots de la notice, expression_count, same_as pour
les registres auxquels la BnF l'aligne, et catalogue_url. status vaut
established ou provisional, et status_statement dit ce que la bibliothèque
entend par là : une notice provisoire est une notice qu'elle n'a pas fini de
vérifier.
list_works
Liste les œuvres attribuées à une personne.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | L'identifiant de la personne. |
| entier, 1 à 50, défaut | non | Lignes à servir. |
| entier, 1 à 100, défaut | non | Quelle page de lignes. |
En retour : works, chacune portant id, title, date telle que publiée,
year en nombre quand la notice en a un, forms, status et source_url, avec
has_more pour poursuivre.
list_editions
Liste les éditions d'une œuvre.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | L'identifiant de l'œuvre. |
| entier, 1 à 50, défaut | non | Lignes à servir. |
| entier, 1 à 100, défaut | non | Quelle page de lignes. |
En retour : editions, chacune portant son propre id au catalogue de la
BnF, le title que cette édition porte, date et year, publisher, place,
edition_statement, extent, isbn, note telle que le catalogueur l'a
écrite, catalogue_url, digitised et source_url. Un champ que la notice
laisse vide vaut null.
find_digitised
Trouve les exemplaires numérisés dans Gallica attachés à une personne ou à une œuvre.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 200 caractères | oui | L'identifiant d'une personne ou d'une œuvre. |
|
| non | Ce que l'identifiant désigne. |
| entier, 1 à 200, défaut | non | Liens à servir. |
En retour : kind, qui dit de quel type le catalogue tient la notice, et
links, chacun portant l'ark Gallica, son url, son rendering et le role
que la personne y tient. links_returned_by_role les compte par rôle. Ce serveur
décrit un document numérisé et n'en ouvre jamais aucun.
Notices établies et provisoires
Une notice porte un status. established signifie que la bibliothèque l'a
vérifiée ; provisional qu'elle ne l'a pas terminée, et status_statement le
dit dans ses propres mots. Rapportez ce statut à côté de tout ce qui vient d'une
notice provisoire.
La licence, et ce qu'elle demande
La BnF pose une condition sur ces métadonnées :
L'utilisation de ces métadonnées est libre et gratuite sous réserve du maintien de la mention de leur source et de l'indication de leur date de récupération.
Chaque réponse porte retrieved_at dans sa charge utile et termine son texte par
la source et cette date. Une réponse servie depuis le cache rapporte le moment où
elle a été lue à l'origine, puisque c'est sa date de récupération. Redonnez les
deux partout où ce que vous avez obtenu est montré.
Configuration
Chaque variable est facultative. Elles se posent dans le bloc env de la
configuration du client.
Variable | Défaut | Ce qu'elle fait |
| l'identité du projet | Nomme votre application auprès de la BnF, avec une adresse où joindre une personne. |
|
| Écart entre deux requêtes, de 3000 à 120000. |
|
| Délai d'une requête, de 1000 à 300000. |
|
| Tentatives après un échec passager, de 0 à 8. |
|
| Durée pendant laquelle une réponse reste en mémoire, de 0 à 86400000. |
|
| Réponses gardées en mémoire à la fois, de 1 à 5000. |
|
|
|
Une valeur hors de sa plage retombe sur le défaut, et la raison est écrite sur la sortie d'erreur.
Erreurs
Chaque échec porte un des six codes, un message, et quand cela aide une indication du geste suivant.
Code | Ce qui s'est passé | Que faire |
| Le service a répondu, et n'a pas cette notice. | Vérifiez l'identifiant avec |
| Les arguments ont été refusés avant toute requête. | Lisez le message, qui nomme l'argument. |
| Le service demande à ce client de ralentir. | Attendez les secondes indiquées et rappelez avec les mêmes arguments. La notice est toujours là. |
| La réponse est arrivée dans une forme illisible ici. | Signalez-le sur le suivi d'incidents. |
| La requête n'a pas abouti. | Réessayez sous peu. |
| La requête a dépassé son délai. | Augmentez |
Comme bibliothèque
La couche qui lit le service est publiée seule, avec son rythme, son cache et ses erreurs, sans protocole attaché.
import { BnfClient } from "mcp-databnf/client";
const client = new BnfClient();
const { data, cached } = await client.getAuthor("cb11907966z");
console.log(data.label, cached);getAuthor et getWork répondent chacun { data, cached }, et lèvent une
erreur portant un des six codes. Le plancher de trois secondes entre deux
requêtes tient également ici.
Rythme et attribution
Les requêtes partent une à une avec au moins trois secondes entre elles, et ce
plancher tient quelle que soit la configuration. Chaque question se résout par
une requête SPARQL contre un point d'accès public que la BnF fait tourner à ses
frais, d'où un intervalle large et un délai long. Le User-Agent se termine
toujours par l'identité du projet et une adresse où joindre une personne.
Chaque réponse porte la source et retrieved_at, que la licence demande
d'indiquer partout où les métadonnées sont montrées.
Ce MCP est un projet non officiel, sans affiliation à la Bibliothèque nationale de France.
Confidentialité
Ce serveur ne collecte rien sur vous et n'envoie rien à son auteur. Il tourne sur
votre machine, ne joint que data.bnf.fr, garde ses réponses en mémoire le temps qu'il
tourne, et n'écrit rien sur le disque. PRIVACY.md dit ce qu'une
requête emporte et quels réglages changent cela.
Développement
npm install
npm run build:fixtures
npm test
npm run checkLes tests s'exécutent sur des fixtures engendrées et n'émettent aucune requête.
La suite en direct, npm run test:live, émet une requête par route et tourne
chaque nuit contre le service lui-même.
Contribuer
Les anomalies, les questions et les idées ont leur place dans le suivi d'incidents. Les propositions de modification sont bienvenues ; ouvrir un ticket d'abord aide à s'accorder sur la forme du changement. Voir CONTRIBUTING.md.
Licence
MIT, voir LICENSE. Les métadonnées appartiennent à la Bibliothèque nationale de France, d'usage libre sous réserve d'indiquer la source et la date de récupération.
Available Tools
7 toolsfind_digitisedGather the digitised documents attached to a recordARead-onlyIdempotent
Gather the digitised documents the Bibliothèque nationale de France catalogue attaches to one person or one work, and return them as links. Give the identifier of either; the tool asks the catalogue what kind of record it is and follows the right path. For a work it walks the editions; for a person it takes the images on the record and the digitised editions of the works they are credited with. The 'kind' returned is what the catalogue types the record as. Every result is a link for someone to open. This server reads the BnF catalogue and never requests gallica.bnf.fr, so it reports nothing about what is at the other end: not whether the document opens, not what it contains, not on what terms it may be reused. It returns links and nothing else: no publisher, no date, no ISBN. Use list_editions when which edition a copy belongs to matters. A 'depiction' illustrates a record and can be a page that merely mentions the subject. A 'reproduction' is an edition digitised. An 'ocr' link names a machine-read text of a document, which this server does not fetch.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A person or work identifier, such as 'cb119219976' or 'cb11970626n'. The argument is named 'id' rather than 'work_id' or 'author_id' because it takes either. | |
| kind | No | What you expect the identifier to name. The catalogue is asked either way, and a kind it contradicts is refused rather than followed. 'auto' states no expectation. | auto |
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | Yes | What the catalogue types this record as. |
| links | Yes | |
| notes | Yes | |
| has_more | Yes | |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
| links_returned_by_role | Yes | How many of the links in this answer carry each role. These count the links returned here, which is neither a count of documents nor a count of what the catalogue attaches: several links can name one document, and 'has_more' says when links were left out. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that the server never requests gallica.bnf.fr, does not report whether documents open, what they contain, or reuse terms. It also clarifies the semantic differences between depiction, reproduction, and ocr links, which is beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but every sentence serves a distinct purpose: establishing the core action, explaining mechanics, stating limitations, contrasting with a sibling, and defining link types. It is well-structured and free of filler, though it could be tightened by merging some related statements.
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?
With annotations and an output schema, the description still adds substantial context: how it handles persons vs works, the role of the kind parameter, and the exact meaning of returned link types. It also covers limitations and alternative tools, leaving no significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers id and kind with descriptions; the description adds that id can be a person or work identifier and the tool auto-detects the record kind. It also explains what the returned 'kind' refers to. Limit is not mentioned, but defaults are straightforward and schema already includes constraints.
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 phrase: 'Gather the digitised documents the Bibliothèque nationale de France catalogue attaches to one person or one work, and return them as links.' It names the resource and distinguishes itself from siblings by essentially stating its purpose as returning links, while pointing to list_editions for edition-specific use.
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?
The description explicitly says 'Use list_editions when which edition a copy belongs to matters,' giving a clear alternative. It also states what the tool does not do (does not fetch or validate links), setting boundaries and preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_authorRead a person's recordARead-onlyIdempotent
Read one person's record in the Bibliothèque nationale de France authority file, by the identifier search_authors returns. It carries the dates and places of birth and death, the occupation the record names, the language and country it associates with the person, the field of activity with its Dewey class, and the addresses for the same person in VIAF, IdRef, DBpedia, Wikidata and ISNI. It carries no biography. The field the BnF calls biographical information is a job title on most records and a single word on many, so quote it as what the catalogue states and do not build a life story out of it. It lists no work. list_works walks from this record to the works the catalogue names the person the creator of, and states what that link does and does not reach. 'depictions' are images data.bnf.fr attaches to the person. They are links for a person to open; this server does not read them, and an image can be a page that mentions the person rather than a portrait of them.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| author_id | Yes | The identifier from search_authors, such as 'cb119219976'. A full data.bnf.fr address is accepted too. | |
| include_depictions | No | Include the images data.bnf.fr attaches to the person. A well-known person can carry dozens, so they are left out by default. find_digitised gathers them with everything else. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| author | Yes | |
| depictions | No | |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
| depiction_count | Yes | Images on Gallica that the record points at, counted whether or not they were returned. An illustration the record holds elsewhere is not counted, because this server describes Gallica documents and knows nothing about the others. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, non-destructive), the description reveals important behavioral caveats: the 'biographical information' is usually just a job title, depictions are external links not images, and the server does not read them. This adds significant value beyond the structured annotations.
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 long but every sentence earns its place: it lists carried fields, explicit omissions, cautions, and alternatives. It is well-structured, front-loading the core action before caveats, and remains focused despite its length.
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?
Given the output schema handles return values, the description fully covers the tool's operational context: what data is included/excluded, how to interpret ambiguous fields, the nature of depictions, and how the record relates to other tools. It is complete for this read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description enriches both parameters: author_id is tied to search_authors, and include_depictions is explained with ambiguity about what depictions represent. This adds useful context, though the schema already provides strong descriptions.
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 clearly states the tool reads one person's record in a specific authority file, using a specific identifier. It also distinguishes itself from sibling tools by explicitly stating it lists no works and that list_works should be used for that purpose.
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?
The description provides explicit when-to-use context (after search_authors returns an identifier), what the record includes and excludes, and names alternatives like list_works for works and find_digitised for broader image gathering. This is strong guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_workRead a work's recordARead-onlyIdempotent
Read one work's record in the Bibliothèque nationale de France catalogue, by the identifier search_works returns. It carries the title, everyone the record credits, the date the BnF gives the work, its language, its form and its subject with the Dewey class. 'forms' holds the work-form vocabulary's own terms, which carry no label in this dataset, so some read as words and some do not. A record stating none has a form the catalogue does not state. 'status' says whether the record is established or provisional, and 'status_statement' repeats what the catalogue itself states. A provisional identifier can change, so cite an established one where there is a choice. 'expression_count' counts the expressions the record links, which is not a count of published editions: use list_editions for those.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | The identifier from search_works, such as 'cb11970626n' or 'temp-work/22d7f68c1a4bdd081ad7ca791fd3b730'. | |
| include_depictions | No | Include the images data.bnf.fr attaches to the work. A well-known work can carry dozens, so they are left out by default. find_digitised gathers them alongside the digitised editions. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| work | Yes | |
| notes | Yes | |
| depictions | No | |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
| depiction_count | Yes | Images on Gallica that the record points at, counted whether or not they were returned. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by clarifying nuances: forms use a vocabulary with no labels, status indicates provisional vs established, and expression_count does not equal edition count. It also explains the default behavior of include_depictions (left out due to large payloads) and points to find_digitised for images alongside digitised editions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes either to scope, field semantics, or usage caveats. Some phrasing, like 'A record stating none has a form the catalogue does not state,' is awkward but not confusing. It is front-loaded with the purpose and then details.
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?
Given the rich schema and output schema, the description provides enough context for an agent to understand the tool's purpose, its data semantics, and its relationship to sibling tools. It covers the main caveats (provisional IDs, form labels, edition count distinction) and is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (100% coverage). The description reinforces the identifier's origin from search_works and adds guidance about preferring established identifiers, which supplements the schema's example. It does not discuss include_depictions separately since the schema covers it well.
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 clearly states the tool's purpose: 'Read one work's record in the Bibliothèque nationale de France catalogue, by the identifier search_works returns.' It specifies the verb (read), resource (work's record), and source (BnF). It also distinguishes from siblings by explicitly directing users to list_editions for edition counts.
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?
The description explains that the identifier comes from search_works, implying a search-then-read workflow. It also warns that provisional identifiers are changeable and recommends citing established ones, and explicitly says to use list_editions for published edition counts instead of this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_editionsList the editions of a workARead-onlyIdempotent
List the published editions of one work in the Bibliothèque nationale de France catalogue, by the identifier search_works or get_work returns. Each row carries the publisher, the place, the year, the edition statement, the extent in the words of the record, the ISBN when there is one, and the record in the BnF general catalogue. An edition that has been digitised carries a link under 'digitised'. That link says a copy exists at that address; this server never opens it, so it cannot say whether the document is readable, complete, or free to reuse. Rows are ordered by the address the catalogue gives each edition, which is neither by date nor by importance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| work_id | Yes | The work identifier, such as 'cb11970626n'. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| notes | Yes | |
| work_id | Yes | |
| editions | Yes | |
| has_more | Yes | |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
| digitised_count | Yes | Editions on this page carrying at least one link. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that digitised editions carry a link that is never opened by the server, so no guarantee is given about readability or reuse. It also reveals that rows are ordered by catalogue address rather than date or importance, which is non-obvious behavior.
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 a compact three sentences. It front-loads the core purpose, then efficiently details the row contents and important caveats without redundancy.
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 list-with-pagination tool, the description covers purpose, output fields, digitisation caveat, ordering, and identifier provenance. The existing annotations and output schema cover the remaining safety and return structure details, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that work_id is an identifier returned by search_works or get_work, giving it meaningful context beyond its schema description. However, page and limit are not mentioned in the description, leaving their semantics only in the schema; given the low schema coverage (33%), this is a gap.
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 clearly states a specific action: 'List the published editions of one work' in the BnF catalogue, and specifies the input identifier from search_works or get_work. This differentiates it from sibling tools that list or search for works.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It signals that the tool is appropriate when you already have a work identifier from search_works or get_work, and it describes what is returned. However, it does not explicitly mention when not to use it or list alternatives like find_digitised for digitised copies, so it has clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_worksList the works a person is credited withARead-onlyIdempotent
List the works the Bibliothèque nationale de France catalogue names one person the creator of, by the identifier search_authors returns. This is the tool for 'what did this person write'. Each row carries the title, the date the record gives the work, the form codes the catalogue points at, whether the record is established or provisional, and the identifier get_work, list_editions and find_digitised take. It is not a bibliography. It reports one link the catalogue holds, and the catalogue credits a person on a record in other ways and holds editions whose work it has never established, so a work missing here is not a work the person did not write. The form codes are the work-form vocabulary's own terms and carry no label in this dataset, so some read as words and some do not. A work stating no code has a form the catalogue does not state, so keeping the rows carrying one code finds the works that declare it and never all the works of that form. Rows are ordered by the address the catalogue gives each work, which is neither chronological nor an order of importance. No total is reported, because the catalogue counts nothing here and a count would read as a measure of what the person wrote.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| author_id | Yes | The person identifier from search_authors, such as 'cb119219976'. A full data.bnf.fr address is accepted too. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| notes | Yes | |
| works | Yes | |
| has_more | Yes | |
| author_id | Yes | |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses row ordering by 'address' not chronological, absence of a total count, that form codes carry no labels, and that only one catalogue link is reported. It also explains the open-world caveat that missing works do not mean the person didn't write them. This is thorough and adds substantial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with a clear purpose in the first sentence. Each subsequent sentence provides valuable caveats and behavioral details without repetition. While verbose, it earns its length through necessary nuance.
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?
Even with an output schema and annotations, the description explains row fields, ordering, open-world behavior, form code nuances, and the meaning of missing works. It leaves no major ambiguity about what the tool returns or its limitations, making it highly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes author_id adequately; the description merely restates it. With only 33% schema coverage, the description does not compensate for undocumented page/limit parameters, offering no pagination guidance or parameter-specific details. The added value is minimal.
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?
Clearly states it lists works a person is credited with, using a specific identifier from search_authors. Explicitly labeled as 'the tool for what did this person write' and distinguished from a bibliography. This separates it from sibling tools like list_editions and get_work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context: after search_authors, for finding what a person wrote. Mentions it is not a bibliography and cautions about open-world limitations. However, it does not explicitly name alternative tools or state when not to use it, relying instead on implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_authorsFind a person in the BnF authority fileARead-onlyIdempotent
Find a person in the Bibliothèque nationale de France authority file by name, and get the identifier the other tools take. This matches the name the BnF records, so it takes a surname, a full name or both names in either order. It does not read biographies, so it cannot find a person from what they wrote or what they did. It reads the person records and nothing else: an organisation, a conference or a place is outside it, and an answer holding no row says nothing about those. The match is letter for letter, so a name written with other accents or under another transliteration is a different search: try the spellings a library would use before concluding the BnF holds nobody of that name. Several rows can carry one name: the BnF keeps more than one authority record for some people, and many people share a name. Read 'birth_year', 'death_year' and 'role' to tell them apart, and show the caller the choice rather than picking one. Rows come back ordered by the address of the record, which is not an order of relevance. That order is the one the pages are cut along, so paging through a search reaches every match once. One search reads a fixed window of the index. 'index_window_full' says whether that window came back full: when it did, names sit past what was read, 'has_more' being false says where the reading stopped, and another reading of the same search can bring back other rows. Narrow the name to reach further.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's name, such as 'Rimbaud' or 'Arthur Rimbaud'. | |
| page | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | The name asked for. |
| page | Yes | |
| notes | Yes | |
| authors | Yes | |
| has_more | Yes | Whether the endpoint held at least one further row beyond this page, within the window the search read off the index. Read it alongside 'index_window_full': false on a full window says where the reading stopped rather than that the file holds nobody else. |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
| words_searched | Yes | The terms the index required, each of which has to appear in the name. A word is cut at an apostrophe and at a hyphen before the index sees it, so a name written as one word can appear here as two, and a record carrying the pieces apart is a match. |
| index_window_full | Yes | Whether the fixed window this search reads off the index came back full. True means records carrying these words sit past what was read, so the rows here are a part of the matches and another reading can bring back other rows. False means the window held everything that matched. Null when the endpoint stated no occupancy, which claims nothing either way. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent, destructive=false), the description discloses critical behavior: match is letter-for-letter, accents/transliterations matter, multiple records can share a name, results are ordered by record address (not relevance), and pagination behavior is explained via 'index_window_full' and 'has_more'. It even notes that another reading may yield different rows (open-world behavior consistent with the annotation). This far exceeds the baseline and provides rich, non-obvious context.
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 lengthy but every sentence adds a distinct, essential caveat—scope exclusions, exact matching, multiple records, ordering, pagination. It is front-loaded with purpose and then logically works through constraints. There is no redundancy or fluff; each sentence earns its place, making the length appropriate for the tool's complexity.
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?
Given the tool's complexity (fuzzy name matching, ambiguous results, paging quirks), the description covers all essential aspects: what the tool matches, what it excludes, how to disambiguate results ('birth_year', 'death_year', 'role'), how ordering works, and how to interpret pagination flags. An output schema exists, so field details are not required in the description, but the description still explains the meaning of key fields. This is a complete, self-contained guide for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only the `name` parameter (33% coverage), and the description compensates heavily for that by explaining accepted formats ('surname, a full name or both names in either order') and the exact matching behavior. For `page` and `limit`, it does not explicitly describe them, but it explains paging semantics ('paging through a search reaches every match once', 'One search reads a fixed window of the index') which indirectly informs how the parameters behave. Given the low schema coverage, this is a strong compensation, though the pagination parameters are not directly mapped to their fields.
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 and resource: 'Find a person in the Bibliothèque nationale de France authority file by name, and get the identifier the other tools take.' It clearly distinguishes from siblings by stating it only searches persons, not organisations, conferences, or places, and explicitly says it does not read biographies. This makes the tool's purpose unambiguous and sets it apart from similar tools like search_works.
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?
The description tells when to use the tool (to get an identifier for use with other tools) and when not to use it (not for biographies, not for non-persons). It provides actionable alternatives, such as trying different spellings or transliterations a library would use. It also advises the caller to present multiple matches to the user rather than auto-selecting, which is a clear usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_worksFind a work by its titleARead-onlyIdempotent
Find a work in the Bibliothèque nationale de France catalogue by words in its title, and get the identifier get_work and list_editions take. A row matches when its title carries every word given. The index returns no measure of how well a row matches, so the rows are ordered by the address of the record and the work a person would call the obvious answer can sit anywhere in the list or on a later page. A study of a book carries the book's title, so a search for a famous title returns the criticism alongside the work. Read 'creators' to tell them apart. This reads titles and nothing else. Searching a person's name returns the works written about them, whose creators are their critics; list_works is what walks from a person to the works the catalogue names them the creator of. 'status' says whether the BnF has established the work as a record of its own or holds it provisionally under a title it has catalogued. One search reads a fixed window of the index, and that window is read before the works are told apart from everything else the index holds, so even a short list can rest on a full one. 'index_window_full' says which: when it is true, titles sit past what was read, 'has_more' being false says where the reading stopped, and another reading of the same search can bring back other rows. Add a word to the title to reach further.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| title | Yes | Words from the title, such as 'saison enfer'. Every word given has to appear. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| notes | Yes | |
| title | Yes | The words asked for. |
| works | Yes | |
| has_more | Yes | Whether the endpoint held at least one further row beyond this page, within the window the search read off the index. Read it alongside 'index_window_full': false on a full window says where the reading stopped rather than that the catalogue holds nothing else. |
| retrieved_at | Yes | When these metadata were read from data.bnf.fr, as an ISO 8601 instant. The BnF licence asks for this date to be stated wherever the metadata are shown, so repeat it alongside the source. |
| words_searched | Yes | The terms the index required, each of which has to appear in the title. A word is cut at an apostrophe and at a hyphen before the index sees it, so a word given as one can appear here as two, and a record carrying the pieces apart is a match. |
| index_window_full | Yes | Whether the fixed window this search reads off the index came back full. The window is read before the works are separated from the rest of the index, so a short list can rest on a full window. True means titles carrying these words sit past what was read, and another reading can bring back other rows. False means the window held everything that matched. Null when the endpoint stated no occupancy. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnly, openWorld, idempotent, and non-destructive. The description goes far beyond this by disclosing that results are not relevance-ranked, are ordered by record address, may include criticism, and that pagination is tied to a fixed index window with 'has_more' and 'index_window_full' flags. This is rich behavioral context that annotations do not capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and every sentence adds meaningful nuance, but it is somewhat long and dense. It is logically structured and front-loaded with the core purpose, though the later sentences about index windows could be tightened without losing usefulness.
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?
Given the tool's complexity, the description covers ordering, criticism, creator distinction, status, pagination quirks, and differences from sibling tools. The output schema exists, so return values need not be detailed. The description is complete enough for an agent to use the tool correctly and interpret odd results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes the title parameter well, and the description reinforces it with 'every word given' and 'Add a word to the title to reach further'. However, page and limit parameters are not explicitly explained in the description; their behavior is only indirectly implied through index-window discussion. With low schema coverage (33%), the description should compensate more for these numeric parameters, but it only partially does.
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 clearly states it finds a work by words in its title and returns the identifier used by get_work and list_editions. It also differentiates itself from list_works, which walks from a person to works they created, so it is not merely a generic search description.
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 gives explicit guidance on when to use this tool versus alternatives: for title-word searches, and specifically says list_works is the tool for finding works by a person's name. It also instructs reading 'creators' to distinguish criticism from the work itself, which is a clear usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.6/5.0
Disambiguation5/5
Each tool has a clearly distinct role: search_authors and search_works find identifiers, get_author and get_work retrieve records, list_editions enumerates editions, and find_digitised collects digitised links. No two tools overlap in purpose, and the input/output relationships are well-documented.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores. Search and get are paired with singular/plural nouns appropriately (search_authors vs get_author), and list_editions/find_digitised follow the same convention. The pattern is predictable and readable.
Tool Count5/5
With six tools, the server is well-scoped for its purpose. Each tool addresses a distinct step in the bibliographic workflow (search, retrieve, list editions, find digitised copies), and none feel redundant or excessive.
Completeness3/5
The tools cover search and retrieval for authors and works, plus editions and digitised links, but there is a notable gap: no way to list all works by a given author, since search_works only matches titles and get_author explicitly does not link to works. This is an acknowledged limitation that could block common discovery workflows.
Maintenance
ActivityMaintained
ResponsivenessWithin a week
Related MCP Connectors
MCP server for Russian books search, details, and recommendation candidates.
Gutendex MCP — wraps Gutendex API for Project Gutenberg books (free, no auth)
Books MCP — wraps Open Library API (free, no auth)
MCP server for the Émile wine cellar — list, add, recommend, scan and search 100k+ wines.
Related MCP Servers
- FlicenseNot gradedqualityFmaintenanceAn MCP server that searches library catalogs worldwide using the SRU protocol, enabling bibliographic search without API keys.
- FlicenseNot gradedqualityDmaintenanceMCP server for querying French railway services (SNCF) via the Navitia API, enabling station search, journey planning, and departure board retrieval.
- FlicenseNot gradedqualityDmaintenanceMCP server to query French Open Data from data.gouv.fr
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/smeet666/mcp-databnf'
If you have feedback or need assistance with the MCP directory API, please join our Discord server