Hyperfabric MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are well-organized by resource categories (auth, devices, fabrics, nodes, etc.) with clear distinctions between actions like get, add, update, and delete. However, some potential overlaps exist, such as multiple 'add' tools for different sub-resources within a category that might be confusing if the agent doesn't carefully parse the resource type.
Naming Consistency5/5
Naming follows a highly consistent pattern: resourceActionResource or resourceActionResources (e.g., authGetUser, fabricsAddFabrics, nodesUpdatePort). All tools use camelCase uniformly, and the verb-noun structure is predictable across all 79 tools, making them easy to parse and understand.
Tool Count2/5
With 79 tools, the count is excessive for typical MCP server purposes, likely overwhelming for agents and users. While the domain (network fabric management) is complex, this many tools suggests over-fragmentation of operations that could have been consolidated, making it heavy and difficult to navigate.
Completeness5/5
The tool set provides comprehensive CRUD coverage across all major resources (fabrics, nodes, ports, VRFs, VNIs, etc.), including lifecycle operations like commit, revert, and review for candidates. No obvious gaps are present; agents can perform full management workflows without dead ends.
Average 2.8/5 across 79 of 79 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?
No annotations are provided, so the description must fully disclose behavioral traits. 'Delete all connections' implies a destructive, irreversible operation but doesn't specify permissions required, side effects, or what 'all connections' entails (e.g., all connections in a fabric). It lacks critical details like confirmation prompts, error handling, or impact on system state, making it inadequate for safe use.
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 just two words, 'Delete all connections,' which is front-loaded and wastes no space. While it's under-specified, it earns a high score for brevity and lack of redundancy, as every word serves a purpose in stating the core action.
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 (destructive deletion operation), lack of annotations, and no output schema, the description is severely incomplete. It doesn't explain what 'connections' are, the scope of deletion, return values, or error conditions. For a tool that could have significant system impact, this minimal description fails to provide necessary context 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?
The input schema has 100% description coverage, with 'fabricId' clearly documented as 'The fabric id or name.' The description adds no parameter information beyond this. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete all connections' states a verb ('Delete') and resource ('connections'), but it's vague about scope and lacks specificity. It doesn't clarify what 'connections' are (e.g., network connections, fabric connections) or distinguish from sibling tools like 'fabricsDeleteFabricConnection' (singular) or 'fabricsSetFabricConnections'. This is a tautology that mostly restates the tool name without meaningful elaboration.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and fails to differentiate from sibling tools like 'fabricsDeleteFabricConnection' (singular deletion) or 'fabricsSetFabricConnections' (setting connections). This leaves the agent with no 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 states 'Get a specific sub-interface', implying a read-only operation, but doesn't clarify authentication requirements, rate limits, error handling, or response format. For a tool with 5 parameters and no output schema, this lack of behavioral context is a significant gap, leaving the agent uncertain about execution outcomes.
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 is appropriately sized for a simple retrieval tool and front-loaded with the core action. While it lacks detail, its brevity is not due to verbosity but under-specification, which is penalized 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 (5 parameters, 3 required) and lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'sub-interface' is, how it relates to nodes and fabrics, what data is returned, or potential side effects. For a tool in a domain with many siblings (e.g., network management), more context is needed 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters documented in the input schema (e.g., fabricId, nodeId, subInterfaceId, candidate, includeMetadata). The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or usage examples. According to the rules, the baseline is 3 when schema coverage is high (>80%) and no param info is in the description.
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 'Get a specific sub-interface' is a tautology that restates the tool name 'nodesGetNodeSubInterface' without adding meaningful specificity. It doesn't clarify what a 'sub-interface' is in this context (e.g., network interface component) or distinguish it from sibling tools like 'nodesGetNodeSubInterfaces' (plural) or 'nodesUpdateNodeSubInterface'. The purpose is vague beyond the basic verb-noun structure.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'nodesGetNodeSubInterfaces' (for listing multiple sub-interfaces) or 'nodesUpdateNodeSubInterface' (for modifications), nor does it specify prerequisites, error conditions, or contextual constraints. Usage is implied only through the generic 'get' action, which is insufficient for effective tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers only the basic action 'Get'. It doesn't indicate whether this is a read-only operation, if it requires specific permissions, what the response format might be, or any error conditions. 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 extremely concise at just four words, with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of completeness. Every word serves a purpose, even if that purpose is minimal.
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 what 'port' means in this context, what data is returned, or how it differs from similar tools. The high parameter count and lack of structured metadata require more descriptive context than provided.
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 all 5 parameters clearly documented. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate or 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 'Get a specific port' is a tautology that merely restates the tool name 'nodesGetPort' without adding meaningful context. It doesn't specify what kind of port (fabric port, management port, etc.) or what information is retrieved, making it minimally informative beyond the name itself.
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 no guidance on when to use this tool versus alternatives like 'nodesGetPorts' (plural) or 'nodesGetManagementPort'. There's no mention of prerequisites, appropriate contexts, or distinctions from sibling tools, leaving the agent with no usage direction.
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. 'Add a fabric' implies a creation/mutation operation but fails to describe critical behaviors: whether this requires specific permissions, if it's idempotent, what happens on conflicts (e.g., duplicate names), or what the response contains. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that are front-loaded: the first states the purpose, and the second provides usage syntax. There's no unnecessary verbosity, though the second sentence could be more informative about the tool's behavior rather than just argument passing.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'adding a fabric' entails operationally, what validation occurs, what the return value looks like, or error conditions. Given the complexity implied by the detailed input schema, the description should provide more context about the tool's behavior and outcomes.
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 comprehensive documentation for the single 'fabrics' parameter and its nested properties. The description adds no parameter semantics beyond what's in the schema, only mentioning how to pass arguments. With high schema coverage, the baseline score of 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a fabric' is a tautology that restates the tool name without providing meaningful context. While it specifies the verb ('Add') and resource ('fabric'), it lacks specificity about what a fabric is or what the operation entails, making it vague compared to more detailed sibling tools like 'fabricsUpdateFabric' or 'fabricsDeleteFabric'.
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 mentions how to pass arguments but offers no context about prerequisites, when this operation is appropriate, or how it differs from sibling tools like 'fabricsUpdateFabric' or 'fabricsGetFabric'. This leaves the agent without usage direction.
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 a read operation ('Get'), implying it's non-destructive, but fails to disclose critical behavioral traits like authentication needs, rate limits, pagination, or response format. For a security-related 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.
Conciseness4/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 and clear, though it could benefit from slightly more detail given the lack of annotations and sibling tool 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 complexity of authentication tools, no annotations, no output schema, and rich sibling tools, the description is incomplete. It doesn't explain return values, error conditions, or how it fits into the broader auth workflow, leaving the agent under-informed for secure operations.
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 the single parameter 'includeMetadata' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples of metadata or implications of including it. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of bearer tokens' clearly states the verb ('Get') and resource ('bearer tokens'), but it's vague about scope and lacks differentiation from sibling tools like 'authGetBearerToken' (singular) or 'authCreateBearerTokens'. It doesn't specify whether this retrieves all tokens, active tokens, or tokens for a specific 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 on when to use this tool versus alternatives like 'authGetBearerToken' (singular) or 'authCreateBearerTokens'. The description offers no context about prerequisites, such as authentication requirements, or exclusions, leaving the agent to infer usage 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 full burden. It only states the action ('Get the list') without disclosing behavioral traits like whether it's read-only (implied but not explicit), pagination, rate limits, authentication needs, or what happens if no connections exist. This leaves significant gaps for safe and effective use.
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, efficient sentence ('Get the list of connections.') with no wasted words. However, it's front-loaded but overly brief, potentially under-specifying the context, which slightly reduces its effectiveness despite good 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 no annotations, no output schema, and a read operation with 2 parameters, the description is incomplete. It lacks details on return format (e.g., list structure), error conditions, or how it interacts with sibling tools, making it insufficient for an agent to fully understand the tool's behavior and 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 both parameters (fabricId and candidate). The description doesn't add any meaning beyond the schema, such as examples or edge cases, but since the schema is well-documented, a baseline score of 3 is appropriate as it 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 the list of connections' states the basic action (get/list) and resource (connections), but it's vague about what type of connections (fabric connections, based on tool name and sibling tools). It doesn't distinguish from sibling tools like 'fabricsGetFabricConnection' (singular) or 'fabricsAddFabricConnections', leaving ambiguity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include 'fabricsGetFabricConnection' (singular), 'fabricsAddFabricConnections', and 'fabricsSetFabricConnections', but the description doesn't mention these or specify contexts like retrieving all connections vs. a specific one, making it hard for an agent to choose correctly.
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 implies a mutation ('Comment on' suggests adding data), but doesn't disclose behavioral traits like whether this requires specific permissions, if comments are editable, rate limits, or what happens on success/failure. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly state the purpose and basic usage. It's front-loaded with the core action. However, the second sentence is somewhat redundant with the schema and could be more informative about context rather than just repeating argument passing.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'commenting' entails in this system, expected outcomes, error conditions, or how it fits with the candidate lifecycle (e.g., vs. commit/revert). Given the complexity implied by sibling tools, more context 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 three parameters (fabricId, name, comments). The description mentions 'resource ID and the fields to update' but doesn't add meaningful semantics beyond what's in the schema (e.g., format of fabricId, purpose of name beyond being required). 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 'Comment on a specific candidate configuration' which provides a clear verb ('Comment on') and resource ('candidate configuration'), but it's somewhat vague about what 'comment' entails (e.g., adding review comments). It doesn't distinguish from siblings like fabricsCommitFabricCandidate or fabricsRevertFabricCandidate, which also operate on candidates.
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 mentions 'pass the resource ID and the fields to update as arguments' but doesn't specify prerequisites, appropriate contexts, or when to choose this over other candidate-related tools like commit or revert.
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 this is an update operation but doesn't explain whether this replaces the entire connections list or merges with existing ones, what permissions are required, whether changes are reversible, or what happens on success/failure. For a mutation tool with complex nested parameters, this is a significant gap in behavioral context.
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 brief with two sentences that get straight to the point without unnecessary elaboration. However, the second sentence could be more informative about what 'fields to update' means in context. Overall, it's efficiently structured but could benefit from slightly more substantive content.
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 that updates complex fabric connections with nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain the mutation behavior, error conditions, relationship to sibling tools, or what constitutes a successful update. The agent lacks sufficient context to use this tool effectively in the broader fabric management system.
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 both parameters (fabricId and connections) thoroughly with detailed descriptions of all nested properties. The description adds no additional parameter semantics beyond what's in the schema, merely stating to 'pass the resource ID and the fields to update as arguments.' This meets the baseline for high schema coverage.
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 'Update the list of connections' which provides a basic verb+resource combination, but it's vague about what exactly is being updated (connections within a fabric) and doesn't distinguish this from sibling tools like fabricsAddFabricConnections or fabricsDeleteFabricConnections. The purpose is understandable but lacks specificity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like fabricsAddFabricConnections or fabricsDeleteFabricConnections. It only gives basic usage instructions ('pass the resource ID and the fields to update as arguments') without context about appropriate scenarios, prerequisites, or exclusions. This leaves the agent with insufficient context for tool 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 full burden. It states this is an 'Add' operation, implying a write/mutation, but doesn't disclose any behavioral traits: no mention of permissions required, whether it's idempotent, if it validates input, what happens on failure, or what the response contains. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The second sentence is somewhat redundant with the schema but provides a minimal usage example. No unnecessary words, though it could be more informative given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (adding nodes to a fabric with nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the fabric context, what happens after addition, error conditions, or relationship to other node tools. For a mutation tool in a networked system, this leaves critical gaps.
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 both parameters (fabricId and nodes). The description adds no meaning beyond what the schema provides—it doesn't explain what a 'fabric' is, clarify the relationship between fabricId and nodes, or provide examples beyond a generic syntax hint. Baseline 3 is appropriate when the schema does all the work.
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 ('Add') and resource ('one or more nodes'), but it's vague about what 'nodes' are in this context. It doesn't differentiate from sibling tools like 'nodesAddManagementPorts' or 'nodesAddNodeLoopbacks', which also add things to nodes. The purpose is understandable but lacks specificity about the domain (fabric networking).
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 doesn't mention prerequisites (e.g., needing an existing fabric), exclusions, or related tools like 'nodesUpdateFabricNode' or 'nodesDeleteFabricNode'. The second sentence is about parameter syntax, not usage context, so it offers no real guidelines.
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 'Get' implying a read operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or response format. For a tool with no annotations, this leaves critical operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get a specific node.') with no wasted words. It's appropriately sized for a simple tool, though it could be more informative without sacrificing brevity.
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 vague description, the tool definition is incomplete. The description doesn't explain what a 'node' is, how it relates to fabrics, or what the return values look like, leaving significant gaps for an agent to understand and 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?
Schema description coverage is 100%, so the schema fully documents all 4 parameters (fabricId, nodeId, candidate, includeMetadata). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline of 3 for high schema coverage without extra value.
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 a specific node' clearly states the action (get) and resource (node), but it's vague about what a 'node' represents in this context. It doesn't differentiate from sibling tools like 'nodesGetFabricNodes' (plural) or 'nodesGetPort' (different resource type), leaving ambiguity about scope and specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'nodesGetFabricNodes' for multiple nodes, 'nodesGetPort' for ports), the description lacks context on prerequisites, typical use cases, or exclusions, leaving the agent to 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 the full burden of behavioral disclosure. It only states the action ('Get the list'), implying a read-only operation, but fails to describe key behaviors such as authentication requirements, rate limits, pagination, error handling, or what the response format looks like. This is inadequate for a tool with multiple parameters and no output schema.
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 ('Get the list of sub-interfaces.') that is front-loaded and wastes no words. However, it is overly brief, lacking necessary context for effective use, which slightly reduces its utility despite the efficient structure.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It does not explain the return values, error conditions, or behavioral traits, leaving significant gaps. While the schema covers parameters well, the overall context for safe and correct usage is insufficient.
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, providing clear documentation for all parameters (fabricId, nodeId, candidate, includeMetadata). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. Given the high schema coverage, a baseline score of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of sub-interfaces' clearly states the action (get/list) and resource (sub-interfaces), making the purpose understandable. However, it lacks specificity about what 'sub-interfaces' refers to (e.g., network interfaces on a node) and does not distinguish it from sibling tools like 'nodesGetNodeSubInterface' (singular vs. plural), leaving room for ambiguity.
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 does not mention prerequisites (e.g., requiring a fabric and node), exclusions, or comparisons to related tools such as 'nodesGetNodeSubInterface' (for a single sub-interface) or 'nodesAddNodeSubInterfaces' (for creation). This absence leaves the agent without context for tool 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?
With no annotations provided, the description carries full burden but only states it's an update operation without disclosing behavioral traits like required permissions, whether updates are partial or complete, side effects, or error handling. This is inadequate for a mutation tool with 14 parameters and nested objects.
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 brief and front-loaded with the core action, consisting of two sentences without unnecessary elaboration. However, the second sentence is somewhat redundant given the schema, slightly reducing 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?
Given the tool's complexity (14 parameters, nested objects, no annotations, no output schema), the description is insufficient. It lacks details on update behavior, error cases, or what constitutes a valid update, leaving significant gaps for an AI agent to operate 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 all 14 parameters. The description adds no additional meaning beyond implying that 'resource ID' and 'fields to update' are needed, which is already clear from the schema's required parameters and properties. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' and resource 'a specific node', which provides a basic purpose. However, it lacks specificity about what aspects of a node can be updated and doesn't differentiate from sibling tools like 'nodesUpdateManagementPort' or 'nodesUpdateNodeLoopback', making it vague in 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?
The description provides no guidance on when to use this tool versus alternatives, such as other update tools in the sibling list. It mentions passing resource ID and fields as arguments, but this is procedural rather than contextual usage advice, leaving the agent without clear decision-making criteria.
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 'Update' implies a mutation operation, but fails to describe critical behavioral traits such as required permissions, whether the update is idempotent or reversible, potential side effects (e.g., network disruption), rate limits, or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded and waste-free. It directly states the tool's purpose and basic usage without unnecessary elaboration. However, it could be more structured by explicitly listing key updatable fields or linking to the schema, but it's efficient given its brevity.
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 (17 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. For a mutation tool with rich schema but no annotations or output schema, the description should provide more context to guide the agent effectively, 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%, meaning all 17 parameters are well-documented in the input schema with detailed descriptions, enums, and constraints. The description adds no additional parameter semantics beyond implying that 'resource ID and fields to update' are needed, which is already covered by the schema. Baseline 3 is appropriate as 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update') and resource ('a specific port channel'), which clarifies the basic purpose. However, it doesn't differentiate this tool from sibling tools like 'portchannelsAddPortChannels' or 'portchannelsDeletePortChannel' beyond the verb, nor does it specify what fields can be updated. The purpose is clear but lacks specificity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance by mentioning that resource ID and fields to update are required as arguments. However, it offers no context on when to use this tool versus alternatives (e.g., 'portchannelsAddPortChannels' for creation, 'portchannelsDeletePortChannel' for deletion), prerequisites, or constraints. This leaves the agent without clear direction on appropriate usage scenarios.
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 'update' implying mutation but doesn't disclose permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields. The description doesn't contradict annotations (none exist), but fails to provide necessary context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and basic usage. There's no wasted text, though it could benefit from being slightly more informative given the tool's 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 mutation tool with 12 parameters, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a valid update, which fields are mutable versus read-only (though schema indicates some), or what the response contains. The complexity demands more guidance than provided.
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 no additional parameter semantics beyond mentioning 'resource ID and the fields to update', which is already implied by the tool name and schema. 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 'Update[s] a specific VNI' which provides a clear verb and resource. However, it doesn't differentiate from sibling tools like 'vnisUpdateFabricVni' vs 'fabricsUpdateFabric' or 'vrfsUpdateFabricVrf', leaving ambiguity about scope and hierarchy.
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 only provides basic usage instructions ('pass the resource ID and the fields to update as arguments') without guidance on when to use this tool versus alternatives like 'vnisAddFabricVnis' or 'vnisDeleteFabricVni'. No context about prerequisites, dependencies, or exclusions 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 full burden but only states the action without behavioral details. It does not disclose if this is a read-only operation, requires authentication, has side effects, or how errors are handled. For a tool with parameters and no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with key details (e.g., 'Retrieve configuration for a VRF') to improve clarity without sacrificing brevity.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It does not explain what is returned (e.g., VRF details, error formats) or behavioral aspects like idempotency or permissions. For a tool that likely returns structured data, this leaves critical gaps for 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 all four parameters. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or examples. Baseline 3 is appropriate as the schema does the heavy lifting, but no extra value is provided.
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') and target ('a specific VRF'), which clarifies the basic purpose. However, it lacks specificity about what 'get' entails (e.g., retrieve configuration, status, or metadata) and does not differentiate from sibling tools like 'vrfsGetFabricVrfs' (plural) or 'vrfsUpdateFabricVrf', leaving the scope ambiguous.
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 does not mention prerequisites, context (e.g., after creation or update), or comparisons to siblings such as 'vrfsGetFabricVrfs' for listing multiple VRFs, leaving usage decisions 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 full burden. It states 'Update a specific VRF' which implies a mutation operation, but doesn't disclose any behavioral traits: no information about permissions required, whether changes are reversible, rate limits, side effects, or what happens to existing configurations not mentioned. For a mutation tool with 13 parameters and complex nested objects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first states the purpose, the second provides basic usage instruction. There's no wasted text, though it could be more front-loaded with critical information about what 'update' entails. The structure is simple but effective for its limited content.
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 (13 parameters with nested objects, mutation operation), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'update' means in practice, what fields are actually modifiable versus read-only (many parameters in the schema are marked readOnly), or what the tool returns. For a VRF update tool in a network fabric context, this leaves too many gaps for effective agent 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 already documents all 13 parameters thoroughly. The description adds no parameter semantics beyond mentioning 'resource ID and the fields to update' - it doesn't explain which fields are updatable versus read-only, or provide any context beyond what's in the schema. With high schema coverage, baseline 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 'Update a specific VRF' which provides a clear verb ('Update') and resource ('VRF'), but it's vague about what fields can be updated and doesn't distinguish this tool from sibling tools like 'vrfsUpdateFabricStaticRoute' or 'fabricsUpdateFabric'. It doesn't specify that this updates VRF configuration fields like name, description, annotations, labels, ASN, or VNI.
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 an existing VRF), when not to use it (e.g., for creating new VRFs, which would use 'vrfsAddFabricVrfs'), or how it differs from similar update tools in the sibling list. The second sentence is just basic usage instruction, not contextual guidance.
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 only states the basic action. It doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, response format, or whether this is a read-only operation. 'Get' implies safe retrieval, but lacks confirmation or 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?
Extremely concise with a single sentence that directly states the tool's purpose. No wasted words or unnecessary elaboration, 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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a bearer token is in this context, how it's used, what the response contains, or any prerequisites. The agent lacks critical context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no additional meaning beyond implying retrieval of a 'specific' token (hinting at tokenId usage). Baseline 3 is appropriate since 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 'Get a specific bearer token' clearly states the verb ('Get') and resource ('bearer token'), but lacks specificity about what 'specific' means and doesn't differentiate from sibling 'authGetBearerTokens' (plural). It's functional but vague about 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 on when to use this tool versus alternatives like 'authGetBearerTokens' (plural) or 'authGetUser'. The description implies retrieval of a single token, but doesn't explicitly state this distinction or provide context for choosing between 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?
No annotations are provided, so the description carries full burden. It states 'Get' implying a read operation, but doesn't disclose behavioral traits such as authentication requirements, error handling, rate limits, or what the response includes (e.g., user details). This is a significant gap for a tool with no annotation coverage.
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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it efficient for quick understanding.
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 and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral context needed for a read operation in an auth system. For a tool with 2 parameters and siblings like 'authGetUsers', more detail is warranted to guide the agent 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 input schema already documents both parameters ('userId' and 'includeMetadata') thoroughly. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, which aligns with the baseline score 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 action ('Get') and resource ('a specific user'), which clarifies the basic purpose. However, it doesn't differentiate this tool from its sibling 'authGetUsers' (which likely lists multiple users), making it somewhat vague about scope. It's not tautological but lacks specificity compared to alternatives.
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 'authGetUsers' for listing users or other auth tools. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage 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 'Get a list of users' but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or the response format (e.g., pagination). For a tool with no annotations, 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 extremely concise with a single sentence, 'Get a list of users,' which is front-loaded and wastes no words. It efficiently conveys the core action, though this brevity contributes to gaps in other dimensions like guidelines and transparency.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., read-only nature, auth needs), usage context, and output expectations. While the schema covers parameters well, the overall description doesn't provide enough context for effective agent 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 description adds no parameter information beyond the input schema, which has 100% coverage with detailed descriptions for all 4 parameters (emails, enabled, roles, includeMetadata). Since the schema fully documents parameters, the baseline score is 3, as the description doesn't need to compensate but also doesn't enhance understanding.
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 a list of users' clearly states the verb ('Get') and resource ('users'), making the basic purpose understandable. However, it doesn't differentiate this tool from its sibling 'authGetUser' (singular) or explain the scope of 'list' (e.g., all users vs. filtered). This makes it adequate but vague regarding 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 doesn't mention the sibling 'authGetUser' for single-user retrieval or other auth tools like 'authSetUsers'. There's no context on prerequisites, such as authentication needs, leaving the agent without usage direction.
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. While 'Add' implies a write/mutation operation, the description doesn't mention required permissions (though the schema hints at administrative privileges), potential side effects, error conditions, or what happens when adding duplicate users. It provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but contains a confusing second sentence that references 'fabrics' parameter syntax which doesn't match this tool's actual parameter ('users'). This creates ambiguity rather than clarity. While short, the structure is problematic with irrelevant information that doesn't earn 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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, permission requirements (beyond what's buried in the schema), or how it differs from sibling user management tools. The confusing second sentence further reduces completeness.
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 the 'users' parameter thoroughly. The description adds no meaningful parameter semantics beyond what's in the schema - the second sentence about passing 'fabrics' appears to be a copy-paste error or irrelevant to this tool. With high schema coverage, the baseline of 3 is appropriate.
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 ('Add one or more users') which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'authUpdateUser' or 'authDeleteUser' - it only indicates it's for adding users without clarifying when to use this versus updating existing users.
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 sibling tools like 'authUpdateUser', 'authDeleteUser', and 'authGetUsers', there's no indication of when adding users is appropriate versus updating existing ones or retrieving user information. The second sentence is about parameter syntax, not 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 only states the action ('Get the list of fabrics') without mentioning any behavioral traits such as pagination (implied by 'cursor' and 'max' parameters), read-only nature, authentication requirements, rate limits, or error handling. This lack of context makes it inadequate for a tool with multiple parameters and no output schema.
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 sentence ('Get the list of fabrics.'), which is front-loaded and wastes no words. It efficiently communicates the core purpose without unnecessary elaboration, earning a top score for brevity and clarity in structure.
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 annotations, no output schema), the description is incomplete. It fails to explain key aspects like the tool's behavior (e.g., pagination via 'cursor', filtering options), return values, or how it differs from siblings. With no output schema and minimal description, the agent lacks sufficient context to use the tool effectively beyond basic inference.
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, providing clear documentation for all 5 parameters (e.g., 'fabricId' for filtering, 'cursor' for pagination). The description adds no additional meaning beyond the schema, as it does not mention parameters at all. According to the rules, with high schema coverage (>80%), the baseline is 3, which is appropriate here since the schema handles 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 'Get the list of fabrics' clearly states the verb ('Get') and resource ('fabrics'), making the purpose understandable. However, it lacks specificity about scope (e.g., all fabrics in a system) and does not distinguish it from sibling tools like 'fabricsGetFabric' (which likely gets a single fabric) or 'fabricsGetFabricConnections' (which focuses on connections). This vagueness prevents a higher 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 many sibling tools (e.g., 'fabricsGetFabric' for a single fabric, 'fabricsGetFabricConnections' for connections), there is no indication of context, prerequisites, or exclusions. This absence of usage instructions leaves the agent to infer 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 of behavioral disclosure. It states 'Get a specific fabric' but doesn't clarify if this is a read-only operation, what permissions are needed, how errors are handled, or the response format. For a tool with no annotation coverage, 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 zero waste. It's front-loaded and appropriately sized for a simple retrieval tool, avoiding 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 the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits, leaving the agent to infer details. For a retrieval tool with no output schema, more context on what 'get' returns would be helpful.
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 input schema already documents all parameters (fabricId, candidate, includeMetadata) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific fabric' clearly states the action (get) and resource (fabric), but it's vague about what 'get' entails (e.g., retrieve details, fetch metadata) and doesn't distinguish it from sibling tools like 'fabricsGetAllFabrics' or 'fabricsGetFabricCandidate'. It avoids tautology 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?
No guidance is provided on when to use this tool versus alternatives like 'fabricsGetAllFabrics' (for listing all fabrics) or 'fabricsGetFabricCandidate' (for candidate configurations). The description implies usage for retrieving a single fabric but offers no context on prerequisites, exclusions, or comparisons to 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?
No annotations are provided, so the description carries full burden. It mentions 'list' which implies a read operation, but doesn't disclose behavioral traits like whether it's paginated (though 'cursor' parameter hints at this), rate limits, authentication needs, or what happens with invalid inputs. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy for an agent 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 complexity (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'candidate configurations' are, how results are structured, or behavioral aspects like pagination or error handling. For a tool with rich parameters and no structured safety hints, this minimal description leaves significant gaps.
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 10 parameters. The description adds no meaning beyond what the schema provides—it doesn't explain relationships between parameters (e.g., how 'fabricId' filters results) or typical usage patterns. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of candidate configurations' clearly states the action (get) and resource (candidate configurations), but it's vague about what 'candidate configurations' are in this context. It doesn't distinguish this tool from sibling tools like 'fabricsGetFabricCandidate' (singular) or 'fabricsGetAllFabrics', leaving the scope ambiguous.
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 many sibling tools available (e.g., 'fabricsGetFabricCandidate' for a single candidate, 'fabricsGetAllFabrics' for fabrics), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on parameter 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 full burden. It states 'Get' implying a read operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error conditions, or what happens if the connection doesn't exist. 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 ('Get a specific connection.') with zero waste. It's appropriately sized for a simple retrieval tool and front-loaded with the core action, though it could benefit from more detail given the lack of annotations.
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 what a 'connection' is in this context, what data is returned, or any prerequisites. With no output schema and minimal description, it fails to provide enough 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?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., fabricId as 'The fabric id or name', connectionId as 'The connection id, connections are not named', candidate for configuration). The description adds no additional meaning beyond the schema, 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 'Get a specific connection' clearly indicates a retrieval action ('Get') on a resource ('connection'), but it's vague about what type of connection (fabric-related) and doesn't distinguish from sibling tools like fabricsGetFabricConnections (plural) or fabricsAddFabricConnections. It states the 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention siblings like fabricsGetFabricConnections (for listing multiple connections) or fabricsDeleteFabricConnection, leaving the agent to infer usage from tool names alone. There's no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states this is an update operation but fails to mention critical aspects: whether this requires specific permissions, if it's idempotent, what happens to unspecified fields (partial vs. full updates), error conditions, or response format. This leaves the agent with significant uncertainty about 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 extremely concise with just two sentences that directly state the purpose and basic usage. Every word serves a clear function without redundancy, making it easy to parse quickly. It's appropriately sized for a tool with comprehensive schema documentation.
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 11 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects like permissions, idempotency, or error handling, nor does it explain what constitutes a successful update or the response format. The schema handles parameter documentation well, but the description fails to provide necessary operational 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%, providing detailed documentation for all 11 parameters. The description adds minimal value by mentioning 'resource ID' (mapping to fabricId) and 'fields to update' (hinting at partial updates), but doesn't clarify parameter interactions or usage nuances beyond what the schema already specifies.
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 ('Update') and resource ('a specific fabric'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'fabricsAddFabrics' or 'fabricsDeleteFabric', which would require explicit comparison to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage instructions ('pass the resource ID and the fields to update as arguments') but offers no guidance on when to use this tool versus alternatives like 'fabricsAddFabrics' for creation or 'fabricsDeleteFabric' for deletion. There's no mention of prerequisites, constraints, or typical scenarios for updates.
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 'Delete' which implies a destructive mutation, but doesn't disclose critical behaviors: whether deletion is permanent/reversible, permission requirements, side effects (e.g., impact on connected resources), or error conditions. This is inadequate for a destructive operation with zero annotation coverage.
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 with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient. No unnecessary details or redundancy are present.
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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (permanence, permissions), usage guidance, and output expectations. While the schema covers parameters, the overall context for safe and correct invocation is insufficient.
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 both parameters (fabricId and nodeId) documented in the schema. The description adds no additional parameter information beyond implying a 'specific node' context. This meets the baseline of 3 since the schema does the heavy lifting, but no extra value is provided.
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 specific node' clearly states the action (delete) and resource (node), but it's vague about scope and context. It doesn't specify what type of node (fabric node) or distinguish it from sibling deletion tools like nodesDeleteNodeLoopback or nodesDeleteNodeSubInterface, which target different resources.
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 (e.g., node must exist), exclusions, or related tools like nodesUpdateFabricNode or nodesAddFabricNodes for other operations. This leaves the agent without context for decision-making.
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 but adds minimal behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are needed, if it's paginated or rate-limited, or the format of the returned list. For a tool with no annotations, this leaves critical 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 extremely concise with a single sentence ('Get the list of nodes.'), which is front-loaded and wastes no words. For a simple retrieval tool, this brevity is appropriate and efficient.
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 doesn't explain what 'nodes' are in this context (e.g., network nodes in a fabric), the response format, or error conditions. For a tool with three parameters and no structured output documentation, more context is needed to be fully usable.
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 (fabricId, candidate, includeMetadata). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline of 3 without compensating or detracting.
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 the list of nodes' clearly states the action (get) and resource (nodes), but it's vague about scope and context. It doesn't specify what type of nodes (fabric nodes vs other nodes) or differentiate from sibling tools like 'nodesGetNamedFabricNode' or 'devicesGetDevices', leaving ambiguity about its specific purpose.
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 sibling tools like 'nodesGetNamedFabricNode' (for a specific node) and 'devicesGetDevices' (possibly for different resource types), the description offers no context about filtering, prerequisites, or comparative use cases.
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 only states the action ('Get'), implying a read-only operation, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, response format, or whether it's idempotent. For a tool with no annotations, 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, clear sentence: 'Get the list of management ports.' It's front-loaded with the core action and resource, with no unnecessary words or redundancy. This is 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 complexity (a tool with 4 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain what management ports are, the response structure, or behavioral traits. While conciseness is good, the lack of context makes it inadequate for an agent to fully understand how to use this tool effectively, especially compared to siblings.
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 all parameters well-documented in the input schema (e.g., fabricId, nodeId, candidate, includeMetadata). The description adds no parameter-specific information beyond what's in the schema, such as examples or usage tips. According to the rules, with high schema coverage, the baseline is 3 even without 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 'Get the list of management ports' clearly states the action (get) and resource (management ports), but it's vague about scope and context. It doesn't specify what management ports are (e.g., network ports for device management) or how this differs from sibling tools like 'nodesGetManagementPort' (singular) or 'nodesGetPorts' (general ports). The purpose is understandable but lacks specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a fabric and node), exclusions, or comparisons to sibling tools like 'nodesGetManagementPort' (singular) or 'nodesGetPorts' (all ports). Without such context, an agent might struggle to choose correctly among similar tools in the list.
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 'Get' implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, error handling, rate limits, or what happens if parameters are invalid. For a tool with 5 parameters and no annotations, this is insufficient.
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 with zero waste: 'Get a specific loopback.' It's front-loaded and appropriately sized for its purpose, though it could benefit from more detail. 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?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what a loopback is, the return format, or error conditions. For a tool that likely retrieves network configuration data, 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?
Schema description coverage is 100%, so the schema fully documents all 5 parameters (e.g., fabricId, nodeId, loopbackId, candidate, includeMetadata). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or typical values. 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 'Get a specific loopback' clearly states the action (get) and resource (loopback), but it's vague about what a 'loopback' is in this context (likely a network interface configuration). It doesn't distinguish from sibling tools like 'nodesGetNodeLoopbacks' (plural) or 'nodesUpdateNodeLoopback', leaving ambiguity about 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. For example, it doesn't clarify if this is for retrieving a single loopback by ID versus using 'nodesGetNodeLoopbacks' for a list, or mention prerequisites like needing fabric/node context. The description alone offers no 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 only states the action ('Get') without mentioning whether this is a read-only operation, if it requires authentication, potential rate limits, or what the response format looks like. For a tool with no annotations, 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, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core action, 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 complexity of a tool with four parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, usage context, and output, leaving significant gaps for the agent to understand how to invoke and interpret results 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 input schema has 100% description coverage, fully documenting all four parameters (fabricId, nodeId, candidate, includeMetadata). The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
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') and resource ('list of ports'), which provides a basic purpose. However, it lacks specificity about what kind of ports (e.g., network ports on a node) and doesn't differentiate from sibling tools like 'nodesGetPort' (singular) or 'nodesGetManagementPorts', making it vague in 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 on when to use this tool versus alternatives such as 'nodesGetPort' (for a single port) or 'nodesGetManagementPorts'. The description offers no context, prerequisites, or exclusions, leaving the agent to 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 the full burden. It mentions 'Reset' but doesn't disclose behavioral traits like whether this is a destructive operation, requires specific permissions, has side effects (e.g., network disruption), or rate limits. This leaves significant gaps in understanding the tool's 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 waste. It is front-loaded and appropriately sized for the tool's complexity, 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 complexity of a reset operation with no annotations and no output schema, the description is incomplete. It lacks details on what 'reset' means, potential impacts, success/failure responses, or error handling, making it inadequate for safe and effective use by 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 clear parameter definitions (fabricId, nodeId, portId). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate as the schema handles 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 action ('Reset') and target ('a specific port'), which provides a basic purpose. However, it lacks specificity about what 'reset' entails (e.g., restart, clear configuration, reboot) and doesn't differentiate from sibling tools like 'nodesUpdatePort' or 'nodesSetPorts', making it vague compared to higher standards.
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 'nodesUpdatePort' or 'nodesSetPorts'. The description offers no context, prerequisites, or exclusions, leaving the agent without usage direction.
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 for behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify permissions needed, rate limits, pagination, error handling, or what format the list returns. For a tool with no annotation coverage, this minimal description 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 zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool. 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?
Given the tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what a 'port channel' is in this context, what the response format looks like, or any behavioral constraints. For a tool that presumably returns network configuration data, more context would be helpful.
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 (fabricId, candidate, includeMetadata). The description adds no parameter information beyond what's in the schema, which is acceptable given the high coverage. Baseline score of 3 applies 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of port channels' clearly states the verb ('Get') and resource ('port channels'), but it's vague about scope and lacks sibling differentiation. It doesn't specify whether this retrieves all port channels globally or within a specific context, and doesn't distinguish from sibling tools like 'portchannelsGetPortChannel' (singular) or 'portchannelsAddPortChannels'.
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 (like needing authentication), when to use this versus the singular 'portchannelsGetPortChannel', or any context-specific recommendations. It's a basic statement with no 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?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'Get'), what permissions are required, error conditions, or response format. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it 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 extremely concise with a single sentence, 'Get a specific VNI.', which is front-loaded and wastes no words. It efficiently communicates the core purpose 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 the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what a VNI is, how it relates to fabrics, what data is returned, or error handling. For a tool in a network management context with many siblings, 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 all 4 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain relationships between parameters like fabricId and vniId). Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with any extra context.
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 a specific VNI' clearly states the action (Get) and resource (VNI), but it's vague about what 'specific' means and doesn't differentiate from sibling tools like 'vnisGetFabricVnis' (plural) or 'vnisGetFabricVniMember'. It doesn't specify that this retrieves a single VNI by ID, which would help distinguish it from list operations.
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 'vnisGetFabricVnis' (get all VNIs) or 'vnisGetFabricVniMember' (get VNI members). The description implies it's for retrieving a single VNI, but it doesn't explicitly state this or mention prerequisites like needing fabric and VNI identifiers.
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 only states the action ('Get the list') without detailing response format (e.g., list structure, pagination), error conditions, authentication requirements, rate limits, or whether it's read-only (implied but not explicit). This is inadequate for a tool with potential complexity in networking contexts.
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 with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse, though this conciseness comes at the cost of detail 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what VNIs are, how the list is structured, or any behavioral traits (e.g., read-only nature, potential errors). For a networking tool with 3 parameters and no structured safety hints, 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?
Schema description coverage is 100%, with clear descriptions for all parameters (fabricId, candidate, includeMetadata). The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or typical use cases. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is provided.
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 the list of VNIs' clearly states the verb ('Get') and resource ('VNIs'), making the basic purpose understandable. However, it lacks specificity about what VNIs are (Virtual Network Identifiers) or how they relate to the fabric context, and it doesn't differentiate from sibling tools like 'vnisGetFabricVni' (singular) or 'vnisGetFabricVniMembers', leaving ambiguity about 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. The description doesn't mention prerequisites (e.g., needing a valid fabric), exclusions, or comparisons to sibling tools like 'vnisGetFabricVni' (for a single VNI) or 'vnisGetFabricVniMembers', leaving the agent to infer usage from context 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 but only states the basic action. It lacks details on behavioral traits like authentication requirements, rate limits, error handling, or what 'get' entails (e.g., read-only, returns configuration data). The description doesn't add meaningful context beyond the minimal 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, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse, though it lacks depth.
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 incomplete. It doesn't explain the return format, error conditions, or how it fits into the broader fabric/VRF context. Sibling tools suggest it's part of a configuration management system, but this isn't clarified.
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 all parameters well-documented in the input schema. The description adds no additional parameter information beyond implying a 'specific' route via 'routeId', which is already covered in the schema. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
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 a specific static route' clearly states the action (get) and resource (static route), but it's vague about scope and context. It doesn't specify what kind of static route (fabric-related) or differentiate from sibling tools like 'vrfsGetFabricStaticRoutes' (plural) which likely retrieves multiple routes.
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. The description doesn't mention prerequisites, such as needing a fabric, VRF, and route ID, or contrast it with sibling tools like 'vrfsGetFabricStaticRoutes' for listing routes or 'vrfsUpdateFabricStaticRoute' for modifications.
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 it's a read operation ('Get'), but doesn't cover aspects like authentication needs, rate limits, pagination, error handling, or what the response format looks like (e.g., list structure). This leaves significant gaps for an agent to understand how to invoke it effectively.
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 action ('Get the list of static routes'), making it easy to parse quickly. No unnecessary words or redundancy are present.
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 read operation with 4 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits like pagination or authentication. For a tool that likely returns structured data, more context is needed to help an agent use it correctly.
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 four parameters (fabricId, vrfId, candidate, includeMetadata) with clear descriptions. The description adds no additional meaning beyond implying a list operation, which is minimal value. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of static routes' clearly states the verb ('Get') and resource ('static routes'), but it's vague about scope and context. It doesn't specify that this is for a particular fabric and VRF, which the parameters indicate, nor does it distinguish it from sibling tools like 'vrfsGetFabricStaticRoute' (singular) or 'vrfsAddFabricStaticRoutes'.
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 doesn't mention sibling tools like 'vrfsGetFabricStaticRoute' (for a single route) or 'vrfsAddFabricStaticRoutes' (for adding routes), nor does it specify prerequisites or contexts for usage beyond what's implied by the parameters.
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 this is an 'Add' operation (implying creation/mutation) but provides no information about permissions required, whether tokens are immediately active, what happens on duplicate names, rate limits, or what the response contains. For a security-sensitive token creation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but inefficiently structured. The first sentence clearly states the purpose. The second sentence provides syntax guidance but includes a confusing example ('fabrics=[{...}]') that doesn't match the actual parameter name ('tokens'), creating potential confusion rather than clarity. The example should either be correct or omitted.
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 token creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after token creation (are tokens returned? in what format?), doesn't mention authentication requirements for this sensitive operation, and provides minimal guidance about parameter usage. The confusing example further reduces completeness. A security-sensitive creation tool needs more comprehensive documentation.
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 fully documents the single 'tokens' parameter and its nested properties. The description adds minimal value beyond the schema - it mentions 'required fields' but doesn't specify which are actually required (schema shows required: []). The confusing 'fabrics' example doesn't help clarify parameter usage. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('bearer tokens'), making the purpose immediately understandable. It specifies 'one or more' tokens, which adds useful scope information. However, it doesn't explicitly differentiate this from sibling tools like authGetBearerTokens or authDeleteBearerToken, which would require mentioning it's for creation rather than retrieval or deletion.
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 basic syntax guidance ('pass the required fields as direct arguments') but offers no contextual guidance about when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication requirements), when creation is appropriate versus using existing tokens, or how this relates to sibling auth tools. The example with 'fabrics' is confusing since it doesn't match the actual parameter name 'tokens'.
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 'Add' which implies a write/mutation operation, but doesn't disclose any behavioral traits like whether this is idempotent, what permissions are required, if it's destructive to existing loopbacks, or what happens on success/failure. The description is minimal and lacks critical context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but inefficiently structured. The first sentence states the purpose clearly. The second sentence provides basic usage syntax but doesn't add meaningful value beyond what the schema already implies. The description could be more front-loaded with context rather than syntax reminders.
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 no annotations and no output schema, the description is inadequate. It doesn't explain what 'Add' entails operationally, what the expected outcome is, error conditions, or relationship to other tools. The 100% schema coverage helps with parameters, but the overall context for using this tool is incomplete.
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 fully documents all 3 parameters (fabricId, nodeId, loopbacks). The description adds no parameter semantics beyond what's in the schema - it only provides a generic example of argument passing format. Baseline 3 is appropriate when the schema does all 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 ('Add one or more loopbacks') and identifies the resource (loopbacks). It distinguishes from siblings like 'nodesUpdateNodeLoopback' (update) and 'nodesDeleteNodeLoopback' (delete), but doesn't explicitly differentiate from 'nodesGetNodeLoopbacks' (read). The purpose is specific but could be slightly more precise about the context (fabric/node).
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 mentions how to pass arguments but not when this tool is appropriate compared to siblings like 'nodesUpdateNodeLoopback' or 'nodesDeleteNodeLoopback'. There's no mention of prerequisites, dependencies, or typical use cases.
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 states the tool adds VNIs (implying a write/mutation operation) but doesn't disclose permissions required, whether it's idempotent, error conditions, or side effects. The schema shows read-only fields (e.g., 'enabled', 'id'), suggesting some fields are auto-generated, but the description doesn't explain this behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but inefficiently structured. The first sentence states the purpose clearly, but the second sentence is redundant with schema information (how to pass arguments) and doesn't add value. It could be more front-loaded with critical usage information instead of basic syntax.
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 (adding VNIs with nested objects like 'svis' and 'annotations'), no annotations, and no output schema, the description is inadequate. It doesn't explain what a successful addition entails (e.g., returns VNI IDs), error handling, or interactions with other tools (e.g., 'fabricsCommitFabricCandidate' for changes). The schema covers inputs, but the description fails to provide necessary operational 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 both parameters ('fabricId' and 'vnis'). The description adds no parameter-specific information beyond the schema, such as examples of valid VNI configurations or constraints on 'fabricId'. It only provides a generic syntax example, which doesn't enhance understanding of parameter meanings.
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 ('Add one or more VNIs') and identifies the resource (VNIs). It distinguishes from siblings like 'vnisUpdateFabricVni' or 'vnisDeleteFabricVni' by specifying addition rather than modification or deletion. However, it doesn't explicitly differentiate from 'vnisAddFabricVniMembers', which adds members to existing VNIs rather than creating new VNIs.
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 an existing fabric), exclusions (e.g., not for updating existing VNIs), or comparisons to sibling tools like 'vnisUpdateFabricVni' for modifications or 'vnisAddFabricVniMembers' for adding members. The second sentence is about syntax, not 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. While 'Delete' implies a destructive mutation, the description fails to specify critical details: whether deletion is permanent or reversible, what permissions are required, if there are rate limits, or what happens to associated resources. For a security-sensitive operation like token deletion, 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, direct sentence with zero wasted words. It front-loads the core action ('Delete') and resource ('bearer token'), making it easy to parse quickly. Every word earns its place, adhering perfectly to conciseness best practices.
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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permanence, side effects), usage context relative to siblings, and expected outcomes. While the parameter is well-documented in the schema, the overall context for safe and correct invocation is insufficient.
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 'tokenId' clearly documented as 'The id of the token to delete.' The description doesn't add any meaning beyond this, such as format examples or where to obtain the ID. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately 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 resource ('a specific bearer token'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'authDeleteUser' or other deletion tools in the list, which would require mentioning it specifically targets authentication tokens rather than user accounts or other resources.
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 the token ID from 'authGetBearerToken' or 'authGetBearerTokens'), nor does it specify scenarios where deletion is appropriate (e.g., revoking access, security cleanup). With multiple sibling tools for managing tokens and users, this lack of context leaves the agent guessing.
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. 'Delete a specific user' implies a destructive mutation, but it fails to describe critical behaviors: whether deletion is permanent, if it requires admin permissions, what happens to associated data, or any error conditions. For a destructive operation, this lack of detail 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, direct sentence with zero wasted words. It's front-loaded with the core action ('Delete') and resource ('user'), making it immediately scannable and efficient. 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?
Given the complexity (a destructive user deletion operation), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, irreversibility, or response format, which are crucial for an agent to use this tool safely and effectively. The high schema coverage doesn't compensate for these missing contextual elements.
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 the single parameter 'userId' documented as 'The user id or email address.' The description adds no additional parameter semantics beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score 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.
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 specific user'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other deletion tools in the sibling list (like authDeleteBearerToken, fabricsDeleteFabric, etc.), which would require specifying it's for user accounts specifically rather than other entities.
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., user must exist), consequences (e.g., irreversible action), or when to choose authDeleteUser over other deletion tools like authDeleteBearerToken or fabricsDeleteFabric. This leaves the agent without context for proper tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool updates a user but fails to disclose critical traits such as required permissions, whether changes are reversible, potential side effects (e.g., impact on user access), or rate limits. This leaves significant gaps in understanding the tool's behavior and risks.
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 concise and front-loaded, with the core purpose in the first sentence and usage note in the second. It avoids unnecessary words, but the second sentence could be more informative (e.g., explaining parameter relationships) to fully earn a score of 5.
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 operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, error handling, return values, and differentiation from siblings, making it inadequate for safe and effective use by an AI agent in this 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?
The input schema has 100% description coverage, clearly documenting all parameters (userId, enabled, labels, role) with details like enum values for 'role'. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, so it meets the baseline score of 3 for high schema coverage without adding 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 ('Update') and resource ('a specific user'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'authSetUsers' or 'authDeleteUser' beyond the basic verb, missing explicit differentiation that would warrant a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool, stating only to 'pass the resource ID and the fields to update as arguments.' It offers no explicit when/when-not instructions, no mention of prerequisites, and no comparison to alternatives like 'authSetUsers' for bulk updates or 'authDeleteUser' for removal, leaving the agent with insufficient context for optimal 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool performs a binding operation but doesn't mention whether this is a write operation, what permissions are required, whether it's idempotent, what happens on failure, or what the expected outcome looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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 appropriately concise with two sentences that directly address the tool's purpose and basic usage. It's front-loaded with the core purpose statement. No wasted words, though it could be slightly more informative given the lack of annotations.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'binding' means in this context, what the expected result is, whether there are side effects, or what happens to existing bindings. The agent lacks crucial information to understand the tool's behavior and consequences.
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. The description adds minimal value beyond the schema by mentioning 'resource ID and the fields to update' but doesn't clarify which parameters correspond to which concepts or provide additional context about parameter usage. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bind') and the target ('a specific device to a node'), providing a specific verb+resource combination. It distinguishes from sibling 'devicesUnbindDevice' by specifying the opposite operation, though it doesn't explicitly mention other device-related tools like 'devicesGetDevices'.
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 mentions 'pass the resource ID and the fields to update as arguments' but doesn't clarify prerequisites, when binding is appropriate, or what happens if the device is already bound. No explicit when/when-not instructions are provided.
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 only states the action ('Get the list') without details on permissions required, rate limits, pagination, error handling, or what the output includes (e.g., device attributes). For a read 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 no wasted words. It's front-loaded with the core action and resource, making it easy to understand at a glance. Every part of the sentence contributes directly to stating 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 tool's simplicity (0 parameters, no annotations, no output schema), the description is minimal but insufficient. It lacks context about what 'devices' are, how the list is structured, or any behavioral traits. For a tool that might return complex data (e.g., device lists with attributes), more detail would help agents use it effectively, making it incomplete despite the low complexity.
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, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, it doesn't need to compensate. This meets the baseline for tools with zero parameters, as there's nothing to explain beyond the schema.
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') and resource ('list of devices'), which clarifies the tool's purpose. However, it's vague about what 'devices' refers to (e.g., network devices, user devices) and doesn't differentiate from sibling tools like 'devicesBindDevice' or 'devicesUnbindDevice', which involve device management. This lack of specificity and sibling distinction keeps it at a basic level.
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 any context, prerequisites, or exclusions, such as whether it lists all devices or filtered ones, or how it relates to other device-related tools like 'nodesGetFabricNodes'. Without such information, users must infer usage from 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 full burden. It states the action is 'Unbind,' implying a destructive mutation, but doesn't disclose behavioral traits like whether this requires specific permissions, if it's reversible, what happens to the device after unbinding, or error conditions. The description is minimal and lacks necessary context 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, direct sentence with zero waste. It's appropriately sized and front-loaded, efficiently conveying the core action without unnecessary details.
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 of a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error handling, or what to expect after unbinding. For a tool that modifies system state, this is inadequate despite good conciseness.
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 both parameters ('fabricId' and 'nodeId') documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as clarifying what 'bound device' refers to or parameter relationships. Baseline 3 is appropriate since 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 ('Unbind') and the resource ('the bound device from a node'), making the purpose understandable. It distinguishes from the sibling 'devicesBindDevice' by being its inverse operation, though this distinction isn't explicitly stated 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?
No guidance is provided on when to use this tool versus alternatives. While 'devicesBindDevice' is a clear sibling, the description doesn't mention it or explain prerequisites like needing a bound device first. Usage context is implied but not explicit.
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 only mentions syntax, not behavioral traits. It doesn't disclose whether this is a mutation (likely, given 'Add'), what permissions are needed, if it's idempotent, or how errors are handled. For a tool that modifies fabric connections, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by a syntax example. Both sentences are relevant, with no wasted words, making it efficient. However, the example could be clearer (e.g., using proper JSON syntax) to enhance usability.
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 of adding fabric connections, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error handling, and return values, leaving the agent with insufficient context to use the tool effectively in a real-world scenario.
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 parameters are well-documented in the schema itself. The description adds minimal value by referencing 'required fields' but doesn't explain parameter meanings beyond what the schema provides. 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 clearly states the action ('Add') and resource ('one or more connections'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'fabricsSetFabricConnections' or 'fabricsDeleteFabricConnections', which would require specifying this is for adding new connections rather than replacing or removing 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 basic syntax guidance ('pass the required fields as direct arguments') but offers no context on when to use this tool versus alternatives like 'fabricsSetFabricConnections' or prerequisites such as needing an existing fabric. Without explicit when/when-not guidance, the agent lacks clear direction.
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. 'Commit' implies a write/mutation operation, but the description doesn't disclose whether this is destructive, requires specific permissions, has side effects, or what happens upon success/failure. The example syntax adds minor value but doesn't address core behavioral traits.
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 appropriately brief with two sentences. The first states the purpose clearly, and the second provides usage syntax. However, the second sentence could be more front-loaded with critical information rather than just syntax example.
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 ('Commit') with no annotations and no output schema, the description is inadequate. It doesn't explain what 'committing' entails operationally, what happens to the candidate after commit, whether changes are reversible, what the tool returns, or error conditions. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral 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 already documents all four parameters thoroughly. The description adds no meaningful parameter semantics beyond what's in the schema - it only provides a generic example of argument passing without explaining any parameters specifically. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Commit') and the resource ('a specific candidate configuration'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'fabricsRevertFabricCandidate' or 'fabricsReviewFabricCandidate', which appear to operate on similar candidate configurations.
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 mentions how to pass arguments but offers no context about prerequisites, timing, or relationship to other candidate-related tools like 'fabricsGetFabricCandidate' or 'fabricsRevertFabricCandidate'.
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 for behavioral disclosure. While 'Delete' implies a destructive mutation, the description fails to specify whether this action is reversible, what permissions are required, whether it affects connected resources, or what happens on success/failure. For a destructive tool with zero annotation coverage, this lack of behavioral detail 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 with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable. Every word earns its place, achieving optimal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical context like what 'delete' entails (soft/hard deletion), error conditions, side effects on related entities, or response format. The combination of high-risk operation and lack of structured metadata requires more descriptive guidance than provided.
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 the single parameter 'fabricId' documented as 'The fabric id or name.' The description doesn't add any meaningful semantic context beyond this, such as format examples or validation rules. With complete schema coverage, the baseline score of 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 clearly states the action ('Delete') and target ('a specific fabric'), which is a specific verb+resource combination. It distinguishes from sibling tools like 'fabricsUpdateFabric' or 'fabricsGetFabric' by specifying deletion rather than modification or retrieval. However, it doesn't explicitly differentiate from other deletion tools like 'fabricsDeleteFabricConnection' or 'fabricsDeleteFabricConnections'.
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., whether the fabric must be empty or inactive), consequences of deletion, or when to choose this over other fabric-related tools like 'fabricsUpdateFabric' for deactivation. The absence of usage context leaves the agent without operational guidance.
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 'Delete' which implies a destructive mutation, but doesn't clarify if this is reversible, requires specific permissions, has side effects (e.g., on connected devices), or what happens on success/failure. 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 ('Delete a specific connection.') that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple deletion operation and front-loaded with the core action, making it easy for an agent 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 destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral risks (e.g., irreversibility), success criteria, error conditions, or return values. For a mutation tool in a complex system (with many sibling tools), more context 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 both parameters ('fabricId' and 'connectionId') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain format constraints or relationships between parameters). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 the target ('a specific connection'), which is a specific verb+resource combination. It distinguishes from sibling tools like 'fabricsDeleteFabric' (which deletes entire fabrics) and 'fabricsDeleteFabricConnections' (which likely deletes multiple connections). However, it doesn't explicitly mention the resource type (fabric connection) beyond the tool name, keeping it from 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. It doesn't mention prerequisites (e.g., needing a fabric ID and connection ID), when not to use it (e.g., for bulk deletions), or refer to sibling tools like 'fabricsDeleteFabricConnections' for comparison. This leaves the agent with minimal 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Get' which implies a read operation, but doesn't clarify if this requires authentication, has rate limits, returns structured data, or involves side effects. The description is minimal and lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple retrieval operation and gets straight to the point 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?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a 'candidate configuration' is, what data it returns, or how it relates to other fabric operations. The minimal description leaves too many contextual gaps for effective tool 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, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific candidate configuration' clearly states the action (Get) and resource (candidate configuration), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'fabricsGetFabricCandidates' (plural) or explain what a 'candidate configuration' is in this 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?
The description provides no guidance on when to use this tool versus alternatives like 'fabricsGetFabricCandidates' (which likely lists multiple candidates) or other fabric-related tools. There's no mention of prerequisites, typical use cases, or contextual constraints.
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. 'Discard' implies a destructive mutation, but it doesn't disclose critical behavioral traits such as whether this action is reversible, what permissions are required, or what happens to the discarded candidate (e.g., permanent deletion). This is a significant gap for a mutation tool with zero annotation coverage.
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 unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy for an agent 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 complexity of a destructive operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral outcomes (e.g., success/failure states, error conditions) and doesn't compensate for the absence of structured data, leaving the agent with insufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('fabricId' and 'name') documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., clarifying what 'discard' entails for these parameters), 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Discard') and target ('a specific candidate configuration'), which is specific and unambiguous. It doesn't explicitly differentiate from sibling tools like 'fabricsCommitFabricCandidate' or 'fabricsReviewFabricCandidate', but the verb 'discard' implies a distinct destructive operation versus committing or reviewing.
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 a candidate to exist), exclusions, or relationships with sibling tools like 'fabricsCommitFabricCandidate' or 'fabricsReviewFabricCandidate', leaving the agent to infer 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 only states it's a 'Get' operation, implying read-only behavior, but doesn't mention permissions, rate limits, error handling, or what the output looks like (e.g., format, data structure). This is inadequate for a tool with no annotation coverage.
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 and appropriately sized for a simple read operation, 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 and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., STP settings details), potential side effects, or usage context. For a tool with moderate complexity (3 parameters, 1 required) and no structured output information, this leaves significant gaps for 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 schema description coverage is 100%, so the schema fully documents all three parameters (fabricId, candidate, includeMetadata). The description adds no additional parameter information beyond what's in the schema, resulting in a baseline score of 3 as the schema handles 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 'Get' and the resource 'fabric spanning tree protocol settings', making the purpose specific and understandable. It doesn't explicitly distinguish from its sibling 'networksResetFabricStp' or 'networksUpdateFabricStp', but the verb 'Get' inherently differentiates it as a read operation versus reset/update operations.
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 any mention of prerequisites, context, or comparisons to sibling tools like 'networksResetFabricStp' or 'networksUpdateFabricStp', leaving usage unclear beyond the basic purpose.
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 'Reset' implies a mutation operation, but doesn't clarify if this is destructive (e.g., reverts to defaults, affects network stability), requires specific permissions, has side effects, or what the expected outcome is. This leaves significant gaps for a tool that likely modifies network configuration.
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 unnecessary words. It's front-loaded with the core action, 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'Reset' entails behaviorally (e.g., resets to defaults, may disrupt network), potential impacts, or return values, leaving the agent under-informed about critical operational aspects.
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 the single parameter 'fabricId' documented as 'The fabric id or name.' The description doesn't add any additional meaning beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating 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 ('Reset') and the target ('fabric spanning tree protocol settings'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'networksUpdateFabricStp' or 'networksGetFabricStp', which would require mentioning what makes this tool unique (e.g., resetting to defaults vs. updating specific settings).
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 'networksUpdateFabricStp' or 'networksGetFabricStp'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent to 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation but doesn't mention potential impacts (e.g., network disruption), authentication needs, rate limits, or what happens to unspecified fields. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by a usage note. Both sentences are relevant, with no wasted words, though it could be slightly more structured for clarity.
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 no annotations and no output schema, the description is insufficient. It doesn't explain behavioral traits, error conditions, or return values, leaving the agent with incomplete context despite the rich input schema.
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 stating to pass 'resource ID and fields to update', which doesn't enhance the schema's detailed parameter descriptions. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('fabric spanning tree protocol settings'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'networksGetFabricStp' or 'networksResetFabricStp', which prevents 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 minimal guidance ('pass the resource ID and the fields to update as arguments') but lacks context on when to use this tool versus alternatives like 'networksResetFabricStp' or prerequisites such as permissions. No explicit when/when-not instructions are given.
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 adds management ports, implying a write/mutation operation, but fails to mention critical aspects like required permissions, whether the operation is idempotent, potential side effects, or error conditions. This leaves significant gaps for an agent to understand how to use it safely and effectively.
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 brief and front-loaded with the core purpose in the first sentence. The second sentence provides a syntax example, which is helpful but could be considered slightly redundant if the schema is well-understood. Overall, it's efficient with minimal waste.
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 of adding management ports (a mutation operation with nested parameters), no annotations, and no output schema, the description is inadequate. It lacks information on behavioral traits, error handling, return values, and prerequisites, leaving the agent with insufficient context to use the tool correctly in real-world scenarios.
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 (fabricId, nodeId, ports) and their nested properties. The description adds no meaningful semantic context beyond what's in the schema, such as explaining relationships between parameters or typical usage patterns. However, with high schema coverage, the baseline score of 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 clearly states the action ('Add') and resource ('one or more management port'), making the purpose evident. However, it doesn't distinguish this tool from sibling tools like 'nodesUpdateManagementPort' or 'nodesGetManagementPorts', which handle updates and reads of the same resource type, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'nodesUpdateManagementPort' for modifications or 'nodesGetManagementPorts' for reads. It includes a syntax example for passing arguments, but this is parameter usage advice rather than contextual guidance on tool 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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states the tool adds sub-interfaces (implying mutation) but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens on success/failure. The technical syntax note adds little behavioral value.
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 brief and front-loaded with the core purpose. The second sentence provides a technical usage note that, while not adding much value, doesn't significantly detract from conciseness. No unnecessary elaboration is present.
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 no annotations and no output schema, the description is insufficient. It doesn't explain what 'adding' entails operationally, what the tool returns, error conditions, or prerequisites. The high schema coverage helps with parameters but doesn't compensate for missing behavioral and output 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%, providing detailed documentation for all parameters. The description adds no meaningful parameter semantics beyond what's already in the schema, merely giving a generic syntax example. This meets 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 ('Add') and resource ('one or more sub-interfaces'), making the purpose evident. It distinguishes from siblings like 'nodesUpdateNodeSubInterface' by focusing on creation rather than modification, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'nodesUpdateNodeSubInterface' or 'nodesDeleteNodeSubInterface'. It only includes a technical usage note about argument passing, which doesn't help with contextual decision-making.
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 'Delete' which implies a destructive mutation, but fails to specify whether this action is reversible, what permissions are required, or what happens to associated resources. This leaves critical behavioral traits unaddressed for a deletion 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, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse immediately.
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 destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like side effects, error conditions, or return values, leaving the agent with incomplete context for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all three parameters clearly documented. The description doesn't add any additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples, which aligns with the baseline score when schema coverage is complete.
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 the resource ('a specific loopback'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'nodesDeleteFabricNode' or 'nodesDeleteNodeSubInterface' beyond the resource type, which prevents 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, dependencies, or any context for selecting this deletion operation over others in the sibling list, leaving the agent without usage direction.
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 action is destructive ('Delete') but doesn't mention critical details like whether deletion is permanent, requires specific permissions, or has side effects on connected resources. 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 no wasted words, making it easy to parse. It's appropriately sized for a simple deletion tool, though it could benefit from additional 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?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error conditions, or return values, which are essential for safe and effective use. The schema covers parameters well, but other critical aspects are missing.
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 clear parameter definitions, so the description doesn't need to add parameter details. It doesn't provide extra semantics beyond the schema, but the schema adequately covers the parameters, meeting the baseline for high 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 ('Delete') and resource ('a specific sub-interface'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'nodesDeleteNodeLoopback' or 'nodesDeleteFabricNode', which also delete resources but target different entities.
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, such as whether the sub-interface must be in a specific state, or references to related tools like 'nodesGetNodeSubInterfaces' 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. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify if it requires specific permissions, has rate limits, returns metadata only optionally, or what the response format is. For a tool with no annotations, 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 zero waste: 'Get a specific management port.' It's front-loaded and appropriately sized for its purpose, earning a perfect score 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 no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits like authentication needs. For a tool with 5 parameters and no structured output, more context is needed to fully guide 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?
Schema description coverage is 100%, with all 5 parameters well-documented in the input schema (e.g., 'fabricId', 'nodeId', 'id' for identification, 'candidate' for configuration, 'includeMetadata' for response detail). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 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 ('Get') and resource ('a specific management port'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'nodesGetManagementPorts' (plural), which likely retrieves multiple ports versus this single-port retrieval. The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'nodesGetManagementPorts' for retrieving multiple ports, nor does it explain prerequisites like authentication or context. Usage is implied by the name but not explicitly stated.
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 but only states it's an update operation. It doesn't mention whether this requires specific permissions, if it's idempotent, what happens to unspecified fields, error conditions, or side effects. For a mutation tool with 25 parameters, 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 two sentences that directly address purpose and basic usage. Every word earns its place with zero wasted text, though this comes at the cost of completeness.
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 (25 parameters, mutation operation, no annotations, no output schema), the description is inadequate. It doesn't explain what 'update' entails behaviorally, doesn't guide usage relative to siblings, and provides no context about the management port resource or update constraints.
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 25 parameters thoroughly. The description adds minimal value beyond stating you need to 'pass the resource ID and the fields to update,' which is implied by the tool name. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a specific management port'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'nodesUpdateFabricNode' or 'nodesUpdatePort', which appear to update different resources in the same 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?
The description provides basic usage syntax ('pass the resource ID and the fields to update as arguments') but offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or distinguish it from similar update tools in the sibling list.
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 must fully disclose behavioral traits. It mentions 'Update' but fails to explain critical aspects: whether this is a mutation (implied but not explicit), what permissions are required, if changes are reversible, how conflicts are handled, or what the response looks like. For a tool with 13 parameters and no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded and waste no words. However, it under-specifies by omitting necessary context, which slightly reduces its effectiveness despite the efficient structure.
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 (13 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks guidance on usage, behavioral details, error handling, and output expectations, making it inadequate for a mutation tool in a network management 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 already documents all parameters thoroughly. The description adds no additional meaning beyond implying that 'resource ID' and 'fields to update' are needed, which is redundant with the schema. This meets 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 verb ('Update') and resource ('a specific loopback'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'nodesUpdateNodeSubInterface' or 'nodesUpdateFabricNode', but the specificity of 'loopback' is adequate for basic clarity.
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 minimal usage guidance, stating only to 'pass the resource ID and the fields to update as arguments'. It offers no context on when to use this tool versus alternatives (e.g., 'nodesAddNodeLoopbacks' for creation, 'nodesDeleteNodeLoopback' for deletion) or any prerequisites, leaving the agent with insufficient direction.
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 mentions 'Update' but fails to disclose critical behavioral traits such as required permissions, whether the operation is idempotent, potential side effects (e.g., network disruption), or response format. This leaves significant gaps in understanding how the tool behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, using only two sentences without unnecessary details. However, it could be more structured by explicitly listing key updatable fields or constraints, though it avoids verbosity and earns its place efficiently.
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 (15 parameters, nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain what 'update' entails (e.g., partial vs. full updates), error handling, or return values, leaving the agent with insufficient context for a mutation tool in a network management domain.
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 15 parameters. The description adds no additional meaning beyond stating to pass 'resource ID and the fields to update', which is redundant with the schema. This meets the baseline for high schema coverage but 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 action ('Update') and resource ('a specific sub-interface'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'nodesUpdateNodeLoopback' or 'nodesUpdatePort', which also update specific resources, leaving room for improvement in distinguishing this specific tool.
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 minimal guidance by stating 'To use this tool, pass the resource ID and the fields to update as arguments', but it lacks explicit context on when to use this tool versus alternatives (e.g., 'nodesAddNodeSubInterfaces' for creation or 'nodesDeleteNodeSubInterface' for deletion). No prerequisites or exclusions are mentioned, offering limited help 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 adds port channels (implying a write/mutation operation) but doesn't mention required permissions, whether changes are reversible, rate limits, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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 brief (two sentences) and front-loaded with the core purpose. The second sentence provides a syntax example, which is useful but could be more informative. There's no wasted text, though it could be more structured with clearer separation of purpose and usage.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral constraints. The 100% schema coverage helps with parameters, but overall completeness is poor for a tool that modifies infrastructure.
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 fully documents both parameters (fabricId and portChannels). The description adds no parameter-specific information beyond a generic syntax example, which doesn't provide additional meaning beyond what's in the schema. 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.
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: 'Add one or more port channels.' It specifies the verb ('Add') and resource ('port channels'), and mentions it can handle multiple items. However, it doesn't differentiate from sibling tools like 'portchannelsUpdatePortChannel' or 'portchannelsDeletePortChannel' beyond the basic action.
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 includes a syntax example ('pass the required fields as direct arguments') but doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like 'portchannelsUpdatePortChannel' or 'portchannelsDeletePortChannel'.
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 address critical aspects like required permissions, whether the deletion is reversible, impact on connected systems, or error conditions. This leaves significant gaps for a destructive operation.
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 front-loaded with the core action and resource, making it immediately understandable 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?
For a destructive tool with no annotations and no output schema, the description is inadequate. It doesn't address behavioral implications, success/failure responses, or integration context. Given the complexity of network fabric operations and the lack of structured safety hints, more completeness 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?
The schema description coverage is 100%, with both parameters ('fabricId' and 'id') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, 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.
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 resource ('a specific port channel'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from other deletion tools in the sibling list (like 'fabricsDeleteFabric' or 'nodesDeleteFabricNode'), which would require explicit differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. While the sibling list shows other deletion tools, the description doesn't mention them or clarify the specific context for port channel deletion versus other fabric operations.
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 adds members, implying a mutation, but lacks details on permissions, side effects, error handling, or response format. The syntax hint is minimal and doesn't cover critical operational aspects.
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 brief and front-loaded with the core purpose, followed by a syntax example. Both sentences are relevant, with no wasted words. However, the example could be more precise (e.g., clarifying it's for illustration) to avoid potential confusion.
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 of adding network members (a mutation operation), no annotations, and no output schema, the description is insufficient. It lacks information on success/error responses, idempotency, constraints (e.g., duplicate members), and how it integrates with sibling tools, leaving significant gaps for 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?
Schema description coverage is 100%, so the schema fully documents the three parameters (fabricId, vniId, members). The description adds no additional semantic meaning beyond the schema, such as explaining relationships between parameters or usage nuances. Baseline 3 is appropriate as the schema handles 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 ('Add') and resource ('one or more VNI members'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'vnisAddFabricVnis' or 'vnisDeleteFabricVniMember', which would require more specific context about what constitutes a VNI member versus a VNI 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, such as 'vnisUpdateFabricVni' or 'vnisDeleteFabricVniMember'. It only offers a syntax example, which is helpful but doesn't address contextual usage, prerequisites, or exclusions.
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 only states the deletion action without behavioral details. It doesn't disclose if deletion is permanent, requires specific permissions, affects related resources, or has side effects, leaving significant gaps for a destructive operation.
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 with no wasted words, efficiently conveying the core action. It's appropriately sized for a simple deletion tool and front-loaded with 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 deletion tool with no annotations and no output schema, the description is incomplete. It lacks critical context like behavioral traits (e.g., permanence, dependencies), error handling, or result format, 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?
Schema description coverage is 100%, with both parameters ('fabricId', 'vniId') clearly documented in the schema. The description adds no additional parameter context beyond implying these are needed to identify the VNI, meeting 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 ('Delete') and target resource ('a specific VNI'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'vnisDeleteFabricVniMember' or 'vnisUpdateFabricVni', which would require mentioning scope or permanence, so it doesn't reach the highest clarity level.
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 'vnisDeleteFabricVniMember' or 'vnisUpdateFabricVni'. The description lacks context about prerequisites, dependencies, or consequences, offering minimal usage direction beyond the basic action.
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. While 'Delete' implies a destructive mutation, the description doesn't specify whether this operation is reversible, what permissions are required, or what happens on success/failure (e.g., error if member doesn't exist). 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 that directly states the tool's purpose without any fluff. It's front-loaded with the key action ('Delete') and target, making it easy to parse. Every word earns its place, and there's no wasted verbiage.
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 absence of an output schema, the description is incomplete. It doesn't cover behavioral aspects like idempotency, error conditions, or return values. For a deletion operation with three required parameters, more context is needed to ensure safe and correct usage by 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?
Schema description coverage is 100%, with clear descriptions for 'fabricId', 'vniId', and 'memberId' in the input schema. The description adds no additional parameter semantics beyond what's already documented in the schema (e.g., format examples or relationships between parameters). With high schema coverage, the baseline score of 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 clearly states the action ('Delete') and the target ('a specific VNI member'), which is a specific verb+resource combination. It distinguishes from sibling tools like 'vnisDeleteFabricVni' (which deletes the entire VNI) by specifying 'member' deletion. However, it doesn't explicitly mention the resource hierarchy (fabric→VNI→member), which could be slightly more specific.
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., the member must exist), related operations (e.g., use 'vnisGetFabricVniMember' to check first), or sibling tools like 'vnisAddFabricVniMembers' for adding members. Without this context, an agent might struggle with proper sequencing.
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. 'Get' implies a read operation, but the description doesn't mention authentication requirements, rate limits, error conditions, or what the response contains. For a tool with 5 parameters and no output schema, 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, clear sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, 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 complexity (5 parameters, 3 required), lack of annotations, and no output schema, the description is incomplete. It doesn't help an agent understand what a 'VNI member' is, how it relates to fabrics and VNIs, what data is returned, or any operational constraints. For a read operation in a network configuration context, more context 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 all parameters are documented in the input schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain relationships between fabricId, vniId, and memberId). With high schema coverage, the baseline score of 3 is appropriate.
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 ('Get') and the resource ('a specific VNI member'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'vnisGetFabricVni' or 'vnisGetFabricVniMembers', which appear to retrieve related but different resources.
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 sibling tools like 'vnisGetFabricVni' (gets VNI) and 'vnisGetFabricVniMembers' (gets all members), an agent wouldn't know whether to use this for a single member or if the other tools are more appropriate for broader queries.
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 but provides minimal information. It states this is a 'Get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, response format, or whether this returns all members or requires pagination. The description is insufficient for a tool with 4 parameters and no output schema.
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 - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it easy to parse quickly. The structure is front-loaded with the core functionality.
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 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'VNI members' are in this context, what format the response takes, or how this tool relates to other VNI operations in the sibling list. The minimal description leaves too many questions unanswered for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the input schema. The description doesn't add any parameter-specific information beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional context about parameter interactions or usage patterns.
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 ('Get') and resource ('list of VNI members'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'vnisGetFabricVniMember' (singular) or 'vnisGetFabricVni', but the verb+resource combination is specific enough for basic understanding.
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 'vnisGetFabricVniMember' (singular member) or 'vnisGetFabricVni' (VNI details), nor does it specify prerequisites or appropriate contexts for calling this 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 provided, the description carries full burden for behavioral disclosure. It states this is an 'Add' operation (implying creation/mutation) but provides no information about permissions required, whether this is idempotent, what happens on conflicts, or what the response looks like. The syntax example is helpful but insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The syntax example is relevant but could be more efficiently integrated. No wasted sentences, though it could be slightly more polished.
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 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after adding routes, error conditions, or system behavior. The comprehensive schema helps but doesn't compensate for the lack of operational context in the description.
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 minimal value by mentioning 'required fields' and providing a syntax example, but doesn't explain parameter relationships or constraints beyond what's already in the comprehensive schema.
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 ('Add') and resource ('static routes'), and specifies it can handle multiple routes ('one or more'). However, it doesn't differentiate from sibling tools like 'vrfsUpdateFabricStaticRoute' or 'vrfsDeleteFabricStaticRoute' beyond the basic 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 like update or delete operations. It only gives a basic syntax example but doesn't address prerequisites, error conditions, or appropriate contexts for static route creation.
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 only states the action ('Add') without disclosing behavioral traits. It doesn't mention whether this is a creation operation, what permissions are required, if it's idempotent, what happens on failure, or any rate limits. 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 only two sentences, both of which earn their place. The first sentence states the purpose, and the second provides essential syntax guidance. There's zero wasted verbiage or redundant 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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'Add' means operationally, what the response looks like, error conditions, or how this tool relates to the broader VRF management workflow. The context signals indicate this is a complex tool (nested objects in schema), but the description provides minimal 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 both parameters (fabricId and vrfs). The description adds no meaningful parameter semantics beyond what's already in the schema, merely providing a syntax example. Baseline 3 is appropriate when the schema does all 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 ('Add') and resource ('one or more VRFs'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'vrfsAddFabricStaticRoutes' or 'vrfsUpdateFabricVrf' beyond the basic resource type, missing explicit sibling distinction.
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 basic syntax guidance ('pass the required fields as direct arguments') but offers no guidance on when to use this tool versus alternatives like 'vrfsUpdateFabricVrf' for modifications or 'vrfsDeleteFabricVrf' for removal. There's no mention of prerequisites, dependencies, or typical use cases.
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 only states the action without behavioral details. It doesn't disclose whether this is destructive (implied by 'Delete' but not explicit), permission requirements, error conditions, or what happens to dependent configurations. This is inadequate 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, direct sentence with zero wasted words. It's perfectly front-loaded and appropriately sized for a simple delete operation.
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 destructive operation with no annotations and no output schema, the description is insufficient. It should explain what 'Delete' entails (permanent removal?), success/failure responses, and potential side effects. The current description leaves too many behavioral 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?
The description adds no parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between fabricId, vrfId, and routeId, or provide context about valid values. Baseline 3 is appropriate since the schema documents all parameters adequately.
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 resource ('a specific static route'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'vrfsDeleteFabricVrf' or 'vrfsUpdateFabricStaticRoute' beyond the obvious difference in target resource.
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 (e.g., route must exist), consequences of deletion, or relationships with sibling tools like 'vrfsAddFabricStaticRoutes' or 'vrfsUpdateFabricStaticRoute'.
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. While 'Delete' implies a destructive mutation, the description lacks critical details such as whether this action is irreversible, what permissions are required, if it affects dependent resources, or what happens on success/failure. This is inadequate for a destructive operation with zero annotation coverage.
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 with zero waste—it states the action and target without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent 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 complexity as a destructive deletion operation, the lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like safety, side effects, or response format, which are crucial for an agent to invoke this tool correctly and handle outcomes.
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 both parameters ('fabricId' and 'vrfId') clearly documented in the input schema. The description adds no additional meaning beyond what the schema provides, 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.
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 the resource ('a specific VRF'), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'vrfsDeleteFabricStaticRoute' or 'fabricsDeleteFabric', which also delete resources in the same domain, leaving some ambiguity about 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 prerequisites (e.g., ensure the VRF is not in use), exclusions, or related tools like 'vrfsGetFabricVrfs' for listing VRFs before deletion, leaving the agent with no contextual usage information.
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 but offers minimal information. It states it's a read operation ('Get'), implying it's likely non-destructive, but doesn't clarify permissions, rate limits, response format, or pagination. For a tool with three parameters and no output schema, this leaves significant gaps in understanding how it 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 wasted words. It's front-loaded with the core purpose ('Get the list of VRFs'), making it immediately understandable. Every word earns its place, and there's no redundancy or 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 the tool's complexity (3 parameters, no annotations, no output schema), the description is insufficiently complete. It lacks details on behavioral traits (e.g., response structure, error handling), usage context, and how to interpret results. While the schema covers parameters, the overall context for effective tool invocation is poorly supported.
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%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain VRF concepts or how parameters interact). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Get') and resource ('list of VRFs'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'vrfsGetFabricVrf' (singular) by specifying 'list of VRFs' (plural), indicating it retrieves multiple items rather than a single one. However, it doesn't explicitly differentiate from other list tools like 'vnisGetFabricVnis' beyond the 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 (e.g., needing a fabricId), compare it to similar tools like 'vrfsGetFabricVrf' for single VRF retrieval, or indicate any contextual constraints. The agent must infer usage solely from the tool name and parameters.
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 but provides almost none. It states this is an update operation but doesn't mention what happens to existing fields not specified, whether the operation is idempotent, what permissions are required, or what the response contains. For a mutation tool with 11 parameters and complex nested objects, this is a significant gap in behavioral context.
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 with just two sentences, front-loading the core purpose. There's no wasted verbiage, though some might argue it's too brief given the tool's complexity. Every sentence serves a purpose: the first states what the tool does, the second provides basic usage syntax.
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 (11 parameters with nested objects, no annotations, no output schema), the description is inadequate. It doesn't explain the relationship between parameters, doesn't indicate which fields are mutable vs read-only (though the schema does), and provides no guidance on partial updates or error conditions. For a mutation tool of this complexity, the description should do more to complement the schema.
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 provides comprehensive parameter documentation. The description adds minimal value beyond the schema by mentioning 'resource ID and the fields to update' but doesn't clarify which parameters are identifiers vs updatable fields, or provide any additional semantic context. 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 ('Update') and resource ('a specific static route'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'vrfsUpdateFabricVrf' or 'vrfsAddFabricStaticRoutes' beyond the basic verb+resource combination.
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 minimal usage guidance with 'To use this tool, pass the resource ID and the fields to update as arguments' - this is basic syntax instruction rather than contextual guidance. There's no indication of when to use this vs alternatives like 'vrfsAddFabricStaticRoutes' or 'vrfsDeleteFabricStaticRoute', nor any prerequisites or constraints beyond what's implied 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without mentioning whether this is a read-only operation, if it requires specific permissions, what the response format might be, or any rate limits. For a tool with no annotations, 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 front-loaded with the core purpose, making it easy to parse quickly.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose clearly but lacks behavioral details, usage context, and output information, leaving room for improvement in completeness.
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, so the schema already documents all four parameters (fabricId, nodeId, candidate, includeMetadata) thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline of 3 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 ('Get') and resource ('list of loopbacks'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'nodesGetNodeLoopback' (singular), which appears to retrieve a single loopback rather than a list, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include 'nodesGetNodeLoopback' (singular) and 'nodesAddNodeLoopbacks' (add), there's no indication of when to choose this list-retrieval tool over those, nor any context about prerequisites or typical use cases.
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 'Get' implies a read operation, but doesn't specify if it's safe (non-destructive), what permissions are required, or details about rate limits or response format. For a 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, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get a specific port channel'), making it efficient and easy to parse. 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.
Completeness3/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 (4 parameters, 2 required) and lack of annotations or output schema, the description is minimally adequate. It states what the tool does but lacks behavioral details, usage context, and output information. This results in a description that is complete enough to understand the basic purpose but insufficient for optimal agent operation without additional inference.
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%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond implying retrieval of a port channel, which is already clear from the tool name and schema. This meets the baseline score of 3 when the schema handles parameter documentation effectively.
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 ('Get') and resource ('a specific port channel'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'portchannelsGetAllPortChannels' or 'portchannelsUpdatePortChannel', which would require mentioning it retrieves a single port channel by ID rather than listing all or modifying one.
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 'portchannelsGetAllPortChannels' for listing all port channels or 'portchannelsUpdatePortChannel' for modifications, nor does it specify prerequisites such as needing a fabric ID and port channel ID. This leaves the agent without context for tool selection.
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 discloses that this is a configuration update tool via REST API and explicitly states it's a 'SAFE OPERATION' that doesn't execute code or commands, which helps clarify safety. However, it lacks details on permissions needed, whether changes are reversible, rate limits, or what happens to existing settings not mentioned.
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 appropriately concise with three sentences: purpose statement, safety/behavioral note, and basic usage instruction. It's front-loaded with the core purpose and safety information. However, the second sentence could be more streamlined, and it lacks structural elements like bullet points for clarity.
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 complexity (network configuration update with nested parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and safety but misses critical context like error handling, response format, idempotency, or dependencies on other tools (e.g., fabrics or nodes operations). For a mutation tool with rich parameter schema, more completeness 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 fully documents the three parameters (fabricId, nodeId, ports). The description adds minimal value beyond the schema by mentioning 'pass the resource ID and the fields to update as arguments,' which aligns with the schema but doesn't provide additional syntax, format, or semantic context. 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.
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: 'Update the list of ports' and specifies it configures network fabric port settings (speed, MTU, VLAN, etc.) via REST API. It distinguishes from siblings by mentioning it doesn't execute code or commands on the system, though it doesn't explicitly differentiate from other port-related tools like nodesUpdatePort or nodesResetPort.
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 minimal usage guidance: 'To use this tool, pass the resource ID and the fields to update as arguments.' It doesn't specify when to use this tool versus alternatives like nodesUpdatePort or nodesResetPort, nor does it mention prerequisites, constraints, or typical scenarios for updating port lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly discloses this is a configuration update operation (not code execution), specifies it's a REST API call, and includes a safety disclaimer ('[SAFE OPERATION]'). However, it doesn't mention potential side effects, authentication requirements, rate limits, or what happens when updating read-only fields (which the schema shows exist).
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 and well-structured: three sentences that each serve a distinct purpose (action statement, safety/implementation context, usage instruction). No wasted words, front-loaded with the core purpose, and appropriately sized for a tool with extensive schema documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 30 parameters, nested objects, no annotations, and no output schema, the description is minimal. While concise, it doesn't adequately address the complexity - it lacks information about return values, error conditions, side effects, or how to handle the many read-only fields shown in the schema. The safety statement helps but doesn't fully compensate for the missing 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 already documents all 30 parameters thoroughly. The description adds minimal value beyond the schema - it mentions passing 'resource ID and the fields to update' but doesn't provide additional context about parameter relationships, constraints, or examples. The baseline of 3 is appropriate given the comprehensive schema coverage.
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 specific action ('Update a specific port') and resource ('network fabric port settings'), distinguishing it from sibling tools like nodesResetPort or nodesSetPorts. It provides concrete examples of what gets updated (speed, MTU, VLAN, etc.) and specifies the implementation method (REST API).
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 context by mentioning it's for configuring network fabric port settings, but doesn't explicitly state when to use this tool versus alternatives like nodesResetPort or nodesSetPorts. It provides basic usage instructions ('pass the resource ID and the fields to update') but lacks guidance on prerequisites, constraints, or comparison with sibling tools.
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:

[![hyperfabric_MCP MCP server](https://glama.ai/mcp/servers/jim-coyne/hyperfabric_MCP/badges/card.svg)](https://glama.ai/mcp/servers/jim-coyne/hyperfabric_MCP)

Score Badge

Copy to your README.md:

[![hyperfabric_MCP MCP server](https://glama.ai/mcp/servers/jim-coyne/hyperfabric_MCP/badges/score.svg)](https://glama.ai/mcp/servers/jim-coyne/hyperfabric_MCP)

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/jim-coyne/hyperfabric_MCP'

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