nt-mcp-server

by Mzzj114

Overview Schema Related Servers Score Discussions

Python

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 serves a distinct purpose: connection management, get/set operations, topic listing, subscriptions (both transient and persistent), and recording access. No overlapping functionality.
Naming Consistency5/5
All tools use a consistent 'nt_' prefix and follow a verb_noun pattern (e.g., nt_get, nt_set_multiple, nt_list_topics, nt_start_subscription). Naming is uniform and predictable.
Tool Count4/5
With 18 tools, the set is slightly larger than typical but justified by the breadth of NetworkTables features (live/offline, subscriptions, recordings). It remains manageable and not overwhelming.
Completeness5/5
The tool surface covers all major operations: connect/disconnect, get/set (individual and bulk), topic listing, both transient and persistent subscriptions, and comprehensive recording access (list, info, history, offline subscription). No obvious gaps.
Average 3.2/5 across 18 of 18 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 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

Behavior1/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 only mentions the return structure and gives no information about side effects, safety, error conditions, or whether it is read-only. This is a significant gap for a tool that likely queries connection state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, consisting of a single line. While it is not verbose, it is under-specified—it does not provide enough context to be useful. The format is front-loaded but the content is insufficient, reflecting under-specification rather than effective conciseness.
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 an output schema exists, the description is not required to detail return values, but it still fails to explain the tool's role. It omits any mention of what 'connections' refers to, the meaning of 'connected', or the operational context. The tool appears to be a simple query, but without context, the description is incomplete.
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 the schema is empty with 100% coverage by default. The baseline for 0-param tools is 4, and the description adds no parameter-related requirements. There is nothing to explain, so this score is appropriate.
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 only states 'Return {"connected": bool, "connections": [...]}' which is a return type pattern, but does not explicitly say what the tool does (e.g., 'Get connection info'). It hints at returning connection status but lacks a clear verb and resource. It does not differentiate from siblings like nt_get_info or nt_list_topics.
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 mention prerequisites (e.g., whether a connection must be active) or contrast with related tools like nt_connect or nt_disconnect. The absence of any usage context leaves the agent without direction.
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 must carry the full burden. It does not disclose whether this is a read-only operation, whether it requires an active connection, or what happens if the topic does not exist. The response format is given, but behavioral traits like error handling or side effects are not mentioned.
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 very short and to the point, with no wasted words. It includes the response format, which is useful. However, it is under-specified, which is a completeness issue rather than a conciseness issue.
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 tool's simplicity (one parameter) and the presence of an output schema, the description is minimal but not entirely inadequate. However, it lacks context about the tool's role among many siblings, and the output schema is not shown to the agent, so the description should explain the response more. The lack of usage guidance and behavioral transparency makes 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?
The schema has one parameter 'topic' with no description, and the description does not elaborate on its meaning beyond the name. It does not specify the expected format (e.g., string identifier, path) or any constraints. With 0% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns metadata for a topic, which is a clear verb+resource. However, it does not distinguish itself from sibling tools like nt_get or nt_get_multiple, which likely also retrieve data. The response format is shown, but the purpose could be more specific about what 'metadata' includes.
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. It does not mention that nt_get_multiple might be used for multiple topics, or that nt_connection_info might be relevant for connection status. The description lacks any context about typical use cases or exclusions.
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 exist, so the description must carry the full behavioral burden. The description only says 'list unique topic names,' providing no insight into side effects, permissions, performance implications, or what 'filtered' entails. It fails to disclose any behavioral characteristics beyond the most basic function.
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 one concise, single sentence with no filler. It is appropriately brief for the function it describes, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and five parameters, the description is severely underpowered. It doesn't explain what a 'recording' is, how filters work, what the output schema contains, or how this offline tool differs from its online counterpart. The lack of any supplementary information makes it impossible for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter documentation in the description, this tool offers no additional meaning beyond the parameter names (regex, prefix, wildcard, etc.). The description's 'optionally filtered' is too vague to clarify how parameters work or interact.
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 lists unique topic names from a recording and can be filtered. It uses a specific verb and resource. However, it doesn't explicitly distinguish itself from the sibling tool nt_list_topics, though the 'offline' in the name provides some 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?
There is no guidance on when to use this tool versus alternatives like nt_list_topics or nt_subscribe_offline. The phrase 'optionally filtered' is the only hint, but no explicit context, examples, or exclusions are provided. It fails to help the agent choose between this and related tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure. 'Return metadata' suggests a read-only operation, but it does not explicitly state that there are no side effects, describe error behavior, or clarify data-source dependencies. Listing output fields adds some value, but the output schema likely already covers the return values.
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 very concise: one front-loaded purpose sentence followed by a compact list of returned metadata fields. Every sentence contributes to understanding the tool with no filler.
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?
Despite having an output schema, the tool has two undocumented parameters, zero required parameters, and no usage guidance. The description does not provide enough context for an agent to confidently select and invoke the tool 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 0%, and the description does not explain either parameter. 'Recording' indirectly hints at recording_id, but output_dir is completely unexplained, and both parameters are optional, creating ambiguity about what the tool actually needs.
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 'Return metadata about a recording' and enumerates the key fields returned, which makes the primary purpose easy to grasp. However, it does not explicitly distinguish itself from siblings like nt_get_info or nt_list_recordings.
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 over alternatives such as nt_get_info or nt_list_recordings. The description implies it is for recording metadata, but it does not state prerequisites, exclusions, or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden and it does add the response structure `{'connected': bool, 'values': {topic: value}}`, which gives useful behavioral shape. However, the semantics of the 'connected' field are left entirely unexplained, and there is no disclosure of error behavior, partial-failure handling, or what happens for invalid topics.
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 efficiently minimal: a one-sentence purpose followed by a structured response format line. It is front-loaded and wastes no words. The phrasing 'every requested topic' is slightly awkward and could be smoother, but the overall structure earns points for channeling information into a compact, parseable form.
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 low complexity (one parameter) and the presence of an output schema, the description is nearly adequate. However, it misses chances to clarify the meaning of the 'connected' boolean, the relationship to nt_get, and whether duplicate or unknown topics in the request cause failures. It does document the response shape, which partially compensates for the missing semantics.
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?
The schema description coverage is 0%, and the description fails to compensate despite the low coverage. While the phrase 'requested topic' loosely echoes the 'topics' parameter, it adds no semantic detail, constraints, format, or examples beyond what the schema already states (array of strings).
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 strong action verb ('Return') with a clear resource ('values for every requested topic'), making the batch-read purpose obvious. It distinguishes from nt_get via the name's 'multiple' qualifier, though the description text itself doesn't explicitly contrast with siblings, so it stops short of a 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?
No explicit guidance is provided on when to use this tool vs. alternatives. The existence of nt_get (singular) makes the batch-vs-single contrast inferable, but the description never states when to prefer this tool, names an alternative, or gives a rule of thumb, leaving the agent to infer all usage context from the name and sibling list.
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 carries the full burden of behavioral disclosure. It does reveal the response structure (connected, results, warnings), which implies partial success behavior, but it fails to mention whether the operation is atomic, whether existing values are overwritten, or the semantics of strict_type_check.
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 extremely concise (two lines) and clearly structured with the purpose and response format in a code block. It earns its place without unnecessary detail, though the response format could be considered part of the output schema rather than the description.
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 batch-write tool with an output schema, the description covers the return shape but misses key behavioral context such as atomicity, strict_type_check semantics, and connection prerequisites. It is adequate but not thorough for an agent to fully understand side effects.
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?
The description explains the core 'updates' parameter as 'topic: value' pairs, but it does not name the parameter or address strict_type_check. Given 0% schema coverage, the description only partially compensates for the missing parameter documentation.
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 the verb 'Write' with the resource 'topic: value pair', clearly indicating a batch write operation for multiple topics. The word 'every' distinguishes it from sibling nt_set, though it could be more explicit about being the batch variant.
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 is provided on when to use this tool versus alternatives like nt_set. It omits any context about prerequisites (e.g., connection state) or when strict_type_check should be enabled, leaving the agent to infer usage.
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?
With no annotations, the description must disclose behavior. It mentions 'wait for a live connection' implying a blocking operation, but does not describe failure modes, timeouts, side effects, idempotency, or whether it replaces an existing connection. The description is too sparse to inform the agent of important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no filler, redundancy, or unnecessary detail. It is front-loaded with the core action and easily parseable, making it ideal for quick consumption.
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 tool likely serves as a setup step and has many siblings, the description lacks essential context. It does not explain why the tool is needed, what happens after connection, or any relationship to other tools. An output schema exists, but the description still does not cover the full scope of a connection operation, leaving gaps in an agent's 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?
The input schema has 4 parameters (identity, server_ip, server_port, team_number) with zero schema descriptions (coverage 0%). The description does not elaborate on any parameter, forcing the agent to infer meaning from names and defaults. For instance, 'team_number' is ambiguous, and no explanation is given for how these parameters affect the connection.
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 'Start the NT4 client and wait for a live connection' clearly identifies the action (starting a client and waiting for connection), the resource (NT4 client), and implicitly differentiates it from siblings like nt_disconnect and nt_connection_info. It uses a specific verb and resource combination, making 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or typical scenarios. It only states the action without explaining context such as 'call this before other NT operations' or 'avoid calling if already connected'.
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?
With no annotations, the description must disclose all behavioral traits. It only mentions that 'last_seconds' selects a recent time window and that some parameters mirror nt_subscribe, but it omits details about read-only nature, required recordings, connection prerequisites, return format, or side effects. The agent is largely left in the dark.
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 well-structured, with the core purpose first and parameter hints in a second sentence. No fluff or redundancy. It earns its short length, though it could include more detail without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, and only a few words of guidance, the description is severely incomplete. It fails to explain how to specify a recording (recording_id), what output_dir does, or how start/end/limit relate to the timestamp range. The single line of purpose is insufficient for a tool this complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains 'last_seconds' and partially references 'sample_interval' and 'format' via the nt_subscribe comparison. The other six parameters (end, limit, start, topic, output_dir, recording_id) are completely unexplained, leaving the agent to guess their meaning and usage.
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 ('Return event history'), the target ('for one topic'), and the scope ('from a recording'), which distinguishes it from live tools like nt_get or nt_subscribe. The verb and resource are specific and 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?
It provides some usage context by referencing 'from a recording' and notes that 'sample_interval' and 'format="summary"' behave like 'nt_subscribe', giving the agent a behavioral pointer. However, it does not explicitly state when to choose this tool over other history-related siblings (e.g., nt_get_recording_info) or when not to use it, so guidance is limited.
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 carries the behavioral disclosure burden. It adds the response format {'connected': bool, 'topics': [...]}, which is useful, but it omits filter combination semantics, connection requirements, and behavior when no topics match.
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, front-loading the core operation and then providing a compact response format. Every word is relevant and there is no filler.
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 list tool with all-optional filters, the description is mostly adequate, but it misses the important distinction from nt_list_topics_offline and does not explain how filters combine. The response format partially compensates for the lack of a full output schema.
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 for parameter meaning. It only restates the three filter names—prefix, regex, and wildcard—without explaining their syntax, how they interact, or their defaults, adding little beyond the schema property 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 begins with 'Return topic names, filtered by prefix, regex, and/or wildcard', which clearly states the operation, resource, and filtering dimensions. It does not explicitly contrast with sibling tool nt_list_topics_offline, but the response shape mentioning 'connected' hints at the online context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus nt_list_topics_offline or whether an active connection is required. The description lists filter options but gives no decision framework or alternatives.
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 of behavioral disclosure. It states that resources are freed, but does not say whether the subscription_id becomes invalid, whether stopping is idempotent, or what happens to pending messages. This is minimal disclosure.
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 sentence that front-loads the action and includes no filler. Every word 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?
For a simple one-parameter stop operation with an output schema, the description is minimally adequate. However, with no annotations and no usage or parameter guidance, it leaves the agent to infer lifecycle context and side effects.
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 needed to compensate by explaining subscription_id. It only indirectly ties the parameter to the persistent subscription via the tool name and description, without specifying format, how to obtain it, or any constraints.
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 specific verb ('Stop') and identifies the resource ('persistent subscription'), clearly distinguishing it from sibling tools like nt_start_subscription and nt_poll_subscription. However, it does not explicitly contrast it with alternatives, so it stops short of a 5.
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?
Usage is implied: call this when you want to terminate a persistent subscription and release its resources. But there is no explicit when-to-use or when-not-to-use guidance, nor mention that it is the counterpart to nt_start_subscription or how it differs from nt_disconnect.
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 carries the transparency burden. It discloses the tool's connection-dependent behavior (returns value when connected, error when disconnected) and defines the response structure. However, it does not mention potential side effects, timeout behavior, or whether the topic must exist.
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: the first states the core function, the second provides the response format. It is front-loaded, efficient, and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and the provided response format, the description covers the essential purpose, connection state behavior, and output structure. It is missing usage guidelines and parameter details, but as a read-only simple getter, it is reasonably 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?
The input schema has one 'topic' string parameter with no descriptions (0% coverage). The description adds minimal meaning beyond 'the value of topic,' lacking details on valid topic formats, path syntax, or examples. It does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the JSON-normalized value of a topic, using a specific verb ('Return') and a clear resource. It is distinct from siblings like nt_get_multiple by focusing on a single topic, though it does not explicitly contrast itself with them.
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 nt_get_multiple or nt_subscribe. It also does not mention prerequisites such as requiring an active connection, beyond the implicit connected/disconnected response states.
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?
There are no annotations. The description is solely burdened with behavioral traits. It mentions that 'format=summary' returns min/max/mean/last per topic, but it doesn't say what happens for the subscription until it stops, what data is returned, or about invalid parameters/permissions/errors. It does not contradict the annotations, as they are absent.
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?
One dense sentence with inline code; efficient in space, but the inline sentence is a bit hard to parse. Not too long.
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 output schema is provided, so the return shape need not be spelled out; yet the description doesn't give information about the'last_seconds' positions and the meaning of 'limit'/'start'/'end'. The live subscription vs offline context is implicit, not explicit.
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?
The schema has many optional parameters (start, end, limit, output_dir, recording_id) and the descriptions are not provided. The description is limited to prefixes, but the interplay of the last few params is unclear. The described params: prefixes, last_seconds, sample_interval, format. Mapping between several optional params is not useful.
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 specific action: 'return events for every topic under prefixes from a recording.' This is clear and distinguishes this tool as an offline subscription tool. It doesn't name sibling tools, but the offline/recording context separates it enough.
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 context of use is clear: this is for a recording rather than a live connection. It does not explicitly explain when to choose this over nt_subscribe or nt_get, but uses the word 'from a recording' and the 'offline' in the name.
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 must carry behavioral disclosure on its own. It accurately describes a non-destructive listing operation and the returned fields, but it does not mention behavior of the output_dir default, sorting, or error cases. There is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using one clear purpose sentence and a compact list of returned fields. Every sentence contributes meaningful information without 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?
This is a simple one-parameter list tool with an output schema available, so describing return values in detail is unnecessary. The description covers the main purpose and result shape, but slightly under-specifies the output_dir parameter behavior and lacks any caveats or edge-case 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?
The sole parameter output_dir has 0% schema description coverage. The description mentions 'the output directory' but never explicitly explains the output_dir parameter, its null default, or how the path is resolved. This provides only minimal compensation for the missing parameter documentation.
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 available NDJSON recordings') and the scope ('in the output directory'). It also lists the returned entry fields, making the tool's purpose explicit and distinct from siblings like nt_get_recording_info or nt_list_topics.
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 related tools such as nt_get_recording_info or nt_list_topics, and no exclusions or alternative recommendations. The only usage context is implied by the phrase 'List available recordings'.
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 mentions the response fields and the need to poll and stop, which gives a sense of the tool's behavior. But with no annotations, it does not disclose potential errors, side effects, or resource implications, leaving important transparency gaps.
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 and well-structured. It states the purpose, gives the response format, and mentions the follow-up tools in a clear, direct manner without superfluous details.
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?
While the overall flow is outlined, the lack of parameter explanations and error handling makes it incomplete. The tool's complexity is moderate, but the description fails to provide essential context for confident usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides three parameters (prefixes, buffer_size, subscription_id) but the description offers no explanation for any of them. Since schema coverage is 0% and the description does not compensate, the agent has no idea what these parameters mean or how to use them.
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: 'Open a persistent subscription and start collecting samples.' It explicitly mentions the response structure and the complementary tools for polling and stopping, which distinguishes it from sibling tools like nt_subscribe or nt_poll_subscription.
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 provides a clear workflow: start, then poll, then stop. This implies when to use the tool (as the initial step in a persistent subscription flow). However, it does not explicitly contrast with other subscription methods (e.g., nt_subscribe might be one-shot), so it falls short of being fully explicit.
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?
Without annotations, the description must disclose behavior, and it does cover response format, sample_interval decimation, change_only threshold, and format='summary' aggregation. However, it does not mention side effects (e.g., whether the subscription is one-shot or persistent), rate limits, or cleanup requirements. It provides moderate behavioral insight but leaves significant gaps.
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 exceptionally compact, using three short paragraphs to convey purpose, response format, and key parameter behaviors. Every sentence adds value, and the structure front-loads the core idea before diving into parameter specifics. No fluff or redundancy.
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 complexity (5 params, output schema present), the description covers the core functionality well: sampling under prefixes, duration, decimation, change thresholds, and summary statistics. It does not address error handling, connection prerequisites, or interaction with sibling tools, but the existence of an output schema and related lifecycle tools mitigate the need for those details. A strong, focused description.
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 0%, so the description must explain parameters. It effectively details sample_interval (decimation), change_only (threshold), and format (samples vs. summary) with behavioral semantics. Prefixes and duration are left implicit, but their meaning is evident from the schema and context. This strongly compensates for the schema's lack of descriptions.
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 specific verb 'Sample' with a clear resource (value updates under prefixes) and a time boundary (duration). The response format is also given, which helps distinguish it from siblings like nt_subscribe_offline. However, it could be more explicit about the subscription mechanism and does not name alternatives, so a 4 is warranted.
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 is provided on when to use this tool versus siblings like nt_subscribe_offline, nt_start_subscription, or nt_poll_subscription. The description focuses solely on parameter effects and output, omitting use cases, prerequisites (e.g., an active nt_connect), or when not to use it. This leaves the agent without decision criteria for tool selection.
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 full burden of behavioral disclosure. It provides the response format ('Response: {"connected": bool, "ok": bool, "warning": str | null}') and explains strict_type_check behavior ('refuses mismatched writes instead of only warning'). This gives meaningful insight into the tool's operation, though it omits prerequisites like connection state.
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 information-dense: the action, the response format, and the strict_type_check nuance. No redundant language, and key content is front-loaded.
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 covers the core action and response, but misses important context like the need to be connected to a server (given sibling tools nt_connect/nt_disconnect) and potential constraints on value types. For a tool in a larger connected system, this is a noticeable gap.
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 0% description coverage, so the description must compensate. It effectively explains strict_type_check ('refuses mismatched writes'), but topic and value are only described generically via 'Publish value to topic'. This adds some meaning but not deep detail about value types or topic format.
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 immediately states 'Publish value to topic', which is a specific verb+resource. It clearly distinguishes from sibling tools like nt_get (retrieve) and nt_set_multiple (batch operation), making the singular 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?
No explicit when-to-use or alternatives are mentioned, such as using nt_set_multiple for batch operations or ensuring a connection before publishing. The usage context is implied by the name and description, but not stated clearly.
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 states what it does (stop client, tear down subscriptions) but doesn't disclose side effects like whether it's irreversible, whether it requires confirmation, or if it affects other clients. No annotations are present to fill this 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 and to the point, with no unnecessary words. It effectively conveys the action in one sentence.
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 simplicity of the operation and that an output schema exists, the description is sufficiently complete. It tells what happens (client stop and subscription teardown) without needing to elaborate on return values.
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 tool takes no parameters, and the schema coverage is 100% (empty). Since no parameters exist, the description adds no extra info, but the baseline is 3 due to high schema coverage.
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: stop the NT4 client and tear down persistent subscriptions. It distinguishes from sibling tools like nt_connect (start) and nt_subscribe (create subscriptions).
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 is implied this is used when the client should be stopped and subscriptions cleaned up, but it doesn't explicitly state when to prefer this over other tools or mention any prerequisites (e.g., must be connected).
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?
No annotations are present, so the description carries the behavioral burden. It discloses the output shape, the connected flag, and the important side effect that clear=True empties the buffer after reading. It does not explain error cases or lifecycle requirements, but for a simple polling tool this is fairly 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 compact and front-loaded. The first sentence states the action, and the following code block and clear=True note add necessary detail without filler. Every sentence earns its place.
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 two-parameter, simple polling tool with an output schema, this is nearly complete. It includes the response format and the key clear-buffer behavior. It lacks a bit of context about how persistent subscriptions are created or how this relates to nt_start_subscription, but the core behavior is well specified.
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%, so the description must compensate. It explains clear=True empties the buffer, which is useful semantics beyond the schema. However, subscription_id is only defined by its name and schema type, with no guidance about how to obtain it or what happens if it is invalid.
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: 'Return buffered samples for a persistent subscription.' This uses a specific verb and resource, and the 'persistent subscription' phrasing distinguishes it from one-shot getters like nt_get and nt_get_multiple. The response shape also reinforces the purpose.
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 provides clear context that this tool is for polling a persistent subscription's buffer. It does not explicitly name alternatives or say when not to use it, but the persistent-subscription framing makes the intended use case reasonably clear.
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:

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

Score Badge

Copy to your README.md:

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

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