Cisco NSO MCP Server

Server Quality Checklist

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

Latest release: v3.1.0
Disambiguation4/5
The tools are mostly distinct with clear purposes centered around device management and service retrieval in Cisco NSO. However, there is some potential overlap between 'get_device_config' and 'get_device_state', as both retrieve device-specific information, which could cause minor confusion without careful reading of descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as 'check_device_sync', 'get_device_config', and 'sync_from_device'. This predictability makes it easy for agents to understand and navigate the tool set without ambiguity.
Tool Count5/5
With 9 tools, the server is well-scoped for managing Cisco NSO devices and services. Each tool serves a specific function, such as checking sync status, retrieving configurations, or listing services, without unnecessary duplication or excessive complexity.
Completeness3/5
The tool set covers read operations well, including retrieving device configurations, states, and service types. However, it lacks write operations like creating, updating, or deleting devices or services, which are essential for full lifecycle management in a network automation context, creating notable gaps.
Average 3.1/5 across 9 of 9 tools scored. Lowest: 2.4/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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, suggesting a write operation, which aligns with 'sync' implying a change. However, the description doesn't add behavioral context beyond this, such as what gets synced, potential side effects, or performance considerations. No contradiction with annotations, but minimal value added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, but it's under-specified rather than concise. It wastes no words, yet the single sentence lacks necessary detail, making it efficient but incomplete.
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 'sync' (likely a write operation), 0% schema coverage, and no output schema details provided in context, the description is inadequate. It doesn't explain what the tool does, how to use parameters, or what to expect in return, leaving significant gaps for agent understanding.
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 input schema is generic with 'additionalProperties: true', providing no parameter details. The description only names 'device_name' as required but doesn't explain its format, constraints, or what other parameters might be needed, failing to compensate for the schema's lack of information.
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+resource, but it's vague about what 'sync' actually does (e.g., sync configuration, state, data). It doesn't distinguish from siblings like 'check_device_sync' or 'get_device_state', leaving ambiguity about its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives is provided. The description only mentions the required parameter without context about scenarios, prerequisites, or comparisons to sibling tools like 'check_device_sync' for monitoring or 'get_device_config' for reading data.
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 indicate readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it retrieves 'full configuration' and requires a 'device_name' parameter, which provides some context beyond annotations, but it lacks details on rate limits, authentication needs, or response format, limiting behavioral insight.
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, using only one sentence without unnecessary details. However, it could be slightly more structured by separating usage notes, but it remains efficient and to the point.
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 input, output schema exists), the description is minimally adequate. It states the purpose and required parameter, but with 0% schema coverage and no output details, it relies heavily on the output schema and annotations, leaving gaps in full understanding.
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 input schema is generic (an object with additionalProperties). The description only mentions that a 'device_name' parameter is required, but it does not specify the parameter's format, constraints, or how it maps to the schema, 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 action ('Retrieve') and resource ('full configuration for a specific device in Cisco NSO'), making the purpose evident. However, it does not explicitly differentiate this tool from its siblings (e.g., get_device_state, get_device_platform), which would be needed for 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 like get_device_state or sync_from_device. It only mentions a required parameter without context about appropriate scenarios or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating a safe read operation. The description adds that it 'requires a service_type parameter', which is useful context not covered by annotations. However, it doesn't disclose other behavioral traits like rate limits, authentication needs, or what 'available services' entails, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action, consisting of two sentences that convey the purpose and a key requirement. There's no unnecessary verbosity, though it could be slightly more informative 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 has annotations (readOnlyHint) and an output schema, the description doesn't need to cover safety or return values. However, with 1 parameter at 0% schema coverage and no usage guidelines, the description is minimally adequate but lacks depth for effective tool invocation in context.
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 details. The description mentions 'service_type' as a required parameter, adding some meaning, but it doesn't explain what 'service_type' is, its format, or how it affects retrieval. With 1 parameter and low coverage, this is insufficient compensation.
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 distinguish this tool from its sibling 'get_service_types', which appears to be a closely related operation, so it doesn't achieve full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_service_types' or other sibling tools. It only mentions a required parameter, which doesn't help the agent understand the appropriate context or exclusions 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?
The description adds that it 'Requires a device_name parameter' which provides context beyond the readOnlyHint annotation. However, it doesn't disclose what the sync status actually returns, potential error conditions, or how this differs from the 'sync_from_device' sibling tool. With annotations covering read-only safety, this adds minimal but useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's purpose and parameter requirement. There's zero wasted language, 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.
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 exists, the description covers basic purpose and parameter requirement. However, for a tool checking device sync status in a network management context, it should ideally explain what 'sync status' means, possible return values, or how this differs from related operations among the many sibling 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?
With 0% schema description coverage and 1 parameter, the description only mentions that a 'device_name' parameter is required. It doesn't specify the parameter's format, constraints, or what constitutes a valid device name. The schema shows a generic 'params' object with no structure, so the description adds minimal value beyond acknowledging the parameter exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as checking sync status for a specific device in Cisco NSO, which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'sync_from_device' or 'get_device_state', which might provide related device information.
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 multiple sibling tools available (like get_device_state, sync_from_device), there's no indication of when this specific sync status check is appropriate versus other device-related operations.
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 declare readOnlyHint=true, which the description aligns with by using 'retrieve' (a read operation). The description adds value by specifying the required parameter, but it doesn't disclose additional behavioral traits such as error handling, authentication needs, or rate limits. With annotations covering safety, this is adequate but not rich in context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and key requirement. It's front-loaded with the main action and avoids any unnecessary words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description doesn't need to explain return values. However, with 0% schema coverage for inputs and no annotations beyond readOnlyHint, the description is minimal—it covers the basic purpose but lacks details on parameters, usage context, or behavioral nuances, making it incomplete for optimal agent guidance.
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 input schema is generic with 'additionalProperties: true', providing no parameter details. The description compensates slightly by naming the 'device_name' parameter, but it doesn't explain its format, constraints, or meaning, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieve platform information') and resource ('specific device in Cisco NSO'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_device_state' or 'get_device_config', 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 mentions the required 'device_name' parameter but provides no guidance on when to use this tool versus alternatives like 'get_device_state' or 'check_device_sync'. There's no context about use cases, prerequisites, or exclusions, leaving the agent with minimal usage 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 this is a safe read operation. The description adds that it 'Requires a device_name parameter', which is useful context about authentication or input needs. However, it doesn't disclose behavioral traits like rate limits, error conditions, or what 'state' encompasses beyond what annotations cover.
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 two concise sentences with zero waste. It's front-loaded with the core purpose and efficiently adds the parameter requirement. Every sentence earns its place by providing essential information.
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, the description doesn't need to explain return values or safety. It covers the basic purpose and parameter need. However, with 0% schema coverage and nested objects, more parameter guidance would improve completeness for this read operation.
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 'device_name' as a required parameter, adding some semantics, but it doesn't explain the 'params' object structure or any nested properties. With 1 parameter and low coverage, this is insufficient compensation.
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 doesn't explicitly differentiate from sibling tools like 'get_device_config' or 'check_device_sync', which likely retrieve different aspects of device information.
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 but provides no guidance on when to use this tool versus alternatives like 'get_device_config' or 'check_device_sync'. There's no context about what 'state' means compared to 'config' or 'sync' status, leaving the agent without usage differentiation.
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 no behavioral context beyond this, such as rate limits, authentication needs, or what 'available' means in practice. No contradiction with annotations exists, but the description doesn't enhance the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it efficient and easy to parse for an AI agent.
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 the basic purpose adequately. However, it lacks usage guidelines and parameter insights, which are gaps considering the presence of sibling tools and a generic parameter. The description is minimal but not fully complete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter 'params' that accepts any object or null. The description provides no information about parameters, not even hinting at possible filters or options. However, since the parameter is optional and generic, the baseline score of 3 is appropriate as the schema handles the structure, but the description fails to add any semantic meaning.
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 'available device groups in Cisco NSO', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools 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. It doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone among similar-sounding siblings like get_device_config and get_device_state.
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 value by specifying the resource type (NED IDs) and context (Cisco NSO), but doesn't provide additional behavioral details like rate limits, authentication needs, or what 'available' entails beyond what annotations cover.
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 highly concise and well-structured for quick understanding.
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 (one optional parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It specifies the resource and context, but could improve by addressing usage relative to siblings or parameter semantics, though annotations and output schema reduce the burden.
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 one parameter with 0% description coverage, and the tool description mentions no parameters. Since schema_description_coverage is low (<50%), the description doesn't compensate by explaining the 'params' object's purpose or usage, leaving parameters undocumented. With 0 parameters effectively described, the baseline is adjusted to 3 due to minimal 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 action ('Retrieve') and the resource ('available Network Element Driver (NED) IDs in Cisco NSO'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_device_platform' or 'get_device_config', which might retrieve related but different device information.
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_platform' and 'get_device_config', there's no indication of the specific context for retrieving NED IDs, such as for device configuration or compatibility checks, leaving usage ambiguous.
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 no behavioral context beyond this, such as rate limits, authentication needs, or what 'available service types' entails. It doesn't contradict annotations, but offers minimal additional value given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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 the tool has annotations (readOnlyHint) and an output schema (which covers return values), the description is minimally adequate. However, it lacks context on usage relative to siblings and doesn't clarify what 'service types' are, leaving gaps in 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?
With 0% schema description coverage and one parameter ('params') that is loosely typed (any object or null), the description doesn't explain parameter usage. However, since there are zero required parameters and the schema allows null/default, the tool likely operates without inputs, making the lack of parameter details less critical. This justifies a baseline above minimum.
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 service types in Cisco NSO'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_services' or 'get_device_ned_ids', which might retrieve related but different data.
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_services' and 'get_device_ned_ids' that might retrieve similar or overlapping data, there's no indication of context, prerequisites, or exclusions to help the agent choose appropriately.
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/NSO-developer/cisco-nso-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/NSO-developer/cisco-nso-mcp-server)

Score Badge

Copy to your README.md:

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

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