Related Servers

Most tools target a distinct resource+action and the descriptions are unusually explicit about when to pick each one (e.g. logs vs metrics vs health). However, there are real confusable clusters: deploy vs redeploy, set_env vs set_env_from_file, and especially email_status vs email_deliverability vs email_overview vs email_activity, where 'is email working?' could plausibly hit three or four tools. Descriptions mitigate but do not eliminate the overlap.

Names are snake_case and grouped by a readable resource prefix, but the verb position is inconsistent: verb-first (create_application, remove_env, add_schedule, create_ai_key) mixed with resource-first (database_create, storage_create, auth_create, email_create, email_pause, email_remove). There are also bare-noun tools (app_settings, database_info, deployment_history, logs, health, metrics) and single-word verbs (deploy, login, rollback), so the pattern is predictable only within a sub-cluster.

48 tools is heavy even for a broad platform surface, and several groups look consolidatable: eleven email_* tools, four near-identical *_env_to_file tools, and separate *_create / *_env_to_file pairs for database, storage, auth and email. The domain justifies many tools, but this count pushes well past the point where an agent can scan the surface comfortably.

Coverage is strong across the lifecycle: application create/link/list, deploy/redeploy/rollback/status/history, env list/set/set-from-file/remove, schedules list/add/enable/remove, plus one-shot provisioning and status for database, storage, auth, email, AI keys and security scans. Minor gaps: no delete/remove for the application itself, no update_schedule (must remove and re-add, as the description admits), and no standalone info/status for storage or auth comparable to database_info.