A
license-
qualityA
maintenanceProvides AI coding agents with accurate knowledge of the Siemens NXOpen .NET API by performing hybrid retrieval over local documentation, eliminating hallucinated API calls.
Last updated
MIT
docs
by com.ntop
Server Details
Search and query nTop's knowledge base and engineering guides from AI applications.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A3.9/5.0
Tool DescriptionsA
Average 4.6/5 across 3 of 3 tools scored.
Server CoherenceC
Disambiguation5/5
Each tool serves a distinct purpose: querying the filesystem, searching the knowledge base, and submitting feedback. There is no overlap.
Naming Consistency2/5
Tool names mix long descriptive phrases ('query_docs_filesystem_n_top'), a shorter pattern ('search_n_top'), and a simple verb_noun ('submit_feedback'). Inconsistent conventions.
Tool Count2/5
Only 3 tools for a documentation server is too few. Many basic operations like listing pages or navigating structure are missing.
Completeness2/5
The tool surface lacks basic operations such as listing available pages, getting page metadata, or a structured way to browse. Agents may struggle to find and read documentation effectively.
Available Tools
3 toolsquery_docs_filesystem_n_topARead-onlyIdempotentInspect
Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at / that contains ONLY the nTop documentation pages and OpenAPI specs. This is NOT a shell on any real machine — nothing runs on the user's computer, the server host, or any network. The filesystem is a sandbox backed by documentation chunks.
This is how you read documentation pages: there is no separate "get page" tool. To read a page, pass its .mdx path (e.g. /quickstart.mdx, /api-reference/create-customer.mdx) to head or cat. To search the docs with exact keyword or regex matches, use rg. To understand the docs structure, use tree or ls.
Workflow: Start with the search tool for broad or conceptual queries like "how to authenticate" or "rate limiting". Use this tool when you need exact keyword/regex matching, structural exploration, or to read the full content of a specific page by path.
Supported commands: rg (ripgrep), grep, find, tree, ls, cat, head, tail, stat, wc, sort, uniq, cut, sed, awk, jq, plus basic text utilities. No writes, no network, no process control. Run --help on any command for usage.
Each call is STATELESS: the working directory always resets to / and no shell variables, aliases, or history carry over between calls. If you need to operate in a subdirectory, chain commands in one call with && or pass absolute paths (e.g., cd /api-reference && ls or ls /api-reference). Do NOT assume that cd in one call affects the next call.
Examples:
tree / -L 2— see the top-level directory layoutrg -il "rate limit" /— find all files mentioning "rate limit"rg -C 3 "apiKey" /api-reference/— show matches with 3 lines of context around each hithead -80 /quickstart.mdx— read the top 80 lines of a specific pagehead -80 /quickstart.mdx /installation.mdx /guides/first-deploy.mdx— read multiple pages in one callcat /api-reference/create-customer.mdx— read a full page when you need everythingcat /openapi/spec.json | jq '.paths | keys'— list OpenAPI endpoints
Output is truncated to 30KB per call. Prefer targeted rg -C or head -N over broad cat on large files. To read only the relevant sections of a large file, use rg -C 3 "pattern" /path/file.mdx. Batch multiple file reads into a single head or cat call whenever possible.
When referencing pages in your response to the user, convert filesystem paths to URL paths by removing the .mdx extension. For example, /quickstart.mdx becomes /quickstart and /api-reference/overview.mdx becomes /api-reference/overview.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | A shell command to run against the virtualized documentation filesystem (e.g., `rg -il "keyword" /`, `tree / -L 2`, `head -80 /path/file.mdx`). |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds crucial behavioral details: statelessness (working directory resets each call), output truncated to 30KB, no network/process control, sandbox nature. These go well beyond annotations.
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 comprehensive but well-structured: purpose, workflow, supported commands, statelessness, examples, output limits, URL conversion. Every sentence earns its place and critical info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (virtual filesystem, stateless behavior, output limits, URL conversion for responses), the description covers all usage aspects. No output schema, but the description explains what output to expect and how to handle truncation.
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?
Input schema has 100% coverage for the single 'command' parameter. The description adds significant value with usage examples, output truncation warning, and tips for efficient usage (e.g., prefer head over cat, batch reads). Baseline is 3 due to high schema coverage, but the extra guidance justifies a 4.
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 explicitly states it runs read-only shell-like queries against a virtualized documentation filesystem, and distinguishes from sibling tool 'search_n_top' which is for broader conceptual queries. This provides a specific verb-resource pair with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use this tool (exact keyword/regex matching, structural exploration, reading full pages) vs. when to start with the search tool. Also clarifies it is not a real shell, no writes, and workflow includes using search first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_n_topSearch documentationARead-onlyIdempotentInspect
Search across the nTop knowledge base to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about nTop, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages. If you need the full content of a specific page, use the query_docs_filesystem tool to head or cat the page path (append .mdx to the path returned from search — e.g. head -200 /api-reference/create-customer.mdx).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it returns contextual content with titles and direct links, and mentions append .mdx for file paths. No contradictions, but no additional behavioral traits like pagination or limits.
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?
Concise, front-loaded with purpose, then usage, then alternative tool and example. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and good annotations, the description is complete. It covers what it does, what it returns, and when to use the sibling 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?
Schema coverage is 100% (single parameter 'query' with description 'Search query'). Description adds context on what the query searches (knowledge base, code examples, etc.), adding value beyond the 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 it searches across the nTop knowledge base for relevant information, code examples, API references, and guides. It distinguishes itself from sibling tools like query_docs_filesystem_n_top and submit_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when needing to answer questions, find specific documentation, understand features, or locate implementation details. Provides a concrete alternative: use query_docs_filesystem_n_top for full page content, including a detailed example of how to construct the file path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit documentation feedbackAInspect
Report a problem with this documentation site so the docs team can fix it. Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example. This is for feedback about the documentation content itself — not for product support requests or feedback about this tool or assistant.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The documentation page path the feedback is about (e.g., the page you were reading, such as `/quickstart`). | |
| feedback | Yes | A clear description of the documentation issue or suggestion — what is incorrect, outdated, missing, or confusing. |
Tool Definition Quality
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, consistent with a write operation. The description adds that it is for reporting feedback, but does not disclose additional behavioral traits such as rate limits, authentication needs, or whether a confirmation is sent. With annotations present, the burden is lower, but the description adds minimal context beyond what is already clear.
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 consists of two concise sentences that immediately convey the tool's purpose. Every sentence is necessary, with no wasted words or redundant 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?
For a simple feedback tool with two required parameters and no output schema, the description provides sufficient context to understand when and how to use it. It could optionally mention what happens after submission (e.g., whether the user gets a confirmation), but this is not critical for a minimal viable definition.
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 coverage is 100% and both parameters have descriptions. The description does not add new information about parameters beyond what the schema provides. Therefore, it meets the baseline for parameter semantics but does not enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for reporting problems with the documentation site, using a specific verb ('Report') and resource ('documentation site'). It also distinguishes from siblings by explicitly stating it is not for product support or feedback about the tool/assistant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use criteria: when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example. It also states what not to use it for: product support requests or feedback about the tool or assistant, which effectively guides the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables natural language search of ANSA Python API documentation, allowing AI to find relevant functions, signatures, and code examples for writing ANSA scripts.Last updated110MIT
notifly-mcp-serverofficial
Alicense-qualityCmaintenanceEnables AI agents to search Notifly documentation and SDK code examples for seamless integration.Last updated191Inno Setup- AlicenseAqualityCmaintenanceEnables searching and retrieving Reflex documentation, including full-text search, code examples, error analysis, changelog, migration guides, API reference, component props, and recipes.Last updated143MIT