A FastAPI-based library management system with OpenAI integration for greeting generation
Server has 5 tools with basic schemas and descriptions, but significant quality gaps. All tools have descriptions (10-60 chars, mostly short) and input schemas with type definitions. However, descriptions are generic and lack LLM-optimization guidance. No output schemas documented. Parameters lack depth (no enums, ranges, or format constraints). Error handling is minimal, responses are unstructured dicts with generic 'error' or 'message' keys, offering no recovery guidance. No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Naming is verb-forward but some tools lack clarity on side effects. This is typical community-server quality (C-range).
Borrow a book from the library
Check the availability of a book by its ID
Get the borrowing history of a book
Generate a warm and friendly greeting for a library visitor using OpenAI
Return a borrowed book to the library
No output schemas documented. LLMs cannot predict response structure or plan downstream calls. All tools return unstructured dicts with 'message' or 'error' keys.
Error responses lack recovery guidance. Generic 'Book ID not found' or 'error' keys give LLMs no actionable next step. Should suggest search_books() or list available IDs.
No tool annotations. borrow_book and return_book are destructive (WRITE risk) but lack destructiveHint. check_book_availability and get_borrowing_history are read-only but lack readOnlyHint. Agents cannot distinguish safe from risky calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Parameter descriptions are minimal (1-5 words). 'The unique identifier of the book' is generic; should explain format (e.g. 'book_001 format') and whether lookup by title is supported.
No pagination or result limits. get_borrowing_history returns entire history as a comma-separated string. Large histories will bloat responses and waste tokens.