Related Servers

Tools are grouped by service prefix (firestore_, auth_, storage_, pubsub_, tasks_, schedules_, eventarc_, functions_, rules_, logs_, extensions_, emulators_) and each action within a group is distinct (get vs query vs count, copy vs move, list vs get_call). A few pairs could still be confused at a glance: auth_mint_token vs auth_set_claims (token-only claims vs stored custom claims), pubsub_peek vs pubsub_list_subscriptions (both expose backlog), and firestore_delete vs emulators_clear (scoped vs global destructive wipe). These are resolved by the descriptions, so ambiguity is minor rather than systemic.

Names follow a predictable service_verb_noun snake_case pattern (firestore_get, auth_list_users, storage_upload, functions_replay_call), which makes the set easy to scan and predict. A handful of deviations drop the verb (auth_oob_codes, auth_verification_codes, tasks_stats) and a few are noun-first (firestore_list_collections, functions_list_calls), but the service prefix keeps everything readable.

54 tools is heavy by any standard, though the surface genuinely spans a dozen Firebase sub-domains (Firestore, Auth, Storage, Pub/Sub, Tasks, Schedules, Eventarc, Functions, Rules, Logs, Extensions, Emulators), averaging ~4-5 tools each. Per-domain scope is tight, but the overall count makes discovery and selection cost high for an agent. It sits at the borderline of 'large but justified' rather than clearly well-scoped.

Coverage is unusually deep: full CRUD for Firestore documents, Auth users, Storage objects, plus inspection/replay for functions, Eventarc events, scheduled runs, rules evaluation and logs. Notable gaps remain: no user profile update (email/password/display name), no Pub/Sub topic/subscription creation or message pull/ack, no rules deployment (rules_get is read-only), and no emulator start/stop/import to pair with emulators_export and emulators_clear. Most gaps are workaroundable but some block common emulator-management workflows.