A read-only MCP server that lets you query a library database of books and authors through 5 tools:
search_books: Search for books by partial title match and/or exact genre, with an option to filter for only available copies.
get_book: Retrieve full details of a specific book (including author name) by its ID.
books_by_author: Find all books by a specific author using a partial name match (e.g., "Borges" matches any author containing that name).
list_authors: Get a complete list of all authors in the library along with their book counts.
library_stats: Retrieve a summary of the entire library, including totals for titles, authors, and available copies.
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., "@Library Book MCP Server search for books by Stephen King"
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.
Un servidor MCP (Model Context Protocol) mĂnimo y de solo lectura, hecho en Python, que consulta una base de datos Postgres con libros y autores.
El objetivo es aprender cĂłmo un agente (por ejemplo en Azure AI Foundry) descubre y llama herramientas expuestas por un MCP.
Expone 5 herramientas (tools) que el agente puede llamar:
Tool | Qué hace |
| Busca libros por tĂtulo y/o gĂ©nero, opcionalmente solo disponibles |
| Detalle completo de un libro por id |
| Libros de un autor (bĂşsqueda por nombre) |
| Todos los autores con su nĂşmero de libros |
| Resumen: totales de tĂtulos, autores y copias |
Related MCP server: mcp-kindle
Docker (para Postgres)
Python 3.11+ (con uv no hace falta tenerlo instalado; Ă©l descarga uno)
uv (recomendado) o pip
docker compose up -dEsto levanta Postgres vacĂo. Las tablas y los datos de ejemplo los crea la
propia app al arrancar (init_db en server.py), asĂ que no hay que cargar
nada a mano.
Para reiniciar los datos desde cero:
docker compose down -v && docker compose up -dCon uv (recomendado):
uv syncO con pip + venv:
python -m venv .venv && source .venv/bin/activate
pip install -e .La forma más rápida de ver las tools sin escribir un cliente es el MCP Inspector:
uv run mcp dev server.pySe abre una UI en el navegador donde puedes listar las tools y llamarlas a mano.
Para correrlo directamente (modo stdio, como lo lanzarĂa un agente):
uv run server.pyO usa el cliente de ejemplo incluido, que arranca el server, lista las tools y llama algunas (es la forma más fácil de ver la mecánica del protocolo):
uv run test_client.pyEjemplo de configuraciĂłn para un cliente tipo Claude Desktop / Cursor
(mcpServers):
{
"mcpServers": {
"library": {
"command": "uv",
"args": ["run", "server.py"],
"env": {
"DATABASE_URL": "postgresql://library:library@localhost:5433/library"
}
}
}
}Variables de entorno:
Variable | Default | Para qué |
|
| ConexiĂłn a Postgres |
|
|
|
|
| Puerto HTTP (solo con |
|
| Al arrancar, crea el esquema y carga |
Seed automático: la app ejecuta
seed.sqlal arrancar (verinit_dbenserver.py). Es idempotente, asà que no duplica datos ni depende de mounts ni de tocar el contenedor de Postgres. Ponlo enfalsepara el proyecto real, donde normalmente no querrás sembrar datos desde la app.
El server ya soporta transporte HTTP. En modo streamable-http expone:
GET /health → ok (para el health check)
POST /mcp → el endpoint del protocolo MCP (lo consume el agente/cliente)
La app se auto-inicializa: al arrancar crea el esquema y carga los datos de
ejemplo (seed.sql) si faltan. No hay que montar seed.sql ni tocar el
contenedor de Postgres.
Usa docker-compose.coolify.yml: levanta Postgres
MCP juntos.
En Coolify crea un recurso Docker Compose apuntando a tu repo y a
docker-compose.coolify.yml.
(Opcional) Define POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB como
variables del recurso; si no, usa los defaults (library).
Asigna un dominio al servicio mcp. Para enrutar al puerto interno del
contenedor, escrĂbelo en el dominio: https://<tu-dominio>:8000. Coolify lo
sirve pĂşblico en 443. No expongas la DB.
El endpoint MCP para el cliente/agente quedará en
https://<tu-dominio>/mcp. Health check: path/health(respondeok).
Postgres: provisiona un contenedor Postgres manualmente (vacĂo; la app lo siembra sola al arrancar).
MCP: crea un recurso Application apuntando a tu repo (usa el Dockerfile).
Variables de entorno del MCP:
DATABASE_URL → hostname interno del Postgres (no localhost),
p. ej. postgresql://library:library@<servicio-postgres>:5432/library.
MCP_TRANSPORT=streamable-http (ya viene en el Dockerfile).
PORT=8000.
Health check: path /health, GET. Puerto: 8000.
docker build -t mcp-library .
docker run --rm -p 8000:8000 \
-e DATABASE_URL="postgresql://library:library@host.docker.internal:5433/library" \
mcp-library
curl http://localhost:8000/health # -> ok.
├── docker-compose.yml # Postgres 16 para desarrollo local
├── seed.sql # Esquema + datos de ejemplo (carga automática)
├── server.py # El MCP: FastMCP + tools (stdio o streamable-http)
├── test_client.py # Cliente de ejemplo para probar el MCP sin agente (stdio)
├── Dockerfile # Imagen del MCP para desplegar (Coolify, etc.)
├── .dockerignore
├── pyproject.toml # Dependencias
└── README.mdAgregar tools de escritura (crear/prestar libros) cuando quieras practicar acciones.
Cambiar el transporte a HTTP/SSE para conectar desde Azure AI Foundry.
Añadir recursos (resources) además de tools, p. ej. exponer el esquema de la DB.
Lista los libros de un autor buscando por su nombre (bĂşsqueda parcial).
Args: author_name: Nombre o parte del nombre del autor (ej. "Borges").
| Name | Required | Description | Default |
|---|---|---|---|
| author_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses the partial search capability but does not mention pagination, limits, or any other behavioral traits. The tool is simple, so minimal disclosure is acceptable but not exceptional.
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 extremely concise: two sentences covering purpose and parameter semantics. No wasted words; the essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description provides adequate context. It could mention case sensitivity or result limits, but overall it is complete enough for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter author_name has 0% schema description coverage, but the description compensates by explaining it expects a name or partial name with an example ('Borges'). This adds value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists books by author using partial name search. It distinguishes itself from siblings like get_book (single book) and list_authors (list authors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing books by author but does not provide explicit guidance on when to use this tool versus siblings like search_books. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el detalle completo de un libro por su id.
Returns: El libro con todos sus campos y el nombre del autor, o None si no existe.
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses that the tool returns the complete book or None if not found, but does not mention permissions, side effects, or error handling beyond the None case. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose, and the second clarifies the return value. No unnecessary words, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema (from context signals). The description explains the return value including the None case. For a simple retrieval, this is nearly complete, though it could mention potential error responses or rate limiting. Still, it suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the only parameter (book_id). The description adds no additional meaning about the parameter—it only restates that it's an ID. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the complete detail of a book by its ID, specifying the return includes all fields and the author's name. This distinguishes it from sibling tools like search_books (multiple results) and books_by_author (filtered list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings. There is no mention of prerequisites, context, or conditions where an alternative would be better. The agent must infer solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve un resumen de la biblioteca: totales y disponibilidad.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adequately describes the output ('totals and availability') but does not disclose any other behavioral aspects such as read-only nature, potential latency, or error conditions. For a simple query tool, this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides sufficient information for an AI agent to understand what the tool returns. It could benefit from clarifying that the output is a summary (e.g., counts of books, authors), but it is complete enough for its simplicity.
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?
There are no parameters, so the input schema is complete with 100% coverage. The description does not need to add parameter semantics, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a library summary of totals and availability. It distinguishes from sibling tools like books_by_author, get_book, list_authors, and search_books, which focus on specific queries rather than an overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used for a high-level summary, but it does not explicitly state when to use it versus alternatives or provide any exclusion criteria. The purpose is clear, but guidance on context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve todos los autores con cuántos libros tiene cada uno.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description accurately describes the output (authors with counts). It is a read-only list without side effects, which is clear. Could mention sorting or caching but not necessary for such a simple 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?
One concise sentence with no wasted words. Front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple output (authors with counts), the description fully conveys what the tool does. An output schema exists but is not needed to understand the behavior.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info but none is needed; baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all authors with their book counts, using a specific verb ('Devuelve') and resource. Distinguishes from siblings like books_by_author (which likely requires an author parameter) and search_books (which queries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage context or alternatives are provided, but the tool is simple and parameterless, so usage is implied: use when needing a complete list of authors and their book counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca libros por tĂtulo y/o gĂ©nero.
Args: query: Texto a buscar dentro del tĂtulo (bĂşsqueda parcial, ignora mayĂşsculas). genre: Filtra por gĂ©nero exacto (ej. "Cuento", "Novela"). VacĂo = todos. available_only: Si es True, solo devuelve libros con copias disponibles.
Returns: Lista de libros con su autor. VacĂa si no hay coincidencias.
| Name | Required | Description | Default |
|---|---|---|---|
| genre | No | ||
| query | No | ||
| available_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It discloses case-insensitive partial search, exact genre filtering, and the behavior of available_only (returns only books with copies). This is adequate for a read-only search tool, though it does not mention return limits or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with Args and Returns sections, using only two lines of prose plus parameter descriptions. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters (none required) and an output schema, the description covers the core behavior, return format (list of books with author), and edge case (empty list). It does not mention pagination or sorting, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for any parameter (0% coverage). The description compensates fully by explaining each parameter: query for partial case-insensitive title search, genre for exact match (with example values), and available_only as a boolean filter. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it searches books by title and/or genre, specifying the two search dimensions. Sibling tools like books_by_author and get_book indicate that this tool is distinct in filtering by title/genre rather than author or single book retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly outlines the three parameters and their effects (partial case-insensitive search, exact genre filter, availability filter). It does not explicitly state when not to use this tool or compare to alternatives, but the context of siblings combined with the parameter explanations provides sufficient usage guidance.
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.0books_by_authorget_booklibrary_statslist_authorssearch_booksScored across 5 tools
Each tool serves a distinct purpose: searching by author, retrieving by ID, stats, listing authors, and searching by title/genre/availability. No overlap in functionality.
Most names follow a verb_noun pattern (get_book, list_authors, search_books), but 'library_stats' and 'books_by_author' are noun phrases, creating a minor inconsistency.
With 5 tools, the server is well-scoped for a read-only library catalog. Each tool adds distinct value without unnecessary bloat.
The tool set covers all essential read operations: search by author, by title/genre, get details by ID, list authors, and aggregate stats. No obvious gaps for its stated purpose.
MCP server for Russian books search, details, and recommendation candidates.
Read-only MCP server exposing a user ORANO library to their own AI agent.
Read-only MCP server for verified book recommendations and reading lists.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
