Both tools have minimal descriptions (under 100 chars) and lack parameter-level documentation. Input schemas are present but sparse: parameters have types (string) but no descriptions, violating the requirement that every parameter must explain what it controls. Tool names lack action verbs (resolve-library-id, query-docs are noun-heavy). No output schema is documented. Error handling is absent, no guidance on what to do if resolution fails or docs are not found. The server acts as a thin wrapper around an external Context7 service, delegating all logic, which limits the ability to provide rich error recovery or validation.

• Add parameter descriptions to both tools. For resolve-library-id: 'libraryName: The name of the library (e.g., "fastapi", "react"). query: A search term to disambiguate if multiple libraries match (e.g., "web framework").' For query-docs: 'libraryId: The Context7-compatible library ID returned by resolve-library-id (format: /vendor/library). query: The documentation search term (e.g., "authentication", "async examples").'
• Expand tool descriptions to 100-150 chars with intent and return value. E.g., 'Resolves a library name to a Context7-compatible ID. Call this first if you only have a library name. Returns the best-matching library ID; if multiple matches exist, use the query parameter to disambiguate.'
• Document output schema. Specify that resolve-library-id returns a library ID string (format /vendor/library) and query-docs returns documentation text (markdown or plaintext). Include example outputs.
• Rename tools to action verbs: 'get_library_id' and 'search_documentation' are clearer and follow the verb_noun convention used by 90% of production tools.
• Add error handling with recovery hints. E.g., 'If library not found, try a partial name or check spelling. If docs are empty, the library may not be indexed in Context7, try a different search term or library name.'