Two tools with significant definition gaps. 'login' has a reasonable description (89 chars) and minimal schema (1 param, boolean). 'dynamic_tool' has a verbose, jargon-heavy description (234 chars) that conflates implementation details with user intent, and a complex schema with 4 parameters but lacks clarity on what the tool actually does from a user perspective. Neither tool has output schemas documented. Parameter descriptions are present but generic. No error handling guidance visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are WRITE-risk but descriptions do not explicitly state side effects or irreversibility.

• Rename 'dynamic_tool' to a verb_noun pattern reflecting the actual action, e.g., 'create_runapi_task' or 'execute_service_action'. This enables LLMs to infer intent from the name alone.
• Rewrite 'dynamic_tool' description to focus on user intent: 'Creates a RunAPI task for a specified service and action, optionally polling until completion. Returns task ID and status.' Remove implementation jargon (factory, inputSchema, cross-field rules).
• Document output schemas for both tools. Specify: login returns {api_key, config_path}; dynamic_tool returns {task_id, status, result, created}. Include field types and descriptions.
• Add explicit side-effect statements: 'login: Modifies local config file with credentials. Irreversible without manual deletion.' 'dynamic_tool: Creates a RunAPI task. Cannot be undone; use task cancellation if needed.'
• Add tool annotations: login with destructiveHint=true (modifies config); dynamic_tool with destructiveHint=true (creates external task). This signals to agents that these are not read-only operations.

Inferred effective spec: <=2025-11-25.

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