MCP server for Saint Patrick Library that provides tools to list and query books, cafes, bookmarks/separadores, and book supports, as well as shopping cart and order management functionality
Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
This server has severe definition quality issues across all dimensions. Tool names use Spanish and lack action verbs, descriptions are minimal (15-40 chars), input schemas are completely missing for 5 of 10 tools, and output schemas are undocumented. The implementation pattern is fundamentally flawed: tools return HTTP request specifications rather than executing them or returning actual data. This is not a functional MCP server, it's a proxy that forces clients to interpret and execute HTTP calls manually.
Tools (10)
agregarAlCarritowriteauthsource verified
Add an item to the shopping cart with specified quantity
consultarCaferead onlyauthsource verified
Query a specific cafe by ID from the library API
consultarLibroread onlyauthsource verified
Query a specific book by ID from the library API
consultarSeparadorread onlyauthsource verified
Query a specific bookmark/separador by ID from the library API
consultarSoporteread onlyauthsource verified
Query a specific book support by ID from the library API
crearPedidowriteauthsource verified
Create and complete an order by paying for items in the shopping cart
Tool names are in Spanish without English action verbs. LLM tool selection depends on verb+noun patterns (get_, list_, create_, etc.). Spanish names like 'listarLibros', 'consultarLibro', 'agregarAlCarrito' force LLMs to reason about foreign language semantics instead of parsing intent directly. Baseline: 90% of A+ tools start with an action verb in English.
No input schemas visible for 5 of 10 tools (listarLibros, listarCafes, listarSeparadores, listarSoportes, crearPedido). Per HARD SCORING RULES: 'If a tool has NO input schema at all: its schema score MUST be 0.' These tools cannot be validated by LLMs and risk invalid invocations.
Rename all tools to English with action verbs. Replace 'listarLibros' with 'list_books', 'consultarLibro' with 'get_book', 'agregarAlCarrito' with 'add_to_cart', 'crearPedido' with 'create_order'. This matches LLM expectations and the 90% baseline of A+ tools.
Rewrite descriptions to 100-200 characters and answer WHAT, WHEN, and any prerequisites. Example: 'Retrieve a single book by its ID. Use after list_books() to get available book IDs. Returns title, author, ISBN, availability, and price.' Current 'Query a specific book by ID' lacks context.
Add input schemas to all tools. For list_* tools, add 'page' (integer, default=1), 'limit' (integer, 1-100, default=20), 'sort_by' (enum: title|author|newest|popularity). For get_* tools, require 'id' (string) and optionally accept 'id_type' (enum: uuid|isbn|sku) for flexibility.
Document complete output schemas. Example for get_book: {"id": "string", "title": "string", "author": "string", "isbn": "string", "price": "number", "available": "boolean", "in_stock_count": "integer"}. Do this for every tool.
Fix the core architectural issue: have tools execute HTTP calls and return parsed JSON data, not HTTP request specs. The server should call the backend API, extract relevant fields, and return structured results to the LLM. Clients should never see 'url' and 'method' keys.
Add error handling with actionable guidance. Example: 'If get_book returns 404, try list_books() to find the correct book ID. If 401 Unauthorized, verify the authentication token is set.' Return structured errors with error codes (NOT_FOUND, UNAUTHORIZED, etc.) and recovery hints.
Score history
Overall score trend
↓ 14 points across a rubric change (v1 → v2)
8/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
8
2026-07-28+
v2
2026-03-09
F
22
-
v1
auth
source verified
List all books from the library API
listarSeparadoresread onlyauthsource verified
List all bookmarks/separadores from the library API
Descriptions are too short (15-40 chars, below the 34-char p10 baseline). Per HARD SCORING RULES: 'If descriptions are under 20 characters: description score CANNOT exceed 40.' Examples: 'List all books from the library' (32 chars), 'Query a specific book by ID' (27 chars). These lack context for when/why to use the tool. Baseline: average A+ tool description is 194 chars (p10=34, p90=392).
No output schemas documented for any tool. The server returns HTTP request specifications (URL, method, headers) rather than actual data. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' No documented output means LLMs cannot understand what data is available or chain tools together.
Fundamental architectural flaw: tools return HTTP request metadata rather than executing them or returning actual results. Example from consultarLibro: returns {"url": "...", "method": "GET", "headers": {...}} instead of book data. This delegates HTTP execution to the client, violating the tool pattern.
Parameter descriptions are missing for 'id' and 'cantidad' params. While consultarLibro shows 'Book ID to query', other tools (consultarCafe, consultarSeparador, etc.) lack descriptions or are not visible in schema. LLMs cannot infer parameter meaning from names alone.'
No pagination or result limits documented. List tools (listarLibros, listarCafes, etc.) do not specify page/offset, limit parameters, or total count in output.
No permission gates or scope declarations. Tools modify state (agregarAlCarrito, crearPedido) without documenting required permissions or verifying user authority. 'read:email', 'write:calendar').' No audit trail or permission checks visible in code.
agregarAlCarritocrearPedido
Implement pagination for list_* tools. Accept 'page' and 'limit' parameters, cap results at 50 items, and return {"items": [...], "total": 1000, "page": 1, "page_size": 50, "has_next": true}. This prevents context window overflow.
Add scope declarations and permission gates. Document that create_order requires 'write:orders' scope. Validate the calling agent/user has this permission before executing. Log the action with timestamp, caller, and result for audit trails.
Add parameter validation. For numeric parameters like 'cantidad' (quantity), specify range (1-1000), default (1), and handling of invalid values. Return clear errors: 'Invalid quantity: got 0, must be 1-1000'.
Consider adding a dry-run mode for destructive operations. For create_order, add an optional 'confirm' parameter. Return a summary for confirmation before actually processing the payment.
Add natural-language identifiers where possible. Instead of requiring an opaque 'id' UUID, accept 'book_title' or 'author_name' as alternatives and resolve them server-side. This matches how users think about books.
Document the complete tool chain. Show how list_books() → get_book() → add_to_cart() → create_order() connects. Include required IDs that flow between steps so the LLM can plan multi-step workflows.