This server auto-generates tool definitions from an OpenAPI spec via FastMCP's RouteMap pattern. All 15 tools have identical, minimal descriptions ('...generated from OpenAPI spec') that provide zero context for LLM selection. No input schemas are visible in the source code, they are inferred from the OpenAPI spec at runtime, making validation impossible. Parameter descriptions, enums, and constraints are not documented. Output schemas are not declared. Error handling is absent. The server exposes destructive operations (DELETE) without confirmation or permission gates. This is a thin HTTP-to-MCP proxy with no LLM-optimized tooling.

• Replace generic descriptions with LLM-optimized text. Example: 'GET /bookmarks' → 'List all bookmarks with optional filtering by tag or list. Returns up to 50 results; use pagination for more. Call this first to discover available bookmarks before fetching details.'
• Document input schemas explicitly in code or via a schema override layer. For each POST/PUT tool, declare required/optional parameters, types (string, integer, enum), constraints (min/max length, allowed values), and descriptions.
• Add confirmation gates to DELETE tools. Implement a two-step pattern: first call returns a confirmation_token; second call with token executes the delete. Or return a dry-run response showing what would be deleted.
• Implement structured error responses with recovery hints. Example: 'Bookmark not found (404). Try: (1) list_bookmarks() to see available IDs, or (2) search_bookmarks() by title/tag.'
• Document output schemas for all tools. Specify which fields are returned, their types, and which are safe to chain into downstream tools (e.g., bookmarkId for use in GET /bookmarks/{bookmarkId}).