EVE-NG MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions in the EVE-NG domain. For example, connect_node_to_network vs connect_node_to_node handle different connection types, while start_node vs wipe_node perform fundamentally different operations on nodes. No tools appear to overlap or cause confusion.
Naming Consistency5/5
All 26 tools follow a consistent verb_noun or verb_noun_noun pattern throughout. Examples include create_lab, delete_node, list_network_types, and connect_node_to_network. The naming is perfectly uniform with no mixing of conventions or stylistic deviations.
Tool Count4/5
With 26 tools, the count is on the higher side but reasonable for a comprehensive network emulation platform like EVE-NG. The tools cover server management, lab operations, node lifecycle, and network configuration, which justifies the breadth. It's slightly heavy but well-scoped for the domain.
Completeness5/5
The toolset provides complete CRUD/lifecycle coverage for EVE-NG's core domain. It includes server connection/disconnection, lab creation/deletion/listing, node addition/deletion/starting/stopping/wipe, network management, and detailed information retrieval. No obvious gaps exist for typical emulation workflows.
Average 3.1/5 across 26 of 26 tools scored.
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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 authentication and that the connection is maintained, but doesn't disclose critical behavioral traits: what happens on authentication failure, whether credentials are stored/encrypted, session timeout details, rate limits, or error handling. For a security-sensitive authentication 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 appropriately concise with two short paragraphs. The first sentence states the purpose clearly, and the second adds useful context about connection persistence. There's no unnecessary fluff, and it's 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?
Given the complexity (authentication/connection tool with security implications), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't cover parameter meanings, error conditions, return values, or security considerations. For this context, it should provide more guidance about authentication behavior and parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description mentions 'credentials' generically but doesn't explain any of the 5 parameters (host, username, password, port, protocol) or their semantics. It fails to compensate for the complete lack of schema documentation, leaving parameters undocumented.
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: 'Connect to EVE-NG server and authenticate' and 'establishes a connection to the EVE-NG server using the provided credentials.' It specifies the verb (connect/authenticate) and resource (EVE-NG server), but doesn't explicitly differentiate from sibling tools like 'test_connection' or 'disconnect_eveng_server' beyond the obvious connection vs. disconnection 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 minimal guidance: it mentions the connection 'will be maintained for subsequent operations,' implying this should be used before other operations. However, it doesn't specify when to use this versus alternatives like 'test_connection' (which might check connectivity without authentication) or clarify prerequisites. No explicit when-not-to-use or comparison with siblings is 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'retrieves' information (implying read-only) and mentions what information is included (configuration, status, interfaces, connectivity), but doesn't cover critical aspects like authentication requirements, error handling, rate limits, or whether it requires the node to be running. The disclosure is incomplete for a tool that likely interacts with a lab environment.
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 purpose and scope. The first sentence states the core function, and the second elaborates on what information is retrieved. There's no unnecessary verbiage, though it could be slightly more structured with bullet points for the information types.
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 interacting with a lab/node system, no annotations, no output schema, and poor parameter documentation, the description is insufficient. It doesn't explain what format the detailed information returns, how to interpret the configuration/status/interface data, or error conditions. For a tool that likely returns structured node data in a lab environment, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters beyond the tool name implying a 'node' is needed. With 0% schema description coverage and 1 required parameter (though the schema shows 2 nested parameters: lab_path and node_id), the description fails to explain what 'arguments' should contain, what format lab_path expects, or how node_id is determined. This leaves parameters completely undocumented.
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 with a specific verb ('Get') and resource ('node'), specifying it retrieves 'detailed information' about a specific node. It distinguishes from siblings like 'list_nodes' (which lists nodes) and 'get_lab_details' (which focuses on labs), but doesn't explicitly contrast with 'get_lab_topology' which might also provide node information in a network 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. It doesn't mention when to choose 'get_node_details' over 'get_lab_topology' (which might include node details) or 'list_nodes' (which provides basic node information), nor does it specify prerequisites like needing an existing node or lab 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 for behavioral disclosure. It states the tool creates connections but lacks critical details: whether this is a mutation (implied by 'creates'), permission requirements, error conditions (e.g., invalid interfaces), idempotency, or what happens on success/failure. The description adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly explain the tool's purpose. It's front-loaded with the main action and avoids unnecessary details. Every sentence earns its place by clarifying the connection type.
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 (mutation tool with 5 parameters, no annotations, no output schema), the description is incomplete. It explains what the tool does at a high level but lacks parameter guidance, behavioral details, error handling, and output expectations. For a tool that modifies lab topology, 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (the schema has descriptions but they're generic like 'Arguments for connect_node_to_node tool'), so the description must compensate. However, the description provides zero information about any parameters—it doesn't mention lab_path, node IDs, interfaces, or their semantics. This leaves all 5 required parameters undocumented.
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: 'Connect two nodes together directly' and 'creates a direct point-to-point connection between two nodes in the lab, enabling direct communication between them.' This specifies the verb (connect/create) and resource (nodes), but doesn't explicitly differentiate from sibling tools like 'connect_node_to_network' or 'test_connection'.
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 prerequisites (e.g., nodes must exist), exclusions (e.g., cannot connect nodes already connected), or comparisons to sibling tools like 'connect_node_to_network' for different connection types.
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 creates a lab but doesn't disclose permissions needed, whether it's idempotent, error conditions (e.g., invalid path), or what happens on success (e.g., returns lab ID). 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 and front-loaded with the main purpose in the first sentence. Both sentences are relevant, though the second could be more informative. There's no wasted text, but it's under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameter meanings, error handling, and return values, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only vaguely mentions 'name and metadata' and 'given path'. It doesn't explain the purpose of each parameter (e.g., 'description', 'author', 'version'), their formats, or constraints, leaving most of the 5 parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a new lab') and resource ('in EVE-NG'), with specific mention of 'name and metadata' and 'given path'. It distinguishes from siblings like 'list_labs' or 'delete_lab' by focusing on creation, though it doesn't explicitly contrast with 'create_lab_network' which creates a different 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., server connection), exclusions (e.g., duplicate names), or comparisons to sibling tools like 'create_lab_network' for related 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 creates a network but lacks details on permissions required, whether the operation is idempotent, error conditions, or what happens on success (e.g., returns a network ID). 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 appropriately sized with two sentences: the first states the purpose, and the second adds specifics. It's front-loaded with the core action. However, the second sentence could be more structured (e.g., bullet points for parameters) to improve clarity without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 sub-parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover parameter details, behavioral traits, error handling, or return values. For a tool that creates resources in a lab environment, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'type and positioning' which loosely maps to 'network_type', 'left', and 'top' parameters, but doesn't explain the 'lab_path' or 'name' parameters. With 1 parameter (a nested object with 5 sub-properties) and no schema descriptions, the description adds minimal value beyond what's inferred from parameter names.
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 ('creates a new network') and resource ('in a lab'), with additional context about network types (cloud, bridge, NAT, etc.) and positioning. It distinguishes from siblings like 'list_lab_networks' or 'delete_lab_network' by specifying creation. However, it doesn't explicitly differentiate from other creation tools like 'create_lab' 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing lab from 'create_lab'), exclusions, or comparisons to siblings like 'list_network_types' for type selection. The description implies usage for network creation but offers no contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'retrieves' information, implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a brief opening sentence followed by a more detailed explanation. Both sentences are relevant and avoid redundancy, though the structure could be slightly improved by integrating the two parts more seamlessly. 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 tool's complexity (retrieving topology with 1 parameter), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address parameter usage, return format, or behavioral traits, making it inadequate for an agent to fully understand how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, failing to explain the 'lab_path' input required by the schema. The description adds no meaning beyond the schema, leaving the parameter's purpose and format unclear to the agent.
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: 'retrieves the complete topology of the lab including all nodes, networks, and their connections.' It specifies the verb ('retrieves') and resource ('complete topology'), though it doesn't explicitly differentiate from siblings like 'get_lab_details' or 'get_node_details' which might provide partial information. The purpose is well-defined but lacks sibling comparison.
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 scenarios where this is preferred over other tools like 'get_lab_details' or 'list_nodes', nor does it specify prerequisites or exclusions. Usage is implied only by the general purpose, with no explicit 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. While it mentions retrieving a list with 'basic information,' it doesn't specify what that includes (names, IDs, statuses), whether results are paginated, what happens with invalid paths, or any authentication requirements. The description provides minimal behavioral context beyond the basic operation.
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. The first sentence states the core function, and the second provides slightly more detail. There's no unnecessary verbiage, though the structure could be slightly improved by front-loading more critical information about the path parameter.
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, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what 'basic information' includes in the returned list, doesn't clarify the path parameter's semantics, and provides no behavioral context about error conditions, permissions, or result formatting. The description leaves too many open questions for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter 'path,' the description provides no additional semantic information about what this parameter means, what format it expects, what valid values are, or how it affects the listing. The mention of 'specified path' in the description is too vague to compensate for the complete lack of schema 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 ('list available labs') and resource ('in EVE-NG'), with the first sentence providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_lab_details' or 'get_lab_topology', 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 no guidance on when to use this tool versus alternatives like 'get_lab_details' for specific lab information or 'list_nodes' for node-level listings. It mentions retrieving labs 'in the specified path' but doesn't explain when different paths should be used or what the default '/' path represents.
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 'creates a connection' which implies a write/mutation operation, but doesn't specify permissions needed, whether it's idempotent, error conditions (e.g., invalid interface), or side effects (e.g., network changes). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second elaborates without redundancy. Every sentence earns its place by clarifying the action and outcome, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool connecting network components), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't cover behavioral aspects like success/failure responses, prerequisites, or error handling, which are crucial for an agent to use this tool effectively in a lab environment.
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 doesn't mention any parameters explicitly. With schema description coverage at 0% (parameters are documented only with titles like 'Lab Path', 'Node Id'), the description doesn't compensate by explaining what arguments are needed or their roles. However, the tool has only 1 parameter (an object with nested properties), so the baseline is slightly higher than minimal, but it fails to add meaning beyond the 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 tool's purpose: 'Connect a node to a network' and elaborates with 'creates a connection between a node interface and a network in the lab, enabling communication through that network.' This specifies the verb (connect/create connection) and resource (node interface to network), but doesn't explicitly differentiate from sibling tools like connect_node_to_node, which is why it's not 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. It doesn't mention prerequisites (e.g., lab must exist, node must be in lab), when not to use it (e.g., if already connected), or refer to sibling tools like connect_node_to_node for different connection types. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't cover aspects like authentication requirements, rate limits, error handling, or what 'comprehensive information' entails. For a tool with zero annotation coverage, 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 appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second elaborates on what information is retrieved. There's no wasted text, making it efficient, 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?
Given the tool's complexity (retrieving detailed lab info), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return format, error cases, or how the retrieved data (metadata, nodes, networks, status) is structured, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no specific meaning beyond the input schema, which has 0% description coverage. It mentions retrieving info about 'a specific lab', hinting at the 'lab_path' parameter's purpose, but doesn't explain the parameter's format, constraints, or examples. With low schema coverage, the description provides minimal compensation, aligning with the baseline for adequate but incomplete param info.
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', 'retrieves') and resource ('detailed information about a specific lab', 'comprehensive information about a lab'), making the purpose explicit. However, it doesn't distinguish this tool from sibling tools like 'get_lab_topology' or 'get_node_details', which also retrieve lab-related information, 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. It doesn't mention siblings like 'get_lab_topology' (which might provide structural info) or 'list_labs' (which lists labs without details), nor does it specify prerequisites such as needing a lab path. This leaves the agent with minimal 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 the full burden of behavioral disclosure. It states the tool 'retrieves information' and lists networks, implying a read-only operation, but does not specify details like whether it requires authentication, how it handles errors, if there are rate limits, or what the output format looks like. 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 appropriately sized and front-loaded: it starts with a clear purpose statement ('List all networks in a lab.'), followed by a slightly more detailed sentence. There is no wasted text, and every sentence adds value by elaborating on the scope of information retrieved. It is efficient 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 context: no annotations, no output schema, 1 parameter with low schema coverage, and moderate complexity (listing networks in a lab), the description is incomplete. It lacks details on behavioral aspects like authentication needs, error handling, or output format, and does not address parameter usage. For a tool that interacts with lab configurations, more context is needed 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?
The input schema has 1 parameter with 0% description coverage, as the schema's description ('Arguments for list_networks tool.') is generic. The tool description does not mention the 'lab_path' parameter or explain its semantics, such as what format the path should be in or examples beyond the schema's hint. Since schema coverage is low, the description does not compensate, but with only 1 parameter, the baseline is adjusted to 3 as it's minimally adequate.
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: 'List all networks in a lab' and 'retrieves information about all networks configured in the specified lab'. It specifies the verb ('list', 'retrieves') and resource ('networks in a lab'), making the action clear. However, it does not explicitly distinguish this tool from sibling tools like 'list_network_types' or 'get_lab_topology', which might also involve network-related information, 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. It does not mention any prerequisites, such as needing an existing lab, or compare it to siblings like 'list_network_types' (which might list network types rather than configured networks) or 'get_lab_topology' (which might provide a broader view). Without such context, the agent lacks clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the prerequisite state ('stopped state') which is useful, but doesn't describe what 'start' entails (e.g., booting a virtual machine, initializing services), potential side effects, error conditions, or response format. For a mutation tool with zero 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 appropriately sized with two sentences that are front-loaded: the first states the purpose, and the second adds a key constraint. There is no wasted text, and it efficiently communicates essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of starting a node (a mutation operation), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on parameters, behavioral outcomes, error handling, and what the tool returns. While concise, it doesn't provide enough context 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description provides no information about parameters, not even mentioning that 'arguments' is required or what it contains (e.g., lab_path and node_id). This fails to compensate for the schema's lack of descriptions, leaving parameters completely unexplained.
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 ('start') and resource ('a node in the lab'), making the purpose understandable. It distinguishes from siblings like 'stop_node' by specifying the opposite action, but doesn't explicitly differentiate from 'start_all_nodes' which starts multiple nodes. The description is specific but lacks 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'The node must be in stopped state to be started successfully,' which suggests when the tool will work. However, it doesn't explicitly state when to use this vs. alternatives like 'start_all_nodes' or mention prerequisites beyond the node state. The guidance is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the node is 'created but not automatically started,' which is useful context about the tool's effect. However, it fails to disclose critical behavioral traits such as whether this is a destructive/mutative operation (implied by 'adds'), permission requirements, error conditions (e.g., invalid lab path), or rate limits. For a mutation tool with zero annotation coverage, this leaves significant 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 appropriately sized and front-loaded, with the core purpose in the first sentence and additional behavioral context in the second. Every sentence earns its place by adding value (creation state clarification), with zero redundant or verbose language. The structure is clear 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 complexity (mutation tool with 13 nested parameters), no annotations, and no output schema, the description is incomplete. It covers basic purpose and one behavioral aspect (node not auto-started) but lacks details on permissions, error handling, return values, or parameter semantics. For a tool that modifies lab state, this leaves the agent with insufficient context to use it effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'template, configuration, and positioning,' which loosely maps to some parameters (e.g., template, config, left/top), but provides no details on parameter meanings, relationships, or constraints beyond what's implied. With 1 parameter (a nested object with 13 sub-properties) and no schema descriptions, the description adds minimal semantic value, failing to adequately explain the complex input structure.
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 ('adds a new node') and resource ('to an existing lab'), making the purpose immediately understandable. It distinguishes from siblings like 'create_lab' (creates lab vs adds node) and 'delete_node' (deletion vs addition). However, it doesn't explicitly differentiate from 'list_nodes' or 'get_node_details' in terms of creation vs retrieval.
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 stating 'to an existing lab' and mentioning the node 'will be created but not automatically started,' which suggests when to use this vs 'start_node.' However, it lacks explicit guidance on when to choose this over alternatives like 'create_lab' or prerequisites (e.g., lab must exist). No when-not-to-use or sibling comparisons 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. It states the tool 'retrieves' information, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or response format. This is a significant gap for a 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 well-structured and concise, with two sentences that efficiently convey the tool's purpose and details. It avoids redundancy and is front-loaded, though minor trimming (e.g., 'detailed information' could be more precise) prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It lacks information on behavioral aspects like authentication, error cases, or return value structure, which are crucial for an agent to use it effectively in a server management context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned any implicit context (e.g., server connection). Baseline is 4 since no parameters exist.
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 with the verb 'retrieves' and resource 'EVE-NG server information and status', specifying details like version, status, capabilities, and system information. However, it doesn't explicitly differentiate from sibling tools like 'test_connection' or 'get_lab_details', which reduces 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., server connectivity), exclusions, or comparisons to siblings like 'test_connection' for basic connectivity checks, 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 full burden. It mentions that 'nodes will be started according to their configured delay settings', which adds useful behavioral context beyond just 'start'. However, it fails to disclose critical aspects: whether this is a destructive/mutative operation (likely yes), what permissions are needed, what happens if nodes are already running, error conditions, or what the output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured: two sentences that directly address what the tool does and a key behavioral detail. Every word earns its place with zero redundancy or fluff. It's front-loaded with the core 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 no annotations, 0% schema coverage, no output schema, and this being a mutative operation (starting nodes), the description is incomplete. It lacks critical context: error handling, side effects, permissions, output format, and detailed parameter guidance. For a tool that likely changes system state, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specified lab' but provides no details about the 'lab_path' parameter—no format examples, constraints, or what constitutes a valid lab. The description adds no parameter semantics beyond what's implied by the tool name, leaving the single required parameter poorly documented.
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 ('start') and resource ('all nodes in a lab'), making the purpose immediately understandable. It distinguishes from sibling tools like 'start_node' (which starts individual nodes) by specifying 'all nodes'. However, it doesn't explicitly contrast with 'stop_all_nodes' or 'wipe_all_nodes', which would have made it a perfect 5.
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 ('in a lab') but provides no explicit guidance on when to use this versus alternatives like 'start_node' for individual nodes or 'stop_all_nodes' for stopping. There's no mention of prerequisites (e.g., lab must exist, nodes must be stopped) or exclusions (e.g., cannot start if already running).
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 full burden. It discloses key behavioral traits: 'gracefully shut down' and 'state will be preserved,' which are crucial for understanding this non-destructive operation. However, it lacks details about permissions, error conditions, or what 'preserved' entails exactly.
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 front-loaded with the core purpose, followed by clarifying behavioral details in two concise sentences. Every sentence adds value without redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a state-altering operation with 1 parameter at 0% schema coverage and no output schema), the description is incomplete. It covers the basic action and preservation behavior but lacks parameter explanations, error handling, and output details, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'a specific node' but doesn't explain the required 'arguments' parameter or its nested 'lab_path' and 'node_id' fields. No parameter details are provided beyond the tool's general purpose.
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 ('stop') and resource ('a specific node'), with additional context about graceful shutdown and state preservation. However, it doesn't explicitly differentiate from sibling tools like 'stop_all_nodes' or 'wipe_node' beyond the 'specific node' phrasing.
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 like 'stop_all_nodes' (for multiple nodes) or 'wipe_node' (for destructive reset). The description mentions 'a specific node' but doesn't contrast with other node control operations or specify prerequisites.
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 'retrieves information' (implying read-only) and lists included data types (status, configuration, connectivity), which is helpful. However, it doesn't cover critical aspects like whether it returns a summary or detailed view, pagination, error conditions, or authentication needs, leaving significant gaps 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 efficiently structured in two sentences: the first states the core action, and the second elaborates on what information is retrieved. Every sentence adds value without redundancy, and it's front-loaded with the main purpose, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the purpose and data types returned, but lacks details on behavioral traits, error handling, and output structure. For a simple list tool, this is adequate but leaves room for improvement, especially in guiding usage among 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?
Schema description coverage is 0% (the parameter 'lab_path' has no description in the schema), so the description must compensate. The description mentions 'specified lab' and implies the lab_path parameter, but doesn't explain its format, constraints, or examples beyond what's in the schema title. It adds minimal semantic value, meeting the baseline for low coverage without fully addressing the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list', 'retrieves') and resource ('nodes in a lab'), making the purpose evident. It distinguishes from siblings like 'get_node_details' by specifying it returns information about all nodes rather than a single node. However, it doesn't explicitly contrast with 'list_labs' or 'list_lab_networks', which would have made it 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 like 'get_node_details' for single nodes or 'list_labs' for labs. It mentions the scope ('all nodes in the specified lab') but doesn't specify prerequisites, exclusions, or contextual alternatives, leaving the agent to infer usage from 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 the tool 'returns server status information,' which is helpful, but lacks details on error handling, authentication requirements, rate limits, or whether it's a read-only operation. For a connection-testing tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences, front-loading the purpose ('Test connection to EVE-NG server') and following with elaboration. There's no wasted text, though it could be slightly more informative about behavior without losing efficiency.
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 low complexity (likely a simple connectivity check), no annotations, no output schema, and minimal parameters, the description is adequate but incomplete. It covers the purpose and return value ('server status information'), but lacks details on error cases, authentication, or how it differs from sibling tools. This meets minimum viability but has clear gaps.
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 one parameter ('arguments') with 0% description coverage, and the schema provides no details about its properties. The description doesn't mention parameters at all, which is acceptable here since the tool likely requires no user-provided inputs beyond a connection context. With zero parameters needing explanation, a baseline of 4 is appropriate, as the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Test connection to EVE-NG server' and 'verifies that the connection to the EVE-NG server is working properly.' It uses specific verbs ('test', 'verifies') and identifies the resource (EVE-NG server). However, it doesn't explicitly differentiate from sibling tools like 'connect_eveng_server' or 'disconnect_eveng_server', which prevents 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare it to similar tools like 'connect_eveng_server' or 'disconnect_eveng_server'. The agent must infer usage from the purpose alone, 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. It states the tool 'retrieves all available node templates,' implying a read-only operation, but lacks details on permissions, rate limits, output format, or any side effects. This leaves gaps 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 front-loaded with the core purpose in the first sentence and adds useful detail in the second. Both sentences earn their place by clarifying scope and content, with no redundant or verbose language, making it efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter-less schema, the description is minimally adequate. It explains what the tool does but lacks behavioral details like output format or usage context. For a read-only list tool, it's functional but could be more complete by addressing these gaps.
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 one parameter ('arguments') with 0% description coverage and no properties, indicating zero parameters in practice. The description doesn't mention any parameters, which is appropriate here since there are none to document, aligning with the schema's empty structure.
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 with 'List available node templates in EVE-NG' and specifies what it retrieves ('all available node templates... including their supported images and options'). It distinguishes from siblings like 'list_labs' or 'list_nodes' by focusing on templates rather than labs or nodes themselves, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions templates 'can be used to create nodes in labs,' implying a prerequisite context, but offers no explicit when/when-not instructions or references to sibling tools like 'add_node' for creating nodes with templates.
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 describes a read operation ('retrieves'), which is clear, but lacks details on behavioral traits such as permissions needed, rate limits, error handling, or what the return format looks like (e.g., list structure). For a tool with no annotation coverage, 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 appropriately sized with two sentences that are front-loaded and zero waste. The first sentence states the purpose, and the second elaborates with specifics and examples, making it efficient 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, 0% schema coverage, 1 undocumented parameter, and no output schema, the description is incomplete. It adequately explains the tool's purpose but fails to address parameter meaning, return values, or behavioral context, which are critical for a tool with such limited structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with 1 parameter (lab_path) undocumented in the schema. The description does not mention or explain any parameters, failing to compensate for the lack of schema documentation. This leaves the parameter's purpose and usage unclear, adding no value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('retrieves all available network types') and resource ('network types in EVE-NG'), with explicit examples ('bridge, cloud, nat, etc.') that distinguish it from sibling tools like list_lab_networks or list_labs. It directly answers what the tool does without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('that can be used to create networks in labs'), suggesting when this tool is relevant, but does not explicitly state when to use it versus alternatives like list_lab_networks or provide exclusions. It offers some guidance but lacks explicit comparisons or prerequisites.
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 the full burden of behavioral disclosure. It effectively communicates critical traits: the action is permanent ('permanently removes'), destructive ('All node data and configuration will be lost'), and irreversible ('This action cannot be undone'). This covers safety and consequences well, though it lacks details on permissions, errors, or side effects.
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 front-loaded with the core purpose in the first sentence, followed by critical warnings in subsequent sentences. Every sentence adds essential value—no fluff or repetition—making it highly efficient and well-structured for quick comprehension.
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 (destructive operation with 1 parameter but 0% schema coverage and no output schema), the description is partially complete. It covers behavioral aspects thoroughly but fails to address parameters or output, leaving gaps that could hinder correct invocation despite good safety warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters beyond what the input schema provides. With schema description coverage at 0% (parameters like 'arguments' are undocumented in schema), the description fails to compensate by explaining what 'arguments' contains (e.g., lab_path and node_id) or their semantics, leaving parameters entirely unclear.
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 ('Delete a node from a lab') with the resource ('node') and scope ('from a lab'), distinguishing it from siblings like delete_lab, wipe_node, or stop_node. It uses precise language that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 wipe_node (which may reset but not delete) or delete_lab (which removes an entire lab). It mentions the action is permanent but does not specify prerequisites, conditions, or comparisons to sibling tools, leaving the agent with insufficient context for selection.
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 the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the action is permanent ('permanently removes'), has irreversible consequences ('cannot be undone'), and causes collateral damage ('All connections to this network will be lost'). This provides essential context about the destructive nature of the 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 perfectly structured with three concise sentences that each add distinct value: stating the action, explaining consequences, and warning about irreversibility. There's zero redundancy or wasted words, and the most critical information (permanent removal) is front-loaded.
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 destructive tool with no annotations and no output schema, the description does well on behavioral transparency but fails to address parameter semantics. It adequately warns about the irreversible nature but leaves the agent without guidance on how to specify which network to delete, creating a significant gap in usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description provides no information about the required parameters (lab_path and network_id). While the description mentions 'a network from a lab,' it doesn't explain how to identify or specify these resources, leaving the agent with insufficient guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('permanently removes') and resource ('a network from the lab'), distinguishing it from sibling tools like delete_lab or delete_node. It uses precise language that goes beyond just restating the tool name.
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 delete_lab or wipe operations. It mentions the consequences ('All connections to this network will be lost') but doesn't specify prerequisites, dependencies, or comparative usage scenarios with sibling tools.
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 the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the action is permanent ('permanently deletes'), irreversible ('cannot be undone'), and affects associated resources ('all its associated resources'). However, it doesn't mention potential side effects like impact on running nodes or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded and concise: the first sentence states the core purpose, and the second adds critical behavioral context. Every sentence earns its place with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does well on behavioral transparency but leaves gaps: it doesn't explain the parameter, potential errors, or system state requirements. Given the high-stakes nature of deletion, more context would be beneficial, though the core risk is clearly communicated.
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 0%, so the description must compensate. It doesn't explain the 'lab_path' parameter at all—no format, examples, or how to obtain it. The description adds no parameter-specific information beyond what's implied by the tool name, leaving the single required parameter undocumented.
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 ('Delete') and resource ('a lab from EVE-NG'), distinguishing it from siblings like delete_lab_network or delete_node which target different resources. The verb+resource combination is precise and unambiguous.
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 wipe_all_nodes or delete_lab_network, nor does it mention prerequisites such as needing the lab to be stopped first. It only states what the tool does, not when it should be used.
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 full burden. It discloses key behavioral traits: 'gracefully shut down' (non-destructive) and 'states preserved' (data retention). However, it doesn't mention permissions needed, potential side effects, error conditions, or what 'gracefully' entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first states the core purpose, second adds important behavioral details. Zero wasted words, appropriately sized for a single-parameter tool. Front-loaded with the essential action in the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description provides adequate purpose and basic behavioral context but lacks parameter details, error handling information, and operational constraints. For a mutation tool affecting multiple nodes, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specified lab' which hints at the lab_path parameter, but provides no details about parameter format, constraints, or examples. The description adds minimal semantic value beyond what's implied by the tool name.
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 ('stop all nodes') and target resource ('in a lab'), with the first sentence providing a concise purpose statement. It distinguishes from sibling tools like 'stop_node' (single node) and 'wipe_all_nodes' (destructive wipe vs graceful shutdown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'in the specified lab' and contrasting with sibling tools through the 'all nodes' scope, but doesn't explicitly state when to use this vs alternatives like 'stop_node' for individual nodes or 'wipe_all_nodes' for destructive operations. No explicit when-not guidance is provided.
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 and does an excellent job disclosing critical behavioral traits: it's destructive ('deleting all user configuration'), specifies what gets destroyed ('startup-config, VLANs, and other settings'), and describes the outcome ('rebuild the node from the selected image'). It doesn't mention permissions or rate limits, but covers the essential destructive nature well.
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?
Perfectly structured with three sentences: purpose statement, destructive scope, and outcome. Every sentence earns its place with zero waste. The description is front-loaded with the core action and appropriately sized for the tool's complexity.
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 destructive tool with no annotations and no output schema, the description does well on behavioral transparency but completely fails on parameter documentation. It covers the 'what happens' adequately but leaves the agent guessing about 'what to provide'. The combination creates a significant gap in usability despite good behavioral disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single required parameter ('arguments') or its nested properties ('lab_path', 'node_id'). The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving the agent with no guidance on what inputs to provide.
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 ('wipe a node', 'reset to factory state') and distinguishes it from siblings like 'delete_node' (removal) and 'wipe_all_nodes' (bulk operation). It specifies the exact resource affected ('a specific node') with precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying what gets deleted ('all user configuration') and the outcome ('next start will rebuild'), but doesn't explicitly state when to use this vs alternatives like 'delete_node' or 'wipe_all_nodes'. It provides clear operational context but lacks explicit sibling differentiation.
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 the full burden of behavioral disclosure. It effectively describes the destructive nature ('deleting all user configuration'), scope ('all nodes'), and outcome ('rebuild all nodes from their selected images'). It doesn't cover aspects like permissions, rate limits, or error handling, but provides solid core behavioral information.
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 front-loaded with the core purpose in the first sentence, followed by specific details in the second. Both sentences earn their place by adding value—no wasted words or redundancy. The structure is clear and efficient.
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 (destructive operation with no annotations and no output schema), the description is moderately complete. It covers the action, scope, and outcome well but lacks details on parameters, error conditions, or what 'factory state' entails. For a high-stakes tool, more context would be beneficial.
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 0%, with one parameter ('lab_path') undocumented in the schema. The description doesn't mention parameters at all, failing to compensate for the schema gap. However, since there's only one parameter, the baseline is 4, but the lack of any parameter guidance in the description reduces it to 3.
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 ('wipe all nodes in a lab'), the resource ('nodes in a lab'), and distinguishes it from the sibling tool 'wipe_node' by specifying it affects 'all nodes' rather than individual nodes. The phrase 'reset to factory state' further clarifies the outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it deletes 'all user configuration' and rebuilds nodes 'from their selected images,' suggesting it's for resetting a lab. However, it doesn't explicitly state when to use this versus alternatives like 'delete_lab' or 'wipe_node,' nor does it mention prerequisites like lab existence or permissions.
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 the full burden of behavioral disclosure. It effectively describes the tool's behavior: closing the connection and cleaning up active sessions, which implies it is a destructive/mutation operation that ends ongoing interactions. However, it does not detail potential side effects like loss of unsaved data or error handling, leaving some behavioral aspects 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 front-loaded with the core action in the first sentence and adds necessary detail in the second. Both sentences earn their place by clarifying the purpose and behavioral impact, with zero wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple disconnect action with no parameters) and lack of annotations/output schema, the description is mostly complete. It explains what the tool does and its behavioral impact, but could improve by mentioning prerequisites (e.g., requires an active connection) or confirming it has no return values, though this is minor for a zero-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's action. A baseline of 4 is applied as it compensates well for the lack of parameters by explaining the tool's effect.
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 ('Disconnect from EVE-NG server') and resource ('EVE-NG server'), distinguishing it from sibling tools like 'connect_eveng_server' and 'test_connection'. The second sentence elaborates on what disconnection entails, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to close a connection and clean up sessions, but does not explicitly state when to use this tool versus alternatives (e.g., when to disconnect vs. keep connected, or prerequisites like needing an active connection first). It provides basic context but lacks explicit guidance on 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.

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:

[![eveng-mcp MCP server](https://glama.ai/mcp/servers/moimran/eveng-mcp/badges/card.svg)](https://glama.ai/mcp/servers/moimran/eveng-mcp)

Score Badge

Copy to your README.md:

[![eveng-mcp MCP server](https://glama.ai/mcp/servers/moimran/eveng-mcp/badges/score.svg)](https://glama.ai/mcp/servers/moimran/eveng-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/moimran/eveng-mcp'

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