Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Server has 3 tools with present but incomplete descriptions and schemas. Tool names follow verb conventions (search_, get_, fetch_) which is good. However, descriptions are terse and parameter documentation is inconsistent. Input schemas are visible and typed, but parameter descriptions within schemas are sparse or generic. No output schemas are documented. Error handling is minimal, tools return HTTP status codes or generic 'Fetch data response' without actionable recovery guidance. The server lacks tool annotations (readOnlyHint, destructiveHint, idempotentHint) and does not guide LLM behavior on error conditions.
Tools (3)
fetch_dataread onlyauthsource verified65/100
Fetch data from the API.(Base on information of get_std_docs tool)
get_std_docsread onlysource verified60/100
Get standard documents from the search results.
search_apiread onlysource verified73/100
Search for APIs in the Open Data Portal using keywords.(API Provider: OpenDataAPI(mcp.ezrnd.co.kr))
Tool descriptions are below 10 - 1024 character baseline for optimal LLM selection. 'search_api': 107 chars (borderline), 'get_std_docs': 46 chars (too terse), 'fetch_data': 56 chars (too terse). Descriptions lack WHEN to use guidance and any prerequisites.
No output schemas documented. LLMs cannot plan follow-up calls or extract required chaining IDs. E.g., search_api response structure is unknown, does it return 'api_id', 'listId', 'id'? Does it include pagination metadata? Downstream tools require these IDs but the contract is implicit.
Parameter descriptions within input schemas are generic or missing crucial details. E.g., fetch_data 'params' array items have 'name' (string, no description) and 'value' (string|null, vague 'value of the parameter' description). No guidance on required vs optional params, format constraints, or how they map to the actual API endpoint.
fetch_data
Recommendations
Expand tool descriptions to 100 - 200 characters. For get_std_docs: 'Retrieve standard documents and API specifications from the Open Data Portal using listIds returned by search_api. Returns endpoint paths, methods, parameters, and headers needed for fetch_data.' For fetch_data: 'Execute HTTP requests to Open Data Portal APIs using connection details from get_std_docs. Automatically injects service credentials if configured. Returns JSON or text response from the API endpoint.'
Document output schemas for all three tools. Example for search_api: '{ "apis": [ { "listId": number, "name": string, "provider": string, "url": string } ], "totalCount": number, "pageNumber": number }' Include which fields can be passed to downstream tools.
Add tool annotations to the input schema. Add 'readOnlyHint: true' to all three tools to signal to LLMs that they are safe to retry without side effects. Example: registerTool("search_api", { title: ..., description: ..., inputSchema: ..., readOnlyHint: true }).
Expand parameter descriptions in fetch_data. For 'params' array items, add: 'A parameter required by the API endpoint. If the parameter name contains "serviceKey", it will be automatically populated with your configured service key, pass an empty string as the value. Other parameters should be passed as-is.' For 'headers' array, add: 'HTTP header to include in the request. If the header name contains "Authorization", the value field will be prefixed with the provided prefix and your service key automatically injected.'
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Error handling is minimal and non-actionable. fetch_data returns bare HTTP status codes or generic JSON responses without recovery guidance. E.g., 'HTTP error occurred: 403' does not tell the LLM whether to retry, ask the user for credentials, or call a different tool. No error categorization (retryable vs user-fixable vs fatal).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While all tools are READ_ONLY per the metadata, this is not communicated to the LLM via the tool definition. The LLM cannot reason about retry safety or state mutation without explicit hints.
Parameter 'listId' in get_std_docs accepts an array of numbers but has no validation or range constraints. What is a valid listId? Where do these come from? The description assumes prior knowledge (search_api results) without stating this dependency explicitly.
fetch_data's 'baseInfo' and 'endpointInfo' require nested objects with multiple required fields. The parameter descriptions ('Host name of the API', 'Base path of the API') lack format guidance. E.g., 'host' is described as 'No protocol or slash' but the description is inside the schema, not visible to the LLM unless it parses JSON Schema.
Service key injection is not transparent. fetch_data modifies params on the fly when 'servicekey' is detected in the name, and modifies headers when 'authorization' is detected. This auto-injection is undocumented in the tool description and parameter documentation. An LLM cannot infer that passing empty string will trigger auto-fill.
fetch_data
Add dependency hints to tool descriptions. search_api description: '(...) Call this tool first to discover available APIs and retrieve listIds.' get_std_docs description: '(...) Call this tool after search_api to get endpoint specifications before calling fetch_data.' fetch_data description: '(...) This tool requires endpoint details from get_std_docs.'
Implement actionable error handling in fetch_data. Instead of 'HTTP error occurred: 403', return: 'HTTP 403 (Forbidden). Possible causes: (1) Service key is invalid or expired, re-configure ODP_SERVICE_KEY environment variable, (2) API requires authentication but none is configured, set ODP_SERVICE_KEY, (3) API endpoint requires additional headers, review endpoint specification from get_std_docs.' For timeout errors, return: 'Request timed out (>30s). API endpoint may be offline or overloaded. Try again in a few moments, or check https://www.data.go.kr for service status.'
Document the auto-injection behavior explicitly. Add a note at the top of fetch_data description: 'Service credentials are automatically injected: parameters containing "serviceKey" or headers containing "Authorization" are populated from the configured ODP_SERVICE_KEY. Pass empty string ("") as the value and let the tool fill it in.'
Add parameter constraints to search_api. 'query' parameter: add 'maxLength: 50' per keyword and document: 'Array of 1-5 search keywords, each up to 50 characters.' 'pageSize' should have example: 'Typically 20. The API supports 1-100 items per page. Larger pages reduce round-trips but may increase response latency.'
Add validation errors to fetch_data response handling. Catch JSON parse errors, network errors, and timeout scenarios separately. Return structured error objects: '{ "error": "NETWORK_TIMEOUT", "message": "Request exceeded 30 second timeout", "retryable": true, "nextSteps": "Retry the request, or choose a different API endpoint." }'
Consider adding a 'describe_endpoint' or 'validate_endpoint' helper tool. Some APIs return detailed parameter schemas and validation rules in a DESCRIBE or OPTIONS call. Expose this so LLMs can auto-validate before calling fetch_data.