ntopology-mcp

by sohumsuthar

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: adding literals vs. setting their values, reading the graph vs. inspecting the notebook, validating vs. running, searching blocks vs. finding examples. No two tools appear to do the same thing, so an agent can reliably pick the right one.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun snake_case pattern (add_literal, search_blocks, set_output). Two exceptions break the pattern: 'mesh_stats' is a noun_noun compound and 'environment' is a bare noun, which slightly reduces predictability but does not cause real confusion.
Tool Count5/5
14 tools is well within the sweet spot for a domain-specific server. Each tool addresses a distinct step in the notebook lifecycle—inspection, editing, validation, execution, and analysis—earning its place without bloat or obvious omission.
Completeness4/5
The tool surface covers the core workflow: read/inspect/validate, add and modify blocks/literals, rewire inputs, set outputs, run, and check results. Minor gaps exist (e.g., no explicit block deletion, no direct 'save notebook' tool), but existing tools like prune_graph and set_input can work around these without agent failure.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 26, 2026
- 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?
With no annotations provided, the description alone must disclose behavioral traits. 'Writes in place unless output is given' is a useful but minimal hint; it does not explain what the output parameter does, whether the operation is destructive or reversible, whether special permissions are required, or what the return value is. For a mutation tool, this is a significant gap.
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 concise, using two sentences with no filler. The primary action and the key behavioral nuance ('writes in place unless output is given') are front-loaded, and every word contributes to the overall meaning.
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 that this is a mutation tool with no annotations, no output schema, and a sparse input schema, the description is under-specified. It fails to explain the output parameter, the exact effect of writing in place, any preconditions, or the response format. An agent would likely need additional information to invoke this tool confidently and correctly.
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 only 25% (only the 'value' parameter has a description). The description adds context for 'value' ('Replacement value, in the same shape the notebook already stores') but provides no semantic guidance for the 'output' parameter, which the description mentions only vaguely ('unless output is given') without clarifying its purpose or format. It also does not explain blockId or notebook beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (a literal block), and enumerates the allowed value types (scalar, file path, vector, point, boolean or enum). It distinguishes from add_literal by use of 'set' (implying modification) and from set_input/set_output by focus on literal blocks, though it does not explicitly name alternatives.
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 does not provide any explicit guidance on when to use this tool versus its siblings like add_literal (for creation) or set_input/set_output. The phrase 'Writes in place' hints that it works on an existing block, but there are no exclusions or alternative recommendations, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Add a literal block holding a constant' and dives into value formatting. It does not disclose side effects (does it modify the notebook in place?), return behavior, permissions, or any constraints on the operation. As a write operation with no annotation coverage, this is a significant gap.
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 sentence plus examples, which is efficient. It front-loads the action and then provides the critical value-shape details. The structure is clean, though the value examples could arguably be moved to the parameter schema. It earns its place for conveying essential information without fluff.
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 6 parameters, 4 required, no output schema, and no annotations, the description is incomplete. It only explains the value parameter's shape; notebook, name, output, and blockId are left entirely to the agent's inference. There is no mention of return values or behavior on failure. The tool likely operates in a complex notebook context, and the description does not equip an agent to call it correctly for all required inputs.
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 only 17% (only the type property has a description). The description compensates by explaining the exact shape of the 'value' parameter for common literal types (length scalar, point, enum), which is valuable. However, other parameters (notebook, name, output, blockId) receive no extra meaning beyond the schema. The description adds value where it matters most but doesn't fully 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 states a clear action and resource: 'Add a literal block holding a constant.' It's distinct from generic add_block and set_literal_value, though it doesn't explicitly name siblings. The purpose is understandable at a glance, but it could be sharper about what makes this different from adding other block types.
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?
There is no guidance on when to use this tool versus alternatives like set_literal_value or add_block. No conditions, prerequisites, or exclusions are given. An agent has to infer the intended use case from the name and sibling context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'reports' information, implying a read-only operation, but does not explicitly confirm no side effects, describe return format, or mention any environmental prerequisites.
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?
A single, focused sentence that directly states what the tool does with no fluff. It is well-structured and easily scannable.
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 zero-parameter, no-output-schema tool, the description covers what the agent needs to know to call it and interpret its purpose. It could explain 'block signatures' further but that is likely domain-specific context not required for invocation.
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 tool has zero parameters and schema coverage is 100% (vacuously). Per the baseline for 0 parameters, a score of 4 is appropriate; no additional parameter information is needed or possible.
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 uses a clear verb ('Report') and specifies the resource (ntopcl, nTop installation, block signatures). It is easily distinguished from siblings like add_block or search_blocks, though it does not explicitly name alternatives.
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 versus alternatives. It does not state prerequisites, typical call timing, or why one might invoke it before other 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?
No annotations are provided, so the description carries the full burden. It discloses the licensing requirement and states that diagnostics (errors, warnings, timings) are returned. However, it does not mention that the tool can modify the notebook file when 'save' is true (a side effect), nor does it describe the execution environment or non-interactivity beyond 'headlessly'. Some behavioral context is given, but significant gaps remain.
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?
A single, front-loaded sentence that efficiently states the purpose, method, and return values. There is no redundancy or filler; every phrase earns its place.
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?
This is a complex execution tool with 5 parameters, no output schema, and no annotations. The description is sparse: it names the return values and the licence but omits when-to-use guidance, side-effect warnings, and parameter context (especially for the required 'notebook'). An agent would need additional inference to select and call it correctly, making it incomplete.
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 60% (save, inputsJson, outputJson have descriptions; notebook and timeoutMs do not). The tool description adds no parameter details, failing to compensate for the undocumented required parameter 'notebook' or 'timeoutMs'. It only references the licence, not how parameters should be used, so it adds no 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 states a specific verb ('Execute'), a concrete resource ('notebook'), a method ('headlessly through nTop Automate (ntopcl)'), and explicitly names the return artifacts ('errors, warnings and per-block timings'). This clearly distinguishes it from sibling tools like inspect_notebook or validate_graph, which are about inspection/validation rather than execution.
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?
There is no guidance on when to use this tool versus the sibling tools. It does not mention alternatives, exclusions, or prerequisites beyond the licence note. The description implies a use case (execute a notebook) but does not help an agent decide between this and related tools like validate_graph or inspect_notebook.
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?
No annotations are present, so the description carries the full burden. It discloses input behavior (source block ids in order, 0 for unconnected, list parameter requirement) but does not mention side effects, permissions, or return values. It adds some behavioral detail but is not comprehensive.
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 concise sentences, front-loaded with the core action. Each sentence adds essential information about signature, input structure, and list handling. No redundancy or wasted words.
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?
With 7 parameters, no annotations, and no output schema, the description covers the two most complex parameters (func and inputs) but omits guidance for the other required parameters (name, output, notebook). An agent may struggle to fill all fields correctly, especially since the schema descriptions are sparse.
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 only 43%, so the description must compensate. It clarifies the func parameter (typed signature from search_blocks) and the inputs array (order, 0 for optional, list handling). However, it leaves name, output, and notebook unexplained. It partially fills the gap but not fully.
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 states the action 'Add a computed block' with a clear verb and resource. It implies differentiation from add_literal through the word 'computed' and the specifics about typed signatures and inputs, but does not explicitly name the sibling tool. Overall it is clear about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to get the signature from search_blocks, implying a prerequisite step. It explains how to construct inputs (order, 0 for unconnected, list types). However, it does not explicitly state when to prefer this over add_literal or other alternatives, so the usage context is partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the disconnect convention (sourceId=0), which is a useful behavioral trait, but it omits side effects (e.g., what happens to the previous connection), error cases, or irreversibility. It gives minimal behavior beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource. It includes the essential disconnect note without any redundant phrasing. There is zero waste, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no output schema, and no annotations, the description is too thin. It does not explain all parameter meanings, describe the return value or side effects, or cover edge cases like invalid slot indices. An agent lacks enough context to call it confidently in a variety of situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of slot (input slot) and sourceId (source block) indirectly, but it does not clarify notebook, blockId, or the 'output' parameter at all. The description is insufficient to map all five parameters to their roles.
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 ('Rewire'), resource ('one input slot of a block'), and the target ('a different source block'). The addition of 'Use 0 to disconnect' clarifies a key behavior. It clearly distinguishes from the sibling set_output by focusing on input slots, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by its action phrase, but it does not explicitly state when to use this tool over alternatives (e.g., set_output) or provide any warnings or exclusions. The '0 to disconnect' note is a usage hint, but there is no overall guidance on choosing this tool in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states what is measured but does not mention side effects (the name and 'Measure' imply read-only, yet that is not explicit), does not describe error behavior, performance characteristics, or the exact return format. For a tool with zero annotation coverage, this is a noticeable gap.
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 sentences, front-loaded with the core purpose and followed by a practical usage hint. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the scope of measurements and the primary use case. However, it omits obvious but potentially relevant details such as expected file parameter format (STL binary or ASCII), whether the tool returns a single object or a list of metrics, and any caveats about large meshes. These gaps keep it from being fully self-sufficient.
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 50%: only 'listComponents' has a description, while the required 'path' parameter is undocumented in the schema. The tool description does not compensate by explaining what 'path' should refer to (e.g., a filesystem path to an STL file). Since the description adds no parameter guidance, agents relying on it may not know how to fill the required field.
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 ('Measure') and resource ('an STL') followed by the exact set of measurements: volume, surface area, bounding box, watertightness, and connected components. This clearly distinguishes the tool from all sibling tools, which relate to notebooks, graphs, and literals, not mesh geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'Use this to check what a notebook actually produced.' That tells an agent when to reach for this tool. It does not explicitly name alternatives or state when not to use it, but given the sibling set, the context is unambiguous enough to infer there are no competing mesh tools.
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?
No annotations are provided, so the description carries the full burden. It discloses the core destructive behavior ('drop every block no longer reachable') and the modification of the root block, but does not state whether the operation mutates the input notebook or returns a new one, nor any reversibility or validation details. This is a partial disclosure, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The core action is front-loaded, and the usage context is appended efficiently. It is a model of conciseness for a tool description.
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 that this is a mutating tool with no annotations and no output schema, the description is incomplete. It does not specify the return value, whether the notebook object is modified in place, or what happens to dropped blocks (deleted vs. detached). The ambiguous 'output' parameter is also unaddressed. For an agent to sequence this correctly with the notebook object, it needs more detail.
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 only 33% (only rootInputs is described). The description mentions 'given outputs' and 'root block' but does not clarify the meaning of the output parameter (a string) or the notebook parameter. It fails to compensate for the missing schema descriptions, leaving the agent to guess the output's role. Minimal added value, so a 2.
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 action ('point the root block at the given outputs and drop every block no longer reachable') and a clear resource (the notebook graph). It also implies the goal ('cut a large notebook down to one chain'), which differentiates it from siblings like run_notebook and inspect_notebook. The verb+resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this 'before running it', giving clear context for when to invoke it. It implies a pre-processing step relative to run_notebook, but does not explicitly name alternatives or exclusion criteria. Since it provides clear usage timing, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It states that the tool is a search (implying read-only, non-destructive), and that it returns 'working example notebooks and HTML reference pages.' However, it does not disclose potential side effects, authentication requirements, rate limits, or the output format. For a simple search tool this is acceptable, but the lack of any protection annotation means the description should be more explicit about its harmless nature.
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 sentences with zero filler. The primary purpose is front-loaded, and the usage guidance is placed immediately after. Every sentence adds value, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with two parameters, the description is mostly complete: it explains what is searched and when to use it. However, the undocumented 'documentationRoot' parameter is a clear gap, and there is no mention of the return value structure (though no output schema exists to lean on). This prevents full completeness.
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 coverage is only 50% (the 'query' parameter is described, but 'documentationRoot' is not). The description adds no additional meaning to the parameters beyond what the schema provides. It does not explain what documentationRoot does, nor does it clarify how query should be formatted beyond the schema's example. Given the low coverage, the description fails to compensate for the undocumented parameter.
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: searching nTop's shipped documentation (example notebooks and HTML reference pages) for a given block. It uses a specific verb ('search') and a distinct resource, and implicitly differentiates from siblings like search_blocks (which likely searches the block catalog) and inspect_notebook (which examines a specific notebook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: 'Consult this BEFORE reverse-engineering a block's wiring.' It explains the advantage (nTop ships 100+ example .ntop files with correct inputs and property paths), which helps the agent decide between this and inspection-based tools. However, it does not name specific alternative tools or state when not to use it, so it stops short of a full 5.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but the description does not explicitly state that it does not modify the notebook, require specific permissions, or explain pagination/limit behavior. Since the limit parameter hints at paging but is not elaborated, the description leaves some behavioral ambiguity.
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. The first establishes the primary purpose with a clear verb and resource, and the second offers a practical usage tip. There is no fluff or redundant phrasing, and the most important information is front-loaded. It scores high for efficiency and structure.
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 read tool with three simple parameters and no output schema, the description covers the core purpose and filter usage. The required notebook parameter is in the schema, so that is covered. Missing explicit output format or a read-only guarantee, but given the simplicity and schema coverage, it is largely adequate. A brief mention of return structure or side-effect-free behavior 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 coverage is 67%: limit and filter have descriptions, but notebook does not. The tool description reiterates the filter's purpose ('narrow by block name or signature') but adds no new parameter-specific meaning. It does contextualize what signatures are (typed signatures) but that is not tied to the notebook parameter. Given moderate schema coverage, the description adds minimal value beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the target (blocks in a notebook), and the specific data included (typed signatures, wiring, literal values). This is specific and distinguishes it from generic operations, though it does not explicitly name sibling tools. It is not a tautology and gives an agent a precise understanding of what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'Use filter to narrow by block name or signature,' which addresses the filter parameter but provides no guidance on when to choose this tool over alternatives like search_blocks or inspect_notebook. There are no exclusions, prerequisites, or cross-references to related tools. The context implies a read operation but does not help an agent decide between similar capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what information the tool provides (version, sections, counts, root evaluation), but it does not explicitly state that the operation is read-only or non-destructive, nor does it mention return format. 'Summarise' implies no mutation, but it's not explicit, so the transparency is adequate but not thorough.
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, front-loaded sentence that specifies the action first and then lists the key outputs. Every word contributes to the meaning with no redundancy or filler.
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 tool with one parameter, the description covers the purpose and the expected summary contents. There is no output schema, but the description lists what the summary includes, so an agent knows what to expect. It does not discuss error cases or required file existence, but these are minor gaps given the tool's simplicity.
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% (the only parameter 'notebook' is described as 'Path to the .ntop file'). The description mentions the notebook but does not add any semantic value beyond the schema, so the baseline 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 a specific verb ('Summarise') and resource ('.ntop notebook'), and enumerates exactly what the summary includes (version, sections, counts, root block evaluation). It is distinct from siblings like run_notebook (execution) and read_graph (graph reading), so an agent can tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a high-level summary of a notebook is needed. It does not explicitly name alternatives or exclusions (e.g., 'use X instead when...'), but the context is clear and no misleading guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns exact typed signatures, orders results newest-first, and warns about retired revisions and unlicensed-toolkit-like rejection. It does not mention whether the operation is read-only, side effects, or error handling, but for a search tool the disclosed behavior is reasonably transparent.
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 sentences with no redundancy. The core purpose and output are front-loaded, and the warning about retired revisions is delivered concisely as an important caveat. Every sentence earns its place.
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 simplicity (3 params, no output schema, no annotations), the description covers purpose, ordering, and a key pitfall. However, it omits details on result format/limit behavior and does not clarify how the 'limit' parameter affects results. For a search tool this is adequate but not fully complete, especially given the low schema coverage.
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 only 33% (only installRoot has a description). The description does not explain the 'query' or 'limit' parameters; while 'search the block signatures' implies 'query' is the search term, 'limit' is left entirely unexplained. Since the schema is sparse, the description fails to compensate, offering only marginal clarification for the primary parameter.
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 searches for block signatures in installed nTop binaries and returns the exact typed signature strings that add_block needs. This is a specific verb and resource, and it distinguishes itself from the sibling add_block by explaining it provides the signatures that add_block consumes. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the signatures are needed by add_block, and it provides critical guidance about preferring the highest version and distrusting unversioned forms due to nTop's rejection of retired revisions. However, it does not explicitly state when not to use this tool or mention alternative tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses that the tool sets the output block, that nTop reads the graph's own output key rather than root group inputs, and that passing -1 clears the output. It does not detail side effects or validation, but for a simple setter this is adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack the purpose, a critical prerequisite, the error condition, and the clear command (pass -1) with zero filler. The most important information is front-loaded, making it easy to scan.
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?
The description is complete for the tool's core function and the blockId parameter, and it explains the error when unset. However, it omits any explanation for the 'output' and 'notebook' parameters, and does not mention return values or side effects (e.g., whether the graph is modified in place). For a tool with low schema coverage, these gaps mean an agent cannot fully determine correct invocation.
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 only 33% (only blockId has a description). The tool description adds meaning for blockId via the '-1 to clear' note, but it says nothing about the 'output' or 'notebook' parameters, leaving them undocumented in both the schema and the description. An agent would not know what values to provide for these fields.
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 action (choose which block), a resource (the notebook output), and clarifies the distinction from related tools like set_input or add_block. It also explains the underlying mechanism (nTop reads the graph's own output key), which makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says this tool is 'Required before run_notebook's outputJson will produce anything' and describes the exact error message when unset, giving clear context on when to use it. It does not name alternatives, but the prerequisite and the -1 clear behavior provide strong usage guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It says 'check', implying non-destructive validation, and lists specific checks. This adds context beyond the name. The only gap is that it doesn't describe the result format (return value, errors) or any side effects, but it is otherwise transparent.
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, information-packed sentence that front-loads the purpose ('Check a notebook for problems that stop it loading or building') and then lists specific cases. Every phrase adds value; there is no fluff.
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?
The description lists the problem categories it detects, which is helpful, but it lacks information about the expected output (does it return a list, a boolean, or throw an exception?) and the exact nature of the notebook parameter. Given there is no output schema and low parameter coverage, these gaps leave the tool only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The single parameter 'notebook' is only described as part of the phrase 'Check a notebook', which fails to clarify whether it's a path, ID, content, or something else. The description adds no semantic detail beyond what the schema (a string) already provides.
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 verb ('check') and resource ('a notebook'), and enumerates specific problem types (dangling inputs, duplicate ids, etc.). This distinguishes it from sibling tools like run_notebook (executes) and inspect_notebook (presumably examines), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: when checking for specific loading/building problems. It implies a pre-run validation role. However, it doesn't explicitly name alternatives or state when not to use it, so it stops short of full guidance.
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:

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

Score Badge

Copy to your README.md:

[![ntopology-mcp MCP server](https://glama.ai/mcp/servers/sohumsuthar/ntopology-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sohumsuthar/ntopology-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sohumsuthar/ntopology-mcp'

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