Fastly NGWAF MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (sites, rules, events, lists, etc.), but some overlap exists: manage_blacklist and manage_whitelist are clear opposites, but manage_lists (custom lists) could be confused with them. Tools like manage_alerts and manage_cloudwaf are distinct but their boundaries with other monitoring/configuration tools might require careful reading of descriptions.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout (e.g., create_corp_rule, list_sites, get_analytics, manage_users). All use snake_case with clear action prefixes (create, delete, get, list, manage, set, etc.), making them predictable and easy to parse for an agent.
Tool Count3/5
With 29 tools, the count is borderline high for a WAF management server. While it covers many aspects (rules, sites, events, analytics, configuration), it risks being overwhelming. A typical well-scoped server might have 15-25 tools; this is slightly above that range but not extreme.
Completeness5/5
The toolset provides comprehensive coverage for WAF management: CRUD for sites and rules (create, get, list, update, delete), event handling (list, expire), analytics, context management, credential setup, and utilities like testing connections. No obvious gaps are present; agents can perform full lifecycle operations.
Average 2.8/5 across 29 of 29 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 but fails completely. 'Manage' could imply any combination of create, read, update, or delete operations, but the description doesn't clarify which actions are supported, what permissions are required, whether operations are destructive, what happens on success/failure, or any rate limits. For a tool with 10 parameters that appears to handle potentially destructive operations (delete action), this lack of transparency is critical.
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 maximally concise at just three words. While this conciseness comes at the expense of usefulness, it's not verbose or poorly structured. Every word technically earns its place, though collectively they provide minimal value. The description is front-loaded with its only content.
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?
Given the tool's complexity (10 parameters, multiple actions including potentially destructive operations), the absence of annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, what 'managing' CloudWAF instances entails, or how different actions affect the system. For a multi-action tool that could create, update, or delete resources, this minimal description leaves the agent with insufficient context to use the tool effectively.
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?
The schema description coverage is 100%, so all parameters are documented in the input schema itself. The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
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 'Manage CloudWAF instances' is essentially a tautology that restates the tool name 'manage_cloudwaf' without adding meaningful specificity. It doesn't clarify what 'manage' entails or what 'CloudWAF instances' are, nor does it distinguish this tool from its many siblings like 'manage_alerts', 'manage_blacklist', etc. The description lacks a clear verb+resource combination that would help an agent understand the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With 27 sibling tools including many that manage related resources (sites, rules, alerts, etc.), the agent receives no help in selecting this specific tool for CloudWAF instance management. There's no mention of prerequisites, appropriate contexts, or comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Manage' implies both read and write operations, but the description doesn't specify permissions required, whether operations are destructive, rate limits, or what happens on success/failure. It mentions no behavioral traits beyond the vague 'manage' concept, leaving critical operational context undefined.
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?
The description is extremely concise at just two words, with no wasted language. However, this brevity comes at the cost of being under-specified - it's too short to be genuinely helpful. The structure is front-loaded but lacks substance, making it efficient but incomplete rather than optimally concise.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the multi-action nature (list/get/update/invite/delete), doesn't clarify what 'manage' entails operationally, and provides no context about return values or error conditions. The description fails to compensate for the lack of structured metadata.
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%, so the schema already documents all 5 parameters with descriptions and enums. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain parameter relationships, dependencies, or provide usage examples. The baseline of 3 is appropriate since the schema does the heavy lifting, but the description doesn't enhance understanding.
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 'Manage corporation users' is a tautology that essentially restates the tool name 'manage_users' with the addition of 'corporation'. It doesn't specify what management actions are possible (list, get, update, invite, delete) or what resources are affected. While it mentions 'corporation users', it doesn't distinguish this from sibling tools like 'manage_alerts' or 'manage_blacklist' in terms of resource type.
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 doesn't mention prerequisites, appropriate contexts, or exclusions. For example, it doesn't clarify whether this is for bulk operations versus individual user management, or how it differs from other user-related tools that might exist in the system (though none are listed among siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Get analytics data' which implies a read operation, but doesn't specify authentication requirements, rate limits, data freshness, or what happens when parameters like corpName/siteName aren't provided (though the schema indicates they use context defaults). The description lacks crucial behavioral context for a tool with 9 parameters.
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?
The description is extremely concise at just 7 words, which is efficient for its length. However, it's arguably too brief given the tool's complexity (9 parameters, no annotations). The parenthetical examples help but don't provide complete context. The structure is front-loaded with the main purpose, but could benefit from more complete guidance.
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?
For a tool with 9 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what analytics data is returned, how results are formatted, whether there's pagination, or what the 'etc.' encompasses. The description fails to compensate for the lack of structured metadata, leaving significant gaps in understanding how to effectively use this tool.
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%, so the schema already documents all 9 parameters thoroughly with descriptions and enums. The description adds minimal value beyond the schema - it mentions 'top attacks, timeseries' which aligns with the 'type' parameter enum, but doesn't explain the relationship between parameters (e.g., that groupBy is for top_attacks, tags/rollup are for timeseries). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get analytics data' which provides a basic verb+resource combination, but it's vague about what specific analytics data is retrieved. The parenthetical '(top attacks, timeseries, etc.)' gives some examples but doesn't clearly define the scope or differentiate this tool from potential sibling analytics tools (though none are listed in the sibling tools).
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. There's no mention of prerequisites, context requirements, or comparison with other tools that might retrieve similar data. The sibling tools list includes various management and retrieval tools, but no explicit analytics alternatives are mentioned, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('Get'), but doesn't specify permissions, rate limits, data freshness, or output format. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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?
The description is a single, straightforward sentence that efficiently conveys the core function without unnecessary words. It is front-loaded with the main action, making it easy to parse, though it could be slightly more informative without losing conciseness.
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 the lack of annotations and output schema, the description is insufficient for a tool that likely returns complex attack data. It doesn't explain what an 'attack overview' includes, how results are structured, or any behavioral traits like error handling, leaving the agent with incomplete context for effective use.
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?
The schema description coverage is 100%, with clear descriptions for all three parameters (corpName, from, until). The description adds no additional semantic context beyond the schema, such as explaining what 'attack overview' entails or how parameters interact, so it meets the baseline for adequate but unenriched parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get attack overview') and target ('for a corporation'), which clarifies the tool's purpose. However, it doesn't differentiate from sibling tools like 'get_analytics' or 'get_context' that might also provide overviews, and 'attack overview' remains somewhat vague without specifying what metrics or data it includes.
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 is provided on when to use this tool versus alternatives such as 'get_analytics' or 'list_events', nor are there any prerequisites or exclusions mentioned. The description only states what it does, without context for its application relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'monitoring attack patterns' which hints at security context, but doesn't disclose permissions needed, whether operations are destructive, rate limits, or what happens when alerts trigger. For a multi-action tool with potential mutations (create/update/delete), this is inadequate.
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?
The description is a single concise sentence that gets straight to the point without unnecessary words. However, it's arguably too brief for a 10-parameter tool with multiple actions, lacking the front-loaded detail needed for such complexity.
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?
For a complex tool with 10 parameters, multiple actions (including destructive ones), no annotations, and no output schema, the description is insufficient. It doesn't explain the tool's scope (corp/site level), what 'managing' entails operationally, or what the expected outcomes are. The agent must rely entirely on the input schema without contextual guidance.
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%, so parameters are well-documented in the schema itself. The description adds no additional parameter context beyond the generic 'manage alerts' statement. It doesn't explain relationships between parameters (e.g., alertId only needed for update/delete) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage alerts for monitoring attack patterns' states the general purpose (managing alerts) and domain (attack pattern monitoring), but is vague about what 'manage' entails. It doesn't specify the CRUD operations available or differentiate from sibling tools like 'manage_blacklist' or 'manage_whitelist' that also manage security-related items.
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 is provided on when to use this tool versus alternatives. With siblings like 'list_events', 'get_suspicious_ips', and various rule management tools, the description doesn't indicate whether this is for alert configuration vs. alert viewing, or when to prefer it over other monitoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'create' which implies a write/mutation operation, but doesn't mention permissions needed, whether creation is idempotent, error conditions, or what happens on success (e.g., returns rule ID). For a creation tool with 10 parameters, this leaves significant 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?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a tool with good schema documentation. Every word earns its place by stating the core action and scope.
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?
For a creation tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (return value), error handling, or how this tool fits into the broader rule management workflow with siblings like 'list_corp_rules' and 'delete_corp_rule'. The schema covers parameters well, but behavioral context is lacking.
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%, so the schema already documents all 10 parameters thoroughly with descriptions and enums. The description adds no additional parameter context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting, though the description could have explained parameter relationships or dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('create') and resource ('corporation-level rule'), which provides basic purpose. However, it doesn't specify what a 'corporation-level rule' entails or how it differs from sibling tools like 'create_site_rule' or 'list_corp_rules'. The purpose is clear but lacks differentiation from related tools.
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 like 'create_site_rule' or 'list_corp_rules'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permission requirements, whether this is idempotent, what happens on conflict, or any side effects. It also doesn't describe the return value or error conditions, leaving significant 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?
The description is extremely concise at just three words. It's front-loaded with the essential action and resource. There's zero wasted language or redundancy, making it efficient for quick scanning while still conveying the core function.
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?
For a complex creation tool with 12 parameters (4 required) and no annotations or output schema, the description is inadequate. It doesn't explain what a 'site-level rule' is, doesn't provide context about the rule system, and offers no guidance on parameter relationships or usage patterns. The agent would struggle to understand when and how to use this tool effectively.
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%, so the schema already documents all 12 parameters thoroughly with descriptions and enums. The description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create') and resource ('site-level rule'), which provides basic purpose. However, it's vague about what a 'site-level rule' entails and doesn't differentiate from sibling tools like 'create_corp_rule' or 'update_site'. The description lacks specificity about what types of rules can be created or their domain context.
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 is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'create_corp_rule' for corporation-level rules or 'update_site' for site modifications. There's no indication of prerequisites, appropriate contexts, or when this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Delete a site', implying a destructive mutation, but doesn't disclose critical behaviors: whether deletion is permanent, requires confirmation, affects related data, has rate limits, or needs specific authentication. This leaves significant gaps for a tool that performs deletion.
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, direct sentence 'Delete a site' with zero wasted words. It is appropriately sized for a simple tool and front-loaded with the core action, making it highly efficient and easy to parse.
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 the tool's complexity (destructive deletion with 2 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like permanence, side effects, or error handling, which are crucial for safe invocation. The schema covers parameters well, but overall context is insufficient for a mutation tool.
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 parameters 'corpName' and 'siteName' documented as using context defaults if not provided. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a site' states the action (delete) and resource (site), which provides a basic purpose. However, it doesn't differentiate from sibling tools like 'delete_corp_rule' or 'delete_site_rule', nor does it specify what kind of site (e.g., web, physical) or scope, making it vague beyond the minimal definition.
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 is provided on when to use this tool versus alternatives like 'update_site' or 'list_sites', nor any prerequisites (e.g., site must exist, permissions required). The description only states what it does, not when or why to invoke it, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool retrieves details but does not specify if it's read-only, requires authentication, has rate limits, or what happens if parameters are omitted. This is a significant gap for a tool with potential context-dependent behavior.
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, efficient sentence with no wasted words. It is front-loaded with the core purpose, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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 the lack of annotations and output schema, the description is incomplete. It does not explain what 'details' are returned, error conditions, or behavioral traits like context defaults. For a tool with two parameters and no structured output, more context is needed to guide effective use.
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?
The input schema has 100% description coverage, documenting both parameters and their default context usage. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get details of a specific site', which is clear but vague. It specifies the verb ('Get') and resource ('site'), but does not differentiate from sibling tools like 'list_sites' or 'get_corp_overview', nor does it clarify what 'details' entail. This makes it minimally adequate but lacking 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'list_sites' for broader listings or 'get_corp_overview' for corporation-level details, nor does it specify prerequisites or exclusions. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states this is a read operation ('Get'), but doesn't mention permissions, rate limits, data freshness, or what the output looks like (e.g., format, pagination). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
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 the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, how 'suspicious' is defined, or behavioral aspects like error handling. For a tool that likely involves security data, more context is needed to use it effectively.
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%, so the schema fully documents the three parameters (corpName, siteName, limit) with descriptions. The description adds no additional parameter information beyond what's in the schema, but since the schema is comprehensive, a baseline score of 3 is appropriate as the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of suspicious IP addresses' clearly states the action (get) and resource (suspicious IP addresses), but it's somewhat vague about scope and criteria. It doesn't specify what makes an IP 'suspicious' or how the list is generated, and it doesn't differentiate from sibling tools like 'manage_blacklist' or 'search_requests' which might also involve IP addresses.
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. With siblings like 'manage_blacklist' (which might handle IP blocking) and 'search_requests' (which could filter by IP), there's no indication of this tool's specific context or prerequisites, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool lists rules but does not cover critical behaviors like pagination handling (implied by 'page' and 'limit' parameters), authentication requirements, rate limits, or output format. This leaves significant gaps for an agent to understand operational traits.
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, clear sentence with no wasted words, making it front-loaded and easy to parse. It efficiently conveys the core action without redundancy or unnecessary detail, earning full marks for conciseness.
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 the tool's complexity (5 parameters, no output schema, no annotations), the description is insufficient. It lacks details on output format, error handling, or behavioral context like pagination. Without annotations or an output schema, the description should provide more completeness to guide effective tool use, but it falls short.
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%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or default behaviors. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List rules for a specific site' clearly states the verb ('list') and resource ('rules for a specific site'), making the purpose understandable. However, it lacks specificity about what 'rules' entail (e.g., security, configuration) and does not differentiate from sibling tools like 'list_corp_rules' or 'list_events', leaving ambiguity in scope.
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 is provided on when to use this tool versus alternatives. It does not mention sibling tools like 'list_corp_rules' for corporation-level rules or 'get_site' for site details, nor does it specify prerequisites such as needing site context. The description implies usage for listing rules but offers no contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies CRUD operations via 'manage' but doesn't disclose permissions, side effects, rate limits, or response format. For a tool with 10 parameters and multiple actions, this is inadequate.
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, efficient sentence with no wasted words. It's appropriately sized for a tool name that implies broad functionality, though this conciseness comes at the cost of detail.
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?
For a complex tool with 10 parameters, multiple actions, no annotations, and no output schema, the description is insufficient. It doesn't explain the tool's role in the system, how it differs from similar sibling tools, or what to expect upon invocation, leaving significant gaps for the agent.
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%, so parameters are well-documented in the schema. The description adds marginal value by hinting at list types ('IP, country, string, etc.') which aligns with the 'type' enum, but doesn't explain parameter interactions or usage beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage custom lists (IP, country, string, etc.)' states a general purpose but lacks specificity. It mentions the resource ('custom lists') and examples of list types, but doesn't specify the verb beyond 'manage' or differentiate from sibling tools like 'manage_blacklist' or 'manage_whitelist' that might handle similar list types.
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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or compare to sibling tools like 'manage_blacklist' or 'manage_whitelist', leaving the agent to infer usage based on the action parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Manage' implies mutation capabilities, but the description doesn't specify permissions required, rate limits, whether changes are reversible, or what the response looks like. It mentions 'whitelist (allowlist)' which adds some context about security/IP filtering, but lacks details on behavioral traits like side effects or error conditions.
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 extremely concise with a single phrase, 'Manage IP whitelist (allowlist)', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, though this brevity contributes to gaps in other dimensions.
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 the tool's complexity (7 parameters, mutation capabilities, no annotations, no output schema), the description is incomplete. It doesn't explain the multi-action nature (list/add/remove), how parameters interact conditionally, what the tool returns, or how it fits into the broader context with sibling tools. For a mutation tool with rich parameters, more guidance is needed.
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%, so the schema already documents all 7 parameters with their purposes and constraints (e.g., action enum values, conditional usage for ip/note/entryId). The description adds no parameter-specific information beyond what's in the schema, such as explaining how corpName/siteName defaults work or format details for expires. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage IP whitelist (allowlist)' states the resource (IP whitelist/allowlist) and the general action (manage), but it's vague about what 'manage' entails. It doesn't specify the specific operations available (list, add, remove) or differentiate from sibling tools like manage_blacklist, manage_lists, or manage_alerts. The description provides basic purpose but lacks 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?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like manage_blacklist for IP blocking, manage_lists for other list types, or create/delete rules for related operations. There's no context about prerequisites, such as needing corp/site context from set_context or get_context tools. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't mention required permissions, whether changes are reversible, potential side effects, or what happens to unspecified configuration fields. This leaves significant behavioral gaps for a tool that modifies site settings.
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 extremely concise at just three words with zero wasted language. It's front-loaded with the essential action and resource. While it may be too brief for completeness, as a standalone statement it achieves maximum efficiency.
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?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'configuration' encompasses, what happens during updates, or what the tool returns. The agent must rely entirely on the input schema for understanding, leaving behavioral and output aspects unspecified.
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?
The schema description coverage is 100%, providing good documentation for all 7 parameters. The description adds no parameter-specific information beyond the general 'configuration' reference. Given the comprehensive schema coverage, the baseline score of 3 is appropriate as the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update site configuration' clearly states the action (update) and resource (site configuration), which is better than a tautology. However, it lacks specificity about what aspects of configuration are updated and doesn't distinguish this tool from potential siblings like 'create_site' or 'get_site' beyond the verb difference.
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. With siblings like 'create_site', 'delete_site', and 'get_site' available, there's no indication of prerequisites, appropriate contexts, or distinctions between these operations. The agent must infer usage from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates a site but doesn't mention what permissions are required, whether this is a destructive operation that affects existing data, what happens on success/failure, or any rate limits. For a creation tool with zero annotation coverage, this leaves significant 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?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a creation tool and front-loads the essential information. Every word earns its place.
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?
For a creation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, what the return value might be, or important behavioral aspects like error conditions. The agent lacks context about the tool's full operation despite the good schema coverage.
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%, so the schema already documents all 7 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies 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 clearly states the action ('Create') and resource ('new site in a corporation'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'update_site' or 'delete_site', but the verb 'Create' inherently distinguishes it from those operations. The description is specific enough to understand what the tool does without being tautological.
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 like 'update_site' or 'list_sites'. There's no mention of prerequisites, such as needing an existing corporation, or context about when site creation is appropriate versus other operations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool deletes a rule, implying a destructive mutation, but doesn't disclose behavioral traits such as permissions required, whether deletion is permanent or reversible, error handling, or side effects. This is a significant gap for a destructive tool.
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, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.
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 the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address critical context like what 'delete' entails, success/error responses, or dependencies, leaving the agent with insufficient information for safe and effective use.
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 parameters 'corpName' and 'ruleId' documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the relationship between parameters or deletion constraints. Baseline 3 is appropriate as the schema handles parameter documentation.
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 action ('Delete') and target ('a corporation-level rule'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'delete_site_rule' or 'delete_site', which target different resources at potentially different scopes.
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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing rule existence), exclusions, or comparisons to siblings like 'delete_site_rule' or 'list_corp_rules' for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Delete' implies a destructive mutation, but the description doesn't state whether this action is reversible, what permissions are required, or what happens upon deletion (e.g., if related data is affected). For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational context.
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, efficient sentence with zero waste—it directly states the action and target. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as confirmation of deletion, error handling, return values, or impact on related resources. The schema covers parameters well, but behavioral and output details are missing, making it inadequate for safe and informed use.
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%, so the schema fully documents all three parameters (corpName, siteName, ruleId) with their types and descriptions. The description adds no additional parameter semantics beyond implying 'site-level' relates to siteName. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Delete') and resource ('a site-level rule'), making the purpose immediately understandable. It distinguishes from sibling tools like 'delete_corp_rule' by specifying 'site-level' rather than corporate-level. However, it doesn't explicitly contrast with other deletion tools like 'delete_site' or 'delete_corp_rule' in the description itself.
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 doesn't mention prerequisites (e.g., needing ruleId), when not to use it, or refer to sibling tools like 'delete_corp_rule' for corporate-level deletions. The agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's for discovery and mentions authentication, but lacks details on return format (e.g., structure, pagination), performance (e.g., speed, limits), or side effects (e.g., caching). For a tool with no annotation coverage, this is a significant gap in transparency about how it behaves beyond its basic purpose.
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, clear sentence that efficiently conveys the tool's core function without unnecessary words. It's front-loaded with the main action ('Discover') and resources, making it easy to parse. Every part of the sentence earns its place by specifying scope and authentication context.
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 the tool's moderate complexity (discovering multiple resource types), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'discover' entails (e.g., returns a list, details permissions), how results are structured, or handle edge cases. For a tool with no structured behavioral or output data, more context is needed to adequately guide an agent.
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?
The input schema has 100% description coverage, with one optional parameter 'corpName' documented as 'Specific corporation to explore (optional)'. The description adds no parameter details beyond what the schema provides, such as explaining how 'corpName' filters results or its format. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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's purpose: 'Discover available corporations and sites for the authenticated user.' It specifies the verb ('discover') and resources ('corporations and sites'), and distinguishes it from siblings like 'list_corps' or 'list_sites' by implying it returns both corporations and sites in one operation. However, it doesn't explicitly differentiate scope or format from those siblings, preventing a perfect score.
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 like 'list_corps' or 'list_sites'. It mentions 'for the authenticated user', which implies a prerequisite of authentication, but offers no explicit when/when-not instructions or comparisons to sibling tools. This leaves usage context largely implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the effect ('unblock IP'), which implies a mutation with security implications, but doesn't cover permissions, reversibility, side effects, or error handling. For a tool that likely modifies event states and IP blocks, this is a significant gap in transparency.
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, efficient sentence with zero waste. It front-loads the core action and effect, making it easy to parse. Every word earns its place by clarifying the tool's purpose.
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 the complexity (a mutation tool with security implications), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, consequences, or response format, leaving the agent under-informed for safe and effective use.
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%, so the schema fully documents all three parameters. The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema handles all parameter documentation.
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 action ('manually expire') and resource ('an event'), with additional context about the effect ('unblock IP'). It distinguishes from siblings like 'list_events' or 'manage_blacklist' by focusing on expiration rather than listing or management. However, it doesn't explicitly differentiate from potential similar tools like 'delete_event' if they existed.
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 is provided on when to use this tool versus alternatives. Siblings include 'list_events' for viewing and 'manage_blacklist' for IP management, but the description doesn't mention prerequisites, timing, or exclusions. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool lists rules but doesn't mention whether it's read-only, paginated (implied by parameters but not described), requires authentication, or has rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action and scope, making it highly concise and well-structured.
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 a list operation with pagination parameters, the description is incomplete. It doesn't address behavioral aspects like pagination handling, return format, or error conditions, which are crucial for an agent to use this tool effectively in a real-world context.
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%, so the schema fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining the 'corpName' default behavior in more detail or clarifying the 'type' enum values. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('List') and resource ('rules at corporation level'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_site_rules' or 'list_corps' beyond the 'corporation level' qualifier, which is somewhat implied but not explicit.
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 is provided on when to use this tool versus alternatives like 'list_site_rules' or 'get_corp_overview'. The description lacks any mention of prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'List security events' but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, any rate limits, pagination behavior, or what the output format looks like. For a tool with 7 parameters and no output schema, this is a significant gap.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('List security events (attacks, blocks, etc.)') directly contributes to understanding the tool's function.
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?
For a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like safety, authentication, or output format, and while schema coverage is high, the description itself lacks context needed for effective agent use without trial-and-error.
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%, providing detailed parameter documentation. The description adds minimal value by implying filtering capabilities ('attacks, blocks, etc.') but doesn't elaborate on parameter interactions or usage beyond what the schema already specifies. Baseline 3 is appropriate given high schema coverage.
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 verb ('List') and resource ('security events') with examples of event types ('attacks, blocks, etc.'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_requests' or 'get_analytics' that might also retrieve security-related data, preventing a perfect score.
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. With siblings like 'search_requests' and 'get_analytics' that could overlap in functionality, there's no indication of context, prerequisites, or exclusions for selecting this specific listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as pagination behavior (implied by 'page' and 'limit' params but not explained), rate limits, authentication requirements, or whether it's a read-only operation (though 'List' suggests it). This leaves significant gaps for agent decision-making.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a list operation, earning its place without redundancy.
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 4 parameters, the description is incomplete. It lacks context on return format (e.g., list structure, error handling), usage constraints, or how it fits with siblings like 'list_corps'. For a tool with moderate complexity, this minimal description leaves the agent under-informed.
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%, so the schema fully documents all 4 parameters. The description adds no additional meaning beyond implying filtering via 'query' and pagination via 'page'/'limit', which are already clear in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'List sites in a corporation' clearly states the verb ('List') and resource ('sites'), with scope ('in a corporation'). It distinguishes from siblings like 'get_site' (singular retrieval) and 'list_corps' (different resource), but doesn't explicitly contrast with 'search_requests' or 'list_events' which might overlap in domain.
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 is provided. It doesn't mention when to choose 'list_sites' over 'get_site' (for single site details) or 'search_requests' (for filtering requests), nor does it specify prerequisites like needing corporation context or authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool manages an IP blacklist, implying mutation capabilities (add/remove actions), but doesn't disclose critical details like required permissions, whether changes are reversible, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
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 extremely concise with a single phrase, front-loaded and zero waste. Every word earns its place by directly stating the tool's purpose without redundancy or fluff.
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 the tool's complexity (7 parameters, mutation actions, no annotations, and no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, making it inadequate for an agent to fully understand how to invoke this tool correctly in practice.
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?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional meaning beyond the schema, such as explaining dependencies between parameters (e.g., ip and note are for add action, entryId for remove). Baseline is 3 when the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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's purpose as managing an IP blacklist/blocklist, which is a specific verb ('manage') and resource ('IP blacklist'). However, it doesn't differentiate this from sibling tools like 'manage_whitelist' or 'manage_lists' beyond the obvious blacklist focus, and the title is null, leaving some ambiguity about the exact scope.
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 doesn't mention sibling tools like 'manage_whitelist' or 'manage_lists', nor does it specify prerequisites such as needing context defaults for corpName and siteName. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Search requests with advanced filtering' implies a read-only operation but doesn't specify pagination behavior (implied by page/limit parameters), rate limits, authentication requirements, or what constitutes 'advanced filtering' beyond the parameters. The description is too vague about operational behavior.
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, efficient sentence with zero wasted words. It's appropriately sized for a search tool and front-loads the core functionality. Every word ('search', 'requests', 'advanced filtering') contributes essential information.
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?
For a search tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a 'request' in this context, what format results return, how pagination works, or what 'advanced filtering' entails beyond the parameter names. The description leaves too many operational questions unanswered.
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%, so all parameters are documented in the schema itself. The description mentions 'advanced filtering' which aligns with the query parameter but doesn't add meaningful semantic context beyond what the schema already provides. No syntax examples or filtering logic details are included in the description.
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 verb ('search') and resource ('requests'), specifying 'advanced filtering' as a key capability. It distinguishes itself from siblings like 'list_events' or 'list_sites' by focusing on search functionality rather than simple listing. However, it doesn't explicitly differentiate from potential search alternatives that might exist.
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. With siblings like 'list_events' and 'list_sites' available, there's no indication whether this tool is preferred for filtered searches or when basic listing would suffice. No prerequisites, exclusions, or comparative context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool sets credentials but doesn't cover critical aspects like whether this is a one-time setup, if it overwrites existing credentials, authentication requirements, rate limits, or error handling. This leaves significant gaps for a mutation tool.
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, efficient sentence with zero waste, front-loading the key action and resource. It is appropriately sized for a simple tool with two parameters.
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 the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It fails to address behavioral traits, return values, or error conditions, making it inadequate for safe and effective use by an AI agent.
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?
The input schema has 100% description coverage, clearly documenting both parameters (email and token). The description adds minimal value by restating the parameters without providing additional context like format examples or validation rules, aligning with the baseline for high schema coverage.
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 action ('Set') and the resource ('Fastly NGWAF API credentials'), specifying the exact credentials (email and access token). It distinguishes from siblings like 'test_connection' or 'set_context' by focusing on credential configuration, though it doesn't explicitly contrast with 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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites (e.g., needing credentials from Fastly), or exclusions. It lacks context for usage relative to siblings like 'test_connection' or other setup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get[s] the current context' but doesn't explain what 'current context' means operationally, whether it's cached or fetched, if it requires authentication, or what happens if no context is set. This leaves key behavioral traits 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?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. It lacks context on what 'current context' entails, how it's used, or what the return value includes, making it incomplete for guiding an agent effectively in a system with many sibling tools.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it implies the tool fetches context without inputs, aligning with the schema. Baseline is 4 for zero parameters.
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 verb 'Get' and the resource 'current context (corp and site names)', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'set_context' or 'discover_environment', which might also relate to context, so it doesn't fully distinguish itself.
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 doesn't mention prerequisites, such as whether context needs to be set first, or compare it to siblings like 'set_context' or 'get_corp_overview', leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions authentication ('authenticated user') but lacks details on permissions, rate limits, pagination, or return format. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, clear sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.
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 the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is adequate as a basic overview but incomplete for operational use. It doesn't explain what 'corporations' entails in this context or how results are returned, which could hinder an agent's ability to use it effectively without trial and error.
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 schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose without redundant parameter information, earning a high baseline score for this dimension.
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 verb ('List') and resource ('corporations') with scope ('accessible to the authenticated user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_corp_overview' or 'list_sites', which might have overlapping or related functionality.
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. With siblings like 'get_corp_overview' and 'list_sites', there's no indication of differences in scope, format, or use cases, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool sets a default context but doesn't disclose behavioral traits such as whether this is a persistent change, if it requires specific permissions, what happens on errors, or if it affects all subsequent tools globally. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that is front-loaded with the core action ('Set the default corporation and site context') and purpose ('for subsequent operations'). There is zero waste, and every word earns its place, making it highly concise and well-structured.
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 the tool's complexity (a mutation affecting global state), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like persistence, error handling, or impact on other tools. For a context-setting tool with significant implications, more detail is needed to ensure safe and correct usage.
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 clear descriptions for 'corpName' and 'siteName' in the input schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format, constraints, or examples). Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate or add value.
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 action ('Set') and the target ('default corporation and site context'), specifying it's for 'subsequent operations'. It distinguishes from siblings like 'get_context' (which retrieves rather than sets) and 'set_credentials' (which handles authentication). However, it doesn't explicitly differentiate from all siblings (e.g., 'update_site' might also affect site context).
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 by stating 'for subsequent operations', suggesting this tool should be used to establish a context before other operations. However, it doesn't provide explicit guidance on when to use it versus alternatives (e.g., whether to use this vs. setting context per-operation), nor does it mention prerequisites or exclusions. The context is clear but lacks detailed alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 states what the tool does (test connection, validate credentials) but doesn't disclose behavioral traits like what happens on failure, whether it makes actual API calls, rate limits, or what the output looks like. It's adequate but lacks operational details.
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 perfectly concise at 6 words, front-loading the core purpose with zero wasted words. Every element ('test', 'API connection', 'validate credentials') earns its place by contributing essential information.
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 the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is complete enough to understand the basic purpose. However, for a credential validation tool, additional context about what constitutes success/failure or security implications would be helpful, especially with no output schema to clarify return values.
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 with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately focuses on the tool's purpose rather than repeating the obvious absence of parameters.
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 purpose with specific verbs ('test', 'validate') and resources ('API connection', 'credentials'), making it immediately understandable. It distinguishes itself from all sibling tools, which perform CRUD operations on various resources rather than connection testing.
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 implies usage context (testing API connectivity and credential validation), which is clear for this type of diagnostic tool. However, it doesn't explicitly state when NOT to use it or mention alternatives (e.g., whether other tools might also validate credentials indirectly).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![FastlyMCP MCP server](https://glama.ai/mcp/servers/purpleax/FastlyMCP/badges/card.svg)](https://glama.ai/mcp/servers/purpleax/FastlyMCP)

Score Badge

Copy to your README.md:

[![FastlyMCP MCP server](https://glama.ai/mcp/servers/purpleax/FastlyMCP/badges/score.svg)](https://glama.ai/mcp/servers/purpleax/FastlyMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/purpleax/FastlyMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server