Skip to main content
Glama

Gather the digitised documents attached to a record

find_digitised
Read-onlyIdempotent

Retrieve direct links to every digitised document linked to a BnF person or work by supplying its identifier.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesA 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.
kindNoWhat 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
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
kindYesWhat the catalogue types this record as.
linksYes
notesYes
has_moreYes
retrieved_atYesWhen 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_roleYesHow 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.
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.

Install Server

Other Tools

Latest Blog Posts

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