Loading ToolBench
Firebase Remote Config tools using the fbrcm machine contract. An MCP server that provides tools for inspecting, editing, planning, and publishing Firebase Remote Config configurations.
fbrcm exhibits significant quality gaps across naming, descriptions, and schemas. Of 6 tools analyzed, none have complete parameter descriptions, and schemas are partially visible with missing type information. Tool names follow verb_noun convention (get, update, show, list, add, blame) which is positive, but descriptions range from generic (10-20 chars) to moderate (30-60 chars), falling below the 50-200 char LLM-optimized baseline. Critical issue: parameters.update, draft.show lack any schema visibility in the provided code, these are inferred rather than explicitly defined, capping their scores at 50. The server uses tool annotations (destructiveHint/readOnlyHint) which is modern, but lacks structured output documentation and error handling guidance.
List Firebase Remote Config conditions
Show Firebase Remote Config draft
Add a Firebase Remote Config parameter
Get Firebase Remote Config parameters
Update Firebase Remote Config parameters
Blame Firebase Remote Config parameter versions
Two tools (parameters.update, draft.show) have NO visible input schemas, only empty objects. These are inferred rather than explicitly defined, making it impossible to validate parameter correctness or provide LLM guidance on required fields.
Tool descriptions range 20-35 chars, well below the 50-200 char LLM-optimized baseline. Generic descriptions like 'Update Firebase Remote Config parameters' provide no context for tool selection or error recovery guidance.
Parameter type constraints are missing or incomplete. 'type' parameter in parameters.add mentions valid values in description (string, number, boolean, json) but these are not declared as enum in schema. 'at' parameter in versions.blame has no documentation of allowed values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
No output schemas documented. For list operations (conditions.list, parameters.get) and mutating operations (parameters.add, parameters.update), the response structure is completely undocumented. LLMs cannot plan downstream tool chains or extract required IDs.
Tool naming inconsistency: 'versions.blame' uses non-standard terminology that will confuse LLMs. 'draft.show' mixes noun-first naming instead of verb_noun convention. Consider 'show_draft' or 'get_draft' for consistency with other tools.
No error handling guidance. Descriptions do not indicate what failures are possible (e.g., parameter not found, project not authorized, quota exceeded) or how LLMs should recover.
Ambiguous parameter placement: 'project' appears in both arguments and options in conditions.list and parameters.get. Unclear whether to pass once or multiple times, or what the semantics differ.
No pagination documented. List operations (conditions.list, parameters.get) do not specify whether results are paginated, what the limit is, or how to retrieve additional pages. This risks context window exhaustion.