Server Quality Checklist

Tool Scores

• auth_readC
  2.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Read' which is implicit from the name, and does not elaborate on safety, side effects, permissions, or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise (one sentence) but at the cost of completeness. It is not verbose, but it is underspecified given the complexity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters, no output schema, and no annotations, the description is inadequate. It should explain that results are read-only, pagination behavior, and that it does not modify data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with detailed descriptions for each parameter, including enums and usage notes. The tool description adds no additional semantic value beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Read from Firebase Authentication' clearly states the verb (read) and resource (Firebase Authentication). It differentiates from siblings like firestore_read which reads from Firestore, though it does not explicitly contrast them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives, nor on when to choose 'get_user' vs 'list_users'. The description provides no usage context or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_configA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite the name 'create_config', the description accurately states it returns a template, indicating it is a read-only operation. No annotations exist, but the description adds behavioral context about its non-destructive nature and the recommended workflow.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main purpose, and every word contributes meaning. No redundancy or wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema), the description is complete: it explains what the tool returns, when to use it, and what to do next. It adequately equips an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameters, and schema coverage is 100%. The description adds meaning by explaining the tool returns a template for the config file structure, which goes beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Returns a template showing the required structure of the firebase-mcp.json config file'. It distinguishes from siblings by explicitly mentioning reload_config for loading after creation, and implies get_config for reading the current config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description specifies when to use: 'Use this when no config file has been found'. It also provides the next step to call reload_config. While it doesn't explicitly exclude other use cases, the context is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reload_configA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the key behavioral traits: re-reading config and evicting caches. This alerts the agent to potential side effects (cache invalidation). It could mention impact on other tools or need to reauthenticate, but for a zero-parameter tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loading the action and then the usage trigger. Every sentence adds value with zero waste. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters, no output schema, and the straightforward action, the description is complete. It covers what the tool does and when to use it. No information is missing for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters (0 params, 100% schema coverage by default). The description adds no parameter information because none is needed. Baseline for 0 params is 4, and the description meets that baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('re-reads the config file from disk and evicts all cached project runtimes') and explicitly distinguishes its use case from siblings by referencing when to use it ('after the user says they have changed their firebase-mcp.json config').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance by stating when to use this tool (after config changes). While it doesn't list when not to use it or alternatives, the context of sibling tools implies usage boundaries. It effectively communicates the primary use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• firestore_readA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries full burden. It discloses detailed behavior for all operations, including internal fetching limits ('up to maxBatchFetchSize') for distinct_values, pagination mechanics (startAfter), and path segment conventions. No destructive actions implied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is long and embeds detailed operation-by-operation documentation in a single paragraph. While comprehensive, it lacks bullet points or separation that would improve scannability. The two introductory sentences are efficient, but the bulk is dense.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 23 parameters, no output schema, and no annotations, the description thoroughly covers all operations, parameter constraints (e.g., path segment parity), and edge cases (e.g., minCollections, groupByPathSegment). It provides enough detail for an AI agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, baseline 3. The description adds significant value for the 'operation' parameter with detailed enum descriptions. For other parameters, it largely reiterates schema info (e.g., path segments) but still provides helpful context like 'ODD segments' that clarifies usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states 'Read from Firebase Firestore' with a verb and specific resource. It distinguishes from sibling tools (auth_read, create_config, etc.) which deal with authentication and configuration. The operation field is introduced as the mechanism to choose a read action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Extensive guidance on when to use each operation, e.g., 'Call this early to avoid exploring the schema from scratch' for list_paths. Explicitly defines arguments and constraints per operation (e.g., EVEN vs ODD path segments). No need to exclude siblings as they are unrelated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_configA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It discloses that the tool excludes sensitive fields (e.g., serviceAccountPath), which is a key behavioral trait. It also implies the configs are in-memory, though it could further clarify read-only behavior or potential performance impacts. The disclosure is sufficient to avoid misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two concise sentences. The first sentence delivers the primary purpose and a key exclusion, and the second sentence provides an alternative use case. No wasted words, and the structure is front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although there is no output schema, the description adequately explains the return value: 'all in-memory project configs (excluding sensitive fields)'. It also gives a specific use case (finding projectId values) and provides alternatives. For a parameterless read-only tool, this is complete and actionable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are 0 parameters and schema coverage is 100% (vacuous). The description adds meaning beyond the schema by explaining what the tool returns (all configs, excluding sensitive fields) and its purpose (finding projectId values). This enriches the semantic understanding, earning a baseline-adjusted score of 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Returns') and resource ('in-memory project configs'), and specifies that it excludes sensitive fields like serviceAccountPath. It also provides a distinct use case: finding available projectId values. This differentiates it from siblings such as create_config and reload_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on when to use an alternative: 'If hasPaths is true, use firestore_read list_paths for path templates.' This directly tells the agent when not to use this tool and provides a sibling alternative, which is excellent usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.