Server Quality Checklist

Tool Scores

• service_api_requestD
  1.8/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry the full burden of behavioral disclosure. The phrase 'enforcing host/auth safeguards' hints at restrictions but does not explain what those are, whether the call is read-only or mutating, what errors occur, or how auth is applied. For a generic HTTP caller, this is insufficient to predict side effects or requirements.

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

  Conciseness2/5

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

  The description is short (two sentences) but this is under-specification rather than conciseness. It omits essential details about request formation, endpoints, and safety. While it is easy to read, it lacks the substance needed to be useful, so it does not earn a higher score.

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

  Completeness1/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, no annotations, and no parameter descriptions, the description is grossly incomplete. An agent would have no idea how to format paths, what query parameters are allowed, what the response looks like, or what constraints 'host/auth safeguards' impose. This tool is not usable without significant external knowledge.

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

  Parameters1/5

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

  The input schema provides zero descriptions for any of the 7 parameters, and the description does not mention a single one. There is no explanation of method, path, body, query, headers, fastlyToken, or authorizationKey. With 0% schema coverage and no parameter documentation in the description, an agent cannot infer how to construct a valid request.

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

  Purpose2/5

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

  The description only states 'Generic target service HTTP API call' without specifying what service or which endpoints are targeted. It is vague and does not differentiate from sibling tools like fastly_get_config or service_health_check, which are purpose-built. An agent cannot tell what specific resource or action this tool performs.

  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?

  There is no guidance on when to use this generic caller versus the dedicated sibling tools. It does not mention that it is a fallback, nor does it suggest when a specific tool would be preferable. No context or preconditions are provided for invoking it.

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

• service_scope_infoC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states it returns metadata, implying a read-only operation, but does not explicitly state side effects, error behavior, permissions required, or what happens when the tenantId is not found. No additional behavioral traits are disclosed beyond the basic action.

  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 a single, concise sentence that front-loads the action and the key context (used by Postgres config and Vault token index paths). There is no redundant or filler text; every phrase adds meaning.

  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?

  Given no annotations, no output schema, and low schema coverage, the description is incomplete. It does not explain what the returned metadata contains, how the parameters influence the result, or any constraints on usage. An agent would lack sufficient information to call this tool correctly and interpret its response.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must explain the parameters. It mentions 'app/tenant/principal' which hints at the three parameters (userId, tenantId, accountId), but it does not explicitly map them. The description does not clarify the meaning of each parameter, their optionality, or their role in scoping. This is insufficient given the lack of schema descriptions.

  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 clearly states the tool returns scoping metadata and specifically ties it to Postgres config and Vault token index paths, which is a distinct purpose from sibling tools like service_connection_info or fastly_get_config. It uses a specific verb (Return) and resource (scoping metadata). However, it could be more explicit about the meaning of 'app/tenant/principal' relative to the parameters, so it misses a 5.

  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?

  The description gives no guidance on when to use this tool versus siblings. It does not mention any conditions, alternatives, or exclusions. Given the large set of sibling tools, this lack of usage context is a significant gap.

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

• service_query_suggestionC
  2.9/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 implies a read/safe operation ('Discover', 'recommendations') but never states it is non-destructive, mentions no side effects, and doesn't clarify behaviors implied by the operationType enum — notably 'mutate', 'suspend_logging', and 'resume_logging' — leaving the agent to guess what invoking this tool might affect.

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

  Conciseness4/5

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

  A single efficient sentence with zero filler that front-loads the core purpose. It loses a point only for being too terse to carry the load of 6 undocumented parameters — concise but under-specified.

  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 6 parameters, no output schema, no annotations, and 0% schema coverage, a discovery/recommendation tool is moderately complex. The description fails to explain the operationType enum values, what the output looks like, or how intent drives recommendations — an agent would struggle to call this correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, so every one of the 6 parameters must be explained in the description. The text only hints at 'workflow intent' (mapping to intent) and 'recommendations', but says nothing about path, method, operationType enum semantics, includeExamples, or includeToolSchemas. It barely compensates for the coverage gap.

  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 uses a specific verb-resource pairing: 'Discover MCP tool schemas and get query/tool recommendations for a workflow intent.' It clearly distinguishes from the Fastly-specific siblings, none of which do schema discovery or recommendation.

  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. It doesn't name a sibling to prefer for other cases, nor state conditions like 'when you need a concrete tool schema' or 'when your workflow intent is vague.' Among Fastly-focused siblings this is obviously different, but the description leaves the routing to inference.

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

• service_list_endpointsB
  3.2/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 behavioral disclosure burden. It implies a read-only operation with 'List', but never states whether it's non-destructive, what the output format looks like, whether auth/permissions are required, or what 'documented vs implemented' actually distinguishes. For an unannotated tool, these are meaningful gaps.

  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?

  A single, focused sentence that front-loads the action and the resource. Every word earns its place; there is no filler or redundant phrasing. Appropriate length for a description of a simple list operation.

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

  Completeness3/5

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

  For an unannotated, no-output-schema list tool, the description is mostly adequate but incomplete. It doesn't describe the response shape (a list of endpoint strings versus objects with methods/properties), which the agent would need to know to use the result. Given the absence of an output schema, the description should have covered this.

  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 tool takes zero parameters, so there is nothing for the description to explain about parameter usage. Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific meaning, but that is expected and acceptable here.

  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 uses a specific verb ('List') and names the resource ('documented/implemented target service HTTP endpoints exposed by this MCP server'). It is clear about scope, though the qualifier 'documented/implemented' is slightly ambiguous. It distinguishes from most siblings which concern config, health, purge, and connection info, but doesn't explicitly differentiate from service_connection_info, which could overlap.

  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 the many siblings (fastly_get_config, service_connection_info, service_health_check, etc.). With 11 sibling tools, an agent has no routing hints to pick this one over alternatives. No when-to-use or when-not-to-use context is provided.

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

• service_connection_infoB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It implies a read-only operation by using 'Return', but it does not explicitly state that it has no side effects, does not require authentication, or what happens on failure. The description is adequate for a simple info retrieval but lacks explicit behavioral guarantees.

  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 a single, concise sentence that front-loads the action ('Return') and the resource. There is no fluff or repetition. Every word earns its place, making it highly efficient for a simple tool.

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

  Completeness3/5

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

  Given that there is no output schema, the description is the only source of what the agent can expect. It states the tool returns 'connection details', but does not specify the structure or content of those details (e.g., URLs, status, authentication info). This is a notable gap for an agent that needs to parse the result. For a 0-param tool, it is adequate but not rich enough to fully prepare the agent for the response format.

  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 tool has 0 parameters, and the schema is empty. According to the rubric, the baseline for 0 parameters is 4. The description adds nothing about parameters because there are none, and no additional semantics are needed. This is appropriate for a parameterless tool.

  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 clearly states the tool returns connection details for MCP server and target service, using the verb 'Return' and specifying a distinct resource. However, it does not distinguish itself from siblings like service_scope_info or service_list_endpoints beyond the term 'connection details', which is somewhat generic. It is clear but lacks explicit differentiation.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or alternative tools. An agent would have to infer usage from the name and the generic description, which is insufficient for making an informed selection among the listed siblings.

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

• fastly_set_configA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses that the operation is mutating and that it rejects tokens/secrets, and mentions an admin key requirement. However, it does not describe side effects (e.g., overwriting existing values), idempotency, or response/returns, leaving important behavioral gaps.

  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?

  One concise sentence that leads with the operation type and purpose, with no excess words. Every phrase carries meaning.

  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?

  Six parameters, no output schema, and no annotations demand a richer description. The current description does not specify required vs optional interplay (e.g., do userId and accountId need to be mutually exclusive?), the format of 'value', the authorization key purpose, or what the response indicates on success/failure. This leaves significant ambiguity for an agent.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It adds context that the configuration is non-secret and scoped to tenant/user or tenant/account, implying the role of userId and accountId, but it does not explain the 'key', 'value', or 'authorizationKey' parameters. The meaning of 'value' is particularly vague.

  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 states the verb 'persist' with resource 'configuration' and scope 'tenant/user or tenant/account', and explicitly labels the operation as 'Mutating', distinguishing it from the read-only sibling fastly_get_config. It also notes it rejects secrets, adding precision to its purpose.

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

  Usage Guidelines3/5

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

  The description implies usage for writing configuration but does not explicitly compare with alternatives like fastly_get_config. It provides a condition ('requires the admin key when configured') and a constraint ('reject tokens and secrets'), but no explicit when-to-use vs not-use guidance, so the agent must infer from the tool name.

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

• service_health_checkA
  3.5/5.0
  Behavior3/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. It discloses 'Read-only', which is a key behavioral trait, and states the token requirement. However, it does not mention what happens on invalid tokens, the response format, or any side effects beyond validation. For a simple read-only tool, this is adequate but minimal.

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

  Conciseness4/5

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

  Two sentences with no fluff; the read-only nature is front-loaded. It is concise and scannable, though it could potentially add a bit more context without losing brevity.

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

  Completeness3/5

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

  For a single-parameter validation tool with no output schema, the description is almost sufficient but leaves gaps: it doesn't state what a successful validation returns (e.g., a status code or boolean) or how to interpret failure. Since there is no output schema, the description should clarify the return contract; this omission makes it incomplete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain the parameter. It only says 'Requires a Fastly token', which merely restates the parameter name and required flag. It does not elaborate on what constitutes a user-scoped token, how to obtain it, or any format expectations beyond the schema's minLength constraint.

  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 the verb 'validate' against a specific resource ('user-scoped Fastly token') and even gives the exact endpoint (GET /tokens/self). This clearly distinguishes it from sibling tools like fastly_get_config or fastly_purge_service, which perform different operations.

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

  Usage Guidelines3/5

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

  The description provides a prerequisite (requires a Fastly token) but does not explicitly state when to prefer this tool over alternatives or when not to use it. It implies usage for token validation but lacks direct comparison to siblings like fastly_update_user_token or service_connection_info.

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

• fastly_list_versionsA
  3.6/5.0
  Behavior3/5

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

  No annotations are present, so the description carries full responsibility for behavioral disclosure. It does state 'Read-only', which is a positive behavioral trait, and mentions the need for a token. However, it does not describe the response format, error handling, or any side effects beyond being non-mutating. For a simple read operation this is adequate but minimal.

  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 a single, concise sentence that front-loads the key read-only trait and lists the required inputs. There is no redundancy or unnecessary detail, and every word contributes to the tool's understanding.

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

  Completeness3/5

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

  For a simple list operation with only two parameters and no output schema, the description covers the essential aspects (read-only, required identifiers). However, it does not specify the expected return format (e.g., an array of version objects), mention pagination, or note potential error conditions. It is acceptable for a basic tool but leaves some operational details unaddressed.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate by explaining parameter meaning. It only says 'Requires serviceId and a user token' – this essentially repeats the schema field names without adding semantics such as 'the identifier of the Fastly service' or 'the API token used for authentication'. The description adds minimal value beyond the schema itself.

  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 states a specific verb ('list') and a specific resource ('versions for a Fastly service'), clearly distinguishing it from sibling tools like fastly_list_services (which lists services) and fastly_get_config (which fetches configuration). The purpose is unambiguous.

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

  Usage Guidelines3/5

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

  The description notes the tool is read-only and requires serviceId and a user token, but does not provide explicit guidance on when to use this versus alternatives like fastly_list_services or fastly_get_config. The usage context is implied by the tool name and resource, but no direct differentiation or when-not-to-use conditions are stated.

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

• fastly_get_configA
  3.7/5.0
  Behavior4/5

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

  With no annotations provided, the description bears the full burden of behavioral disclosure. It explicitly states 'read-only' and 'Never stores secrets', which covers safety and side-effect concerns. It does not mention return format or error behavior, but for a simple get tool this is acceptable. The transparency is strong relative to the absence of annotations.

  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 a single, front-loaded sentence with zero filler. The critical 'read-only' qualifier leads, and the entire purpose is conveyed efficiently. Every word adds value.

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

  Completeness3/5

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

  Given no output schema, the description should ideally hint at what the tool returns. It does not describe the return value or failure modes, which could leave an agent uncertain about how to consume the result. However, the tool's simplicity mitigates this gap; the core action and scope are well defined. Still, a mention of response format would make it complete.

  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 0%, so the description must compensate. It adds meaning by explaining that the key can be either tenant/user or tenant/account, implying the optional userId and accountId are alternatives. However, it does not clarify that they are mutually exclusive, nor does it explain the 'key' and 'tenantId' beyond their names. Partial compensation for the coverage gap.

  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 uses a specific verb ('retrieve') and resource ('configuration key'), and clearly states the scope: tenant/user or tenant/account. It also distinguishes itself from the write sibling 'fastly_set_config' by being marked read-only. The mention of Postgres adds specificity.

  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 explicit guidance is given on when to use this tool versus alternatives. It does not state conditions, prerequisites, or mention that you should use 'fastly_set_config' for writes. The read-only hint makes its purpose clear, but the absence of any alternative routing or exclusion criteria leaves the agent to infer usage.

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

• fastly_purge_serviceA
  3.8/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 disclosure burden. It proactively labels the operation as 'high-risk mutation', requires confirmation of serviceId, and mentions the admin authorization key requirement. This goes beyond a typical operation description, though it stops short of detailing side effects like irreversibility or impact on all users.

  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?

  A single sentence that leads with the most important warning ('High-risk mutation'), then states the action, followed by essential usage notes. Every word earns its place with no redundancy.

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

  Completeness3/5

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

  The description is adequate for a straightforward purge operation, covering risk and auth requirements. However, it omits details like success/failure reporting, idempotency, or whether a network condition could cause partial purges. For a high-risk mutation, more operational context would improve completeness.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It hints at two parameters—serviceId ('confirm serviceId') and authorizationKey ('require MCP_ADMIN_AUTH_KEY')—but is silent on fastlyToken. This leaves one required parameter completely unexplained, failing to adequately define all inputs.

  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?

  States a precise action ('purge all cached content') on a specific resource ('Fastly service'), with a clear verb that distinguishes it from sibling tools like get_config and set_config. The description is unambiguous about scope and intent.

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

  Usage Guidelines3/5

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

  The description implies when to use it (to invalidate all cache) and provides cautionary context, but does not explicitly state use conditions, alternatives, or when not to use it. Siblings offer no competing purge tool, so the guidance is implicit rather than explicit.

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

• fastly_list_servicesA
  3.9/5.0
  Behavior3/5

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

  The description discloses the read-only nature and token-scoped visibility, which is important for a tool with no annotations. It does not mention pagination, rate limits, or error semantics, leaving some behavioral details unspecified.

  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?

  Two crisp sentences; the read-only hint is front-loaded, followed by the action and a forward pointer to sibling tools. No wasted words.

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

  Completeness4/5

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

  For a one-parameter read-only list, the description covers purpose, parameter semantics, and follow-up actions. It omits output details, but the chaining guidance suggests the returned data is compatible with fastly_list_versions or service_api_request, making it sufficiently complete for an agent to proceed.

  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?

  With 0% schema coverage, the description compensates by explaining the fastlyToken parameter's role ('supplied Fastly user token'). This adds meaning beyond the schema's minimal type and minLength, clarifying that the token determines which services are listed.

  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 states a clear verb (list) and resource (services) and specifies the scope ('visible to the supplied Fastly user token'). It differentiates from siblings by focusing on token-based listing, though it does not explicitly name alternatives.

  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 offers explicit follow-up guidance ('Follow with fastly_list_versions or service_api_request'), which implies when to use this tool as an initial discovery step. It lacks explicit exclusions, but the contextual cue is useful.

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

• fastly_update_user_tokenA
  4/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 the operation as 'High-risk mutation,' implying destructive/irreversible effects, and requires 'admin authorization,' signaling an auth prerequisite. It does not detail side effects or reversibility, but the risk warning and auth requirement are valuable beyond what the schema offers.

  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 concise, with high-impact wording front-loaded ('High-risk mutation'). It delivers key constraints in two sentences with no filler, efficiently communicating risk, purpose, and usage restrictions.

  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?

  Given 5 parameters, 0% schema coverage, no output schema, and no annotations, the description is insufficient. It does not explain how to properly set each parameter, especially the userId vs accountId choice, nor does it describe the effect of rotation (e.g., token invalidation). An agent would lack critical details for correct invocation.

  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 0%, so the description must compensate. It hints at 'scope' (likely tenantId, userId/accountId) and 'admin authorization' (likely authorizationKey), providing some mapping. However, it does not explicitly define each parameter or clarify the distinction between tenant/user and tenant/account, leaving significant gaps for an agent.

  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 action ('persist or rotate'), the resource ('one tenant/user or tenant/account Fastly token in Vault'), and explicitly excludes configuration use. It distinguishes itself from siblings like fastly_set_config, making its purpose unmistakable.

  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 gives clear context: it is for token persistence/rotation and explicitly says 'Never use for configuration,' providing a when-not condition. However, it does not name specific alternative tools or elaborate on when other tools are preferred, so it stops short of full routing guidance.

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