Three tools are well-defined with strong descriptions and comprehensive parameter schemas. Tool names are action-oriented (list_, search_, get_). Descriptions exceed the 50-character minimum and include detailed usage boundaries, trigger scenarios, and recommendations. Input schemas declare all parameters with types and descriptions. However, output schemas are entirely absent from the code, only parameter inputs are visible. The server does not document what each tool returns, which prevents LLMs from planning downstream calls or extracting structured data. No tool annotations (readOnlyHint/destructiveHint) are present despite all three tools being read-only operations. Error handling is not visible in the tool definitions themselves.

• Add explicit output schema documentation for each tool. Define the response structure as JSON Schema, listing all returned fields, their types, and meanings. Example for list_api: {type: 'object', properties: {apis: {type: 'array', items: {type: 'object', properties: {operationId, method, path, summary, tags}}}, total: {type: 'number'}, page: {type: 'number'}}}
• Add readOnlyHint: true to all three tool definitions in server.ts to signal that these tools have no side effects and are safe for unrestricted agent use.
• Enforce numeric constraints in schemas using minimum/maximum. For pageSize in list_api, add {type: 'number', minimum: 1, maximum: 200}. For limit in search_apis, add {type: 'number', minimum: 1, maximum: 100}.
• Ensure operationId, method, and path are all present in get_api_detail input schema with proper enum/type declarations. Currently, method and path are documented in the description but may not be in the actual schema JSON passed to tool registration.
• Document what list_api returns when called without project parameter (the tool description mentions '获取项目列表' but the return schema is not defined). Clarify whether it returns API objects, project objects, or both.
• Add error recovery hints to tool descriptions. For example, if search_apis returns zero results, suggest the user try list_api to browse available categories or use different keywords.
• Consider adding example usage or common parameter combinations in descriptions. E.g., 'Typical usage: search_apis(query="user management", limit=10) to discover APIs related to user management.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry