A
licenseNot graded
qualityC
maintenanceEnables searching official ANSYS SpaceClaim API documentation and generating SCDM Python code candidates from natural language modeling intents.
3
MIT
docs
by com.ntop
Server Details
Search and query nTop's knowledge base and engineering guides from AI applications.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 47 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.2/5.0
Scored across 3 tools
Disambiguation4/5
The three tools have distinct purposes: querying the docs filesystem, searching the knowledge base, and submitting feedback. There is minor overlap between query_docs_filesystem_n_top and search_n_top since both can locate documentation, but the descriptions clearly differentiate search (broad/conceptual) from filesystem query (exact/regex/reading).
Naming Consistency3/5
The names are readable and mostly descriptive, but they mix conventions: query_docs_filesystem_n_top is verbose with an embedded product name, search_n_top follows a different pattern, and submit_feedback is a clean verb_noun. The inconsistency is noticeable but not chaotic.
Tool Count4/5
Three tools is on the low end but appropriate for a documentation server: one for reading/searching the filesystem, one for semantic search, and one for feedback. The scope is narrow enough that each tool earns its place, though a dedicated 'get page' tool is intentionally folded into the filesystem query tool.
Completeness4/5
The server covers the core documentation workflow: discover structure, search content, read pages, and report issues. Minor gaps exist (e.g., no tool for listing recently updated docs or browsing by metadata), but the combined filesystem query and search tools cover most user needs without dead ends.
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. 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 to head or cat — a page at the URL path /some/page lives at /some/page.mdx. To search the docs with exact keyword or regex matches, use rg. To understand the docs structure, use tree or ls.
Paths are specific to this site — never guess them. Discover real paths with tree / -L 2, ls /, or the search tool before reading. If a path does not exist, that only means the guess was wrong; it does NOT mean the topic is undocumented — use rg -il "keyword" / to find where it is covered.
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 /some-directory && ls or ls /some-directory). Do NOT assume that cd in one call affects the next call.
Examples (replace the placeholder paths with real ones from tree or search):
tree / -L 2— see the top-level directory layoutrg -il "rate limit" /— find all files mentioning "rate limit"rg -C 3 "apiKey" /some-directory/— show matches with 3 lines of context around each hithead -80 /some/page.mdx— read the top 80 lines of a specific pagehead -80 /page-one.mdx /page-two.mdx /section/page-three.mdx— read multiple pages in one callcat /some/page.mdx— read a full page when you need everything
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, /some/page.mdx becomes /some/page.
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`). |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it is a sandbox, not a real shell; calls are stateless; output is truncated to 30KB; and there are no writes, network access, or process control. This fully discloses operational behavior and does not contradict the readOnly/idempotent annotations.
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 long but well organized, with the critical sandbox caveat front-loaded and clear workflow/examples sections. Some redundancy exists around statelessness and cd behavior, but nearly every detail earns its place given the complexity of a shell-like tool.
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?
The description is complete for an execution-oriented tool with no output schema: it covers command support, stateless behavior, output truncation, path discovery, page URL conversion, and when to prefer the sibling search tool. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the single command parameter already has 100% schema coverage, the description significantly enriches it with supported command lists, chaining guidance, absolute-path examples, and path-to-URL conversion rules. This goes well beyond the schema's minimal parameter description.
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 states a specific verb and resource: run a read-only shell-like query against a virtualized, in-memory filesystem containing only nTop documentation pages. It also clearly positions this tool as the way to read documentation pages, distinguishing it from the search sibling.
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 explicitly explains when to use this tool versus search_n_top: use search for broad or conceptual queries, and use this tool for exact keyword/regex matching, structural exploration, or reading full page content. It even notes there is no separate 'get page' tool, removing ambiguity.
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. a result at /some/page is read with head -200 /some/page.mdx).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return format (contextual content with titles and direct links) and the .mdx follow-up convention, which helps the agent understand what happens after the call. No contradiction with annotations.
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 longer than average but each sentence earns its place: purpose, when-to-use, return format, and sibling routing. It is front-loaded with the primary purpose and only slightly verbose in the follow-up example.
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?
With a single well-documented parameter, safety annotations present, and no output schema, the description explains the return format and how to consume results via the sibling tool. Minor gaps (result limits, query phrasing guidance) keep it from a 5, but nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'query' parameter. The description adds little parameter-specific detail beyond implying a natural-language search; the baseline of 3 is appropriate since the schema carries the weight.
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?
States a specific verb ('search') and a concrete resource (the nTop knowledge base), and enumerates the content types it retrieves (code examples, API references, guides). It implicitly distinguishes itself from query_docs_filesystem_n_top by framing itself as the search step while the sibling is the full-content reader.
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 the tool ('when you need to answer questions about nTop, find specific documentation, understand how features work, or locate implementation details') and names the alternative with a concrete condition: use query_docs_filesystem to retrieve full page content via head/cat. This routing is precise and actionable.
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 URL path of the documentation page the feedback is about (the page you were reading, without the `.mdx` extension). | |
| feedback | Yes | A clear description of the documentation issue or suggestion — what is incorrect, outdated, missing, or confusing. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false, idempotentHint=false), and the description adds meaningful context: feedback is routed to the docs team and is scoped to documentation content. It stops short of describing what happens after submission (e.g., whether a confirmation is returned, whether it creates an issue), but it does not contradict the annotations and provides useful behavioral framing.
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?
Three sentences, all informative. The first sentence states the purpose, the second gives concrete usage criteria, and the third excludes non-documentation feedback. No filler or redundancy; the most important information is front-loaded.
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 two-parameter tool with no output schema, the description and schema together cover the essential information: what to submit, which page, what kind of feedback, and when to use it. The only minor gap is the lack of detail about the post-submission result or confirmation behavior, which is not critical but would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions already explain 'path' (URL path without .mdx extension) and 'feedback' (clear description of the issue). The tool description reinforces the kind of feedback expected but adds no technical semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Report a problem with this documentation site so the docs team can fix it.' It identifies the specific resource (documentation site) and the action (reporting a problem), and it distinguishes itself from the sibling query/search tools by being feedback-oriented. It also explicitly carves out what 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 gives explicit when-to-use guidance: 'Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example.' It also provides a clear when-not-to-use boundary: 'not for product support requests or feedback about this tool or assistant.' This is strong, actionable usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
submit_feedback1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The documentation page path the feedback is about (e.g., the page you were reading, such as `/quickstart`)."New value: +"The URL path of the documentation page the feedback is about (the page you were reading, without the `.mdx` extension)."
3 tool updates
- Changed
query_docs_filesystem_n_top1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
search_n_top1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
submit_feedback1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
Related MCP Connectors
Search the Cerebrium docs: deployment, cerebrium.toml, hardware, endpoints. Also sends feedback.
Search the SiteGPT documentation: setup, features, API reference, troubleshooting.
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Semantic search over Handsontable and HyperFormula docs, API reference, release notes, and issues.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables intent-based semantic search over external design system documentation, allowing MCP-compatible AI assistants to retrieve relevant design tokens, component architectures, and code patterns via a single tool.-
- AlicenseNot gradedqualityAmaintenanceProvides AI coding agents with accurate knowledge of the Siemens NXOpen .NET API by performing hybrid retrieval over local documentation, eliminating hallucinated API calls.32 PyPI12MIT
- AlicenseAqualityBmaintenanceEnables coding agents to query a team knowledge base via MCP, performing semantic search and asking questions that return grounded, citation-backed answers from ingested documents.4MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.