Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has significant definition quality gaps across all 7 tools. While tool names follow verb_noun conventions reasonably well, descriptions are inconsistent (some in Korean, some minimal), input parameters lack proper type definitions and descriptions in JSON Schema format, and output schemas are completely undocumented. The server appears to proxy requests to a backend MeDeasy API but does not provide LLM-optimized tool definitions. Critical issues: (1) Parameter descriptions are sparse or missing entirely, many parameters lack explanations of constraints, formats, or expected values. (2) No documented output schemas, LLMs cannot predict what fields will be returned or how to chain tools. (3) Security concerns: jwt_token appears as a parameter in multiple tools, violating secret-injection patterns. (4) Missing idempotency, pagination, and error recovery guidance. Tool definitions exist and are registered, but are far below production quality.
JWT tokens exposed as tool parameters, violating secret-injection pattern. Credentials must be server-injected via environment or vault, not passed in parameters, to prevent logging and leaking tokens into traces.
Remove jwt_token from all tool parameters. Implement server-side JWT extraction from HTTP headers (Authorization: Bearer <token>) or environment injection. This prevents credential leaks in logs and traces.
Document output schema for every tool. Use describe_all_responses=True in FastApiMCP config (already set) but ensure each endpoint returns a consistent, well-documented JSON structure. Example for search_medicine: {"medicines": [{"medicine_id": string, "name": string, "description": string}], "total_count": int}
Rewrite all descriptions in English only. Use action-oriented language: 'Search for medicines by name and return matching results. Use this to find medicine IDs before querying details. Maximum 20 results; use pagination for larger result sets.' Remove Korean; add WHEN to use it.
Add format, range, and enum constraints to every parameter. Example: change 'size: int Query(1, ...)' to 'size: int Query(default=20, ge=1, le=100, description="Number of results (1-100, default 20)")'
Implement pagination for search_medicine and get_medicine_routine_list_by_date_detailed. Add offset/limit or cursor-based pagination with a total_count or next_cursor field in responses.
Add error recovery guidance. Wrap HTTP errors in try/except blocks and return structured error responses: {"error": "unauthorized", "message": "JWT token expired or invalid", "recovery": "Request a fresh token and retry"}. Use HTTP 4XX for client errors with actionable messages.
Add jwt_token parameter to register_medicine_routine (currently missing). Mark as required=true in FastAPI Query and add it to the input schema.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 5 points across a rubric change (v1 → v2)
44/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
44
<=2025-11-25
v2
2026-03-09
F
49
-
v1
Parameter descriptions are inconsistent, sparse, or missing. Many lack format guidance, constraints, or context. Example: 'schedule_times' is described as '사용자가 선택한 시간대' (in Korean) with no indication of valid values, array element types, or constraints. Parameter names like 'size', 'take_time', and 'user_schedule_name' lack suffixed type hints (size_limit, time_start, schedule_name_display).
Descriptions are in mixed languages (Korean and English) without clear separation. LLMs are multi-lingual but descriptions should be consistent and complete in the primary language (English for international tools). Korean descriptions provide no context to English-speaking LLMs.
No pagination support documented. Tools like 'search_medicine' accept a 'size' parameter but no offset/limit or cursor. Large result sets will blow context windows without pagination guidance.
No error recovery guidance. Error responses return raw HTTP status codes and text without actionable recovery steps. Example: 'API 요청 실패: 401' tells an LLM nothing about how to retry or what to try next.
register_medicine_routine is missing jwt_token parameter entirely, yet all other tools require authentication. This is inconsistent and suggests the tool is incomplete or draft state.
No idempotency guarantees or dry-run support for WRITE tools (modify_medicine_routine_schedule_time, update_user_custom_agent_voice, register_medicine_routine). Agents may retry on transient failures, causing duplicate state changes.
Tool definitions inferred from FastAPI router, not explicitly registered. Input schema types are sometimes non-standard (e.g., 'date', 'time' instead of 'string' with format). Output schemas are completely absent, forcing per-tool score caps.
get_medicine_routine_list_by_date_detailed
Implement a dry-run mode for WRITE tools. Add an optional 'confirm' or 'dry_run' parameter that returns what would change without committing. Example: modify_medicine_routine_schedule_time(..., dry_run=True) returns the old and new schedule without persisting.
Document tool chaining requirements. For tools that return IDs (register_medicine_routine, search_medicine), ensure the response includes all IDs needed by downstream tools (medicine_id for get_medicine_by_medicine_id, schedule_id for modify_medicine_routine_schedule_time).
Add rate-limit headers and guidance. Document that agents should not retry faster than 1 call per second; implement exponential backoff in error messages: 'Rate limited. Retry after 5 seconds.'
Remove example JWT token from update_user_custom_agent_voice parameter description. Example values tempt LLMs to copy them literally; use regex patterns or format documentation instead.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to FastApiMCP registration to clarify side effects. Example: search_medicine and get_* tools should be marked read-only; register_medicine_routine and modify_* tools should be marked destructive.
Unify parameter naming. Avoid 'user_schedule_name' (ambiguous: is this a user ID? a schedule name?). Use 'schedule_name' or 'schedule_id' with clear descriptions of which one is expected and where to find valid values.