Cisco NSO MCP Server

Server Quality Checklist

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

Latest release: v3.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are well-organized around specific resources (devices, services) and actions (check, get, sync), making it easy for an agent to select the right one. For example, get_device_config retrieves configuration while get_device_state retrieves state, and they are clearly differentiated.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with all tools using snake_case. The naming is predictable, such as get_device_config, check_device_sync, and sync_from_device, which enhances readability and agent usability. There are no deviations or mixed conventions.
Tool Count5/5
With 9 tools, the count is well-scoped for managing Cisco NSO devices and services. Each tool earns its place by covering essential operations like configuration retrieval, status checks, and synchronization, without being overly sparse or bloated. This aligns well with the server's purpose of network device management.
Completeness4/5
The tool set provides strong coverage for device and service management in Cisco NSO, including retrieval, status checks, and synchronization. However, there are minor gaps, such as the lack of tools for modifying configurations or creating services, which agents might need to work around for full lifecycle management. Overall, it supports core workflows effectively.
Average 3.1/5 across 9 of 9 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, indicating a write operation, but the description doesn't add behavioral context beyond this. It fails to disclose what 'Sync' does (e.g., whether it triggers a configuration pull, updates device state, or has side effects like network disruption), rate limits, or authentication needs. With annotations covering only the read/write aspect, the description adds minimal value, not compensating for the lack of detailed behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's action and a key parameter. It's front-loaded with the main purpose, and there's no wasted text. However, it could be more structured by explicitly separating purpose from requirements, but overall, it's efficient and to the point.
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 implied by a write operation (readOnlyHint=false), 1 parameter with 0% schema coverage, nested objects, and an output schema, the description is incomplete. It doesn't explain what 'Sync' entails, the expected output, or how it differs from siblings. The presence of an output schema reduces the need to detail return values, but the description lacks sufficient context for safe and effective use, especially for a mutation 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%, with 1 parameter ('params') that is a nested object with no documented properties. The description mentions 'device_name' as a required parameter, adding some meaning, but it doesn't explain the structure or usage of 'params' beyond this. Since schema coverage is low, the description partially compensates but doesn't fully clarify parameter semantics, leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Sync from a specific device in Cisco NSO' which provides a basic verb ('Sync') and resource ('device'), but it's vague about what 'Sync' entails (e.g., synchronization of configuration, state, or data). It doesn't distinguish from siblings like 'check_device_sync' or 'get_device_state', leaving ambiguity in purpose. This is a tautology that largely restates the name/title without clarifying the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires a 'device_name' parameter', which implies a prerequisite but doesn't provide guidance on when to use this tool versus alternatives. No explicit when/when-not scenarios or comparisons to sibling tools (e.g., 'check_device_sync' for verification vs. 'sync_from_device' for execution) are included. This lack of context leaves usage unclear.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it 'Requires a device_name parameter', which provides some context about authentication or identification needs. However, it doesn't disclose behavioral traits like rate limits, error conditions, or what 'sync status' specifically entails beyond what annotations provide.
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 each serve a purpose - stating the tool's function and noting the required parameter. It's front-loaded with the core purpose. There's no unnecessary verbosity, though it could potentially benefit from slightly more detail given the complexity of device synchronization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), the description doesn't need to explain return values. However, for a device synchronization tool with 0% schema description coverage and no behavioral annotations beyond readOnlyHint, the description provides only basic context. It covers the purpose and parameter requirement but lacks details about what 'sync status' means operationally or how this differs from related tools.
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%, meaning the input schema provides no documentation for the single parameter. The description mentions 'Requires a device_name parameter', which adds basic semantic meaning about what the parameter represents. However, this is minimal compensation for the complete lack of schema documentation - it doesn't specify format, constraints, or examples for the device_name.
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 ('Check the sync status') and resource ('for a specific device in Cisco NSO'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'sync_from_device' or 'get_device_state', which might have overlapping functionality in a device management context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'sync_from_device' or 'get_device_state'. It mentions the required parameter but offers no context about appropriate use cases, prerequisites, or exclusions. This leaves the agent with minimal direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating this is a safe read operation. The description adds minimal context by specifying it retrieves 'full configuration' and requires a device name, but does not disclose additional behavioral traits such as rate limits, authentication needs, or what 'full configuration' entails. With annotations covering safety, this earns a baseline score for adding some value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and requirement. It avoids unnecessary words, but could be slightly more structured by explicitly naming the tool's scope or limitations, though it earns high marks for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (readOnlyHint) and an output schema (per context signals), the description does not need to explain return values or safety. However, with 1 parameter and 0% schema coverage, the description only partially documents parameters and lacks usage guidelines. It is minimally adequate but has clear gaps in context for a configuration retrieval 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 schema provides no parameter documentation. The description mentions a 'device_name' parameter, which adds meaning for one parameter, but there is 1 parameter total (based on context signals), and it doesn't explain the structure or usage of 'params' as an object with additional properties. This partially compensates but leaves gaps, scoring below the baseline.
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 'Retrieve' and resource 'full configuration for a specific device in Cisco NSO', making the purpose unambiguous. However, it does not explicitly differentiate this tool from sibling tools like 'get_device_state' or 'get_device_platform', which likely retrieve different aspects of device information, so it doesn't reach the highest 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 mentions that it 'Requires a 'device_name' parameter', which is a basic prerequisite, but provides no guidance on when to use this tool versus alternatives like 'get_device_state' or 'sync_from_device'. There is no explicit when/when-not usage context or named alternatives, leaving the agent with minimal direction.
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?
Annotations provide readOnlyHint=true, indicating a safe read operation, which the description doesn't contradict. The description adds that it 'requires a device_name parameter', which is useful context beyond annotations, but it doesn't disclose other behavioral traits like rate limits, authentication needs, or what specific platform information is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the purpose and key requirement. It's front-loaded with the main action and resource, with no wasted words, though it could be slightly more detailed without losing conciseness.
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 has annotations (readOnlyHint) and an output schema, the description covers basic purpose and parameter requirement. However, with 0% schema description coverage and no details on output or behavioral context, it's minimally adequate but leaves gaps in understanding how to use the tool effectively.
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 only mentions that a 'device_name' parameter is required without explaining its format, constraints, or how it relates to the nested 'params' object in the schema. This adds minimal value beyond the schema's structure, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'platform information for a specific device in Cisco NSO', making the purpose understandable. However, it doesn't explicitly differentiate from siblings like get_device_config or get_device_state, which also retrieve device-specific information but different aspects.
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 mentions the required 'device_name' parameter, which provides some context for usage, but it doesn't specify when to use this tool versus alternatives like get_device_config or get_device_state. No guidance on prerequisites, exclusions, or comparative use cases is provided.
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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds minimal behavioral context by stating it 'Requires a 'device_name' parameter,' which implies a prerequisite but does not elaborate on permissions, rate limits, or response format. With annotations covering the safety profile, the description adds some value but lacks rich behavioral details.
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, consisting of two sentences that directly state the purpose and a key requirement. There is no unnecessary information, making it efficient. However, it could be slightly more structured by explicitly separating purpose from usage notes.
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 (1 parameter, nested objects in schema) and the presence of an output schema, the description is minimally adequate. It covers the basic purpose but lacks details on parameter usage, behavioral traits beyond annotations, and guidance relative to siblings. The output schema reduces the need to explain return values, but overall completeness is limited.
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%, meaning parameters are undocumented in the schema. The description only mentions the 'device_name' parameter without explaining its format, constraints, or how it relates to the 'params' object in the schema. This fails to compensate for the schema's lack of documentation, leaving key parameter semantics unclear.
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 ('Retrieve') and resource ('state for a specific device in Cisco NSO'), making the purpose understandable. However, it does not explicitly differentiate this tool from its siblings like 'get_device_config' or 'check_device_sync', which might retrieve related but different information. This omission 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. It mentions the required parameter but does not specify scenarios, prerequisites, or comparisons to sibling tools such as 'get_device_config' for configuration data or 'check_device_sync' for synchronization status. This lack of contextual direction leaves the agent without usage cues.
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?
Annotations provide readOnlyHint=true, indicating it's a safe read operation. The description adds that it retrieves services and requires a parameter, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or what 'available services' entails (e.g., active, configured). With annotations covering safety, the description adds minimal context, warranting a baseline score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and requirement. It avoids unnecessary words, though it could be slightly more structured by separating purpose from parameter details for clarity.
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 has annotations (readOnlyHint) and an output schema (per context signals), the description covers the basic purpose and parameter need adequately. However, with 0% schema coverage and no details on output or behavioral nuances, it's not fully complete but meets minimal expectations with structured support.
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 one required parameter documented only as 'params' with additionalProperties. The description specifies 'service_type' as a required parameter, adding meaning beyond the generic schema. However, it doesn't explain the parameter's format, constraints, or how it filters services, leaving significant gaps given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'available services in Cisco NSO', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_service_types', which might retrieve service type metadata rather than services themselves, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it 'Requires a 'service_type' parameter', which provides a basic prerequisite but no guidance on when to use this tool versus alternatives like 'get_service_types' or other sibling tools. There's no explicit when/when-not or alternative tool recommendations.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond that—no information about permissions, rate limits, or what 'available' means (e.g., filtered by user access). With annotations covering safety, a 3 is appropriate as the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (readOnlyHint) and an output schema, the description doesn't need to cover safety or return values. However, for a tool with 1 undocumented parameter and no usage guidance among siblings, the description is minimally adequate but leaves gaps in parameter meaning and contextual application.
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%, and the description provides no parameter information. The schema shows one optional parameter 'params' that can be an object or null, but its purpose is undocumented. Baseline 3 applies as the schema exists, but the description fails to compensate for the coverage 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 ('Retrieve') and resource ('available device groups in Cisco NSO'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'get_device_config' or 'get_device_state', which also retrieve device-related information but focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_device_config' and 'get_device_state' that retrieve different device data, there's no indication of when device groups are needed versus other device information, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which the description aligns with by using 'Retrieve' (a read operation). The description adds context about retrieving 'available' NED IDs in Cisco NSO, which hints at scope but doesn't detail behavioral traits like rate limits, auth needs, or output format. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary details. It's front-loaded and wastes no words, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, read-only, with an output schema), the description is reasonably complete. It specifies the resource and context (Cisco NSO), and the output schema will handle return values. However, it lacks usage guidelines, which slightly reduces completeness for agent decision-making.
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 with 0% description coverage and no enums, but the parameter is optional (required: 0) and defaults to null. The description doesn't mention parameters, which is acceptable here since the tool likely requires no inputs for its basic function. This compensates for the low schema coverage by implying simplicity.
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 ('Retrieve') and resource ('available Network Element Driver (NED) IDs'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_device_platform' or 'get_device_state', which might also retrieve device-related information, so it doesn't reach the highest 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, context, or exclusions, leaving the agent to infer usage based on the name alone. This is a significant gap 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which the description aligns with by using 'Retrieve' (implying a read operation). The description adds minimal context beyond annotations—it specifies the domain ('Cisco NSO') but doesn't detail behavioral traits like rate limits, authentication needs, or response format, resulting in an adequate but not comprehensive score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse, earning a perfect score for conciseness.
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 low complexity (1 optional parameter, read-only operation) and the presence of an output schema (which handles return values), the description is reasonably complete. It states what the tool does but lacks usage guidelines and deeper behavioral context, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 1 parameter (optional 'params'), the description doesn't explain parameters at all. However, since there's only one optional parameter and an output schema exists, the baseline is high. The description focuses on the tool's purpose without parameter details, which is acceptable given the low parameter burden.
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 ('Retrieve') and resource ('available service types in Cisco NSO'), making the purpose unambiguous. However, it doesn't distinguish this tool from its siblings (like 'get_services'), which are also retrieval operations in the same domain, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as how it differs from 'get_services' or when to prefer one over the other, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![cisco-nso-mcp-server MCP server](https://glama.ai/mcp/servers/dbono711/cisco-nso-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/dbono711/cisco-nso-mcp-server)

Score Badge

Copy to your README.md:

[![cisco-nso-mcp-server MCP server](https://glama.ai/mcp/servers/dbono711/cisco-nso-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/dbono711/cisco-nso-mcp-server)

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/dbono711/cisco-nso-mcp-server'

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