Windows Telnet MCP

by gethshap

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct, but a few pairs overlap in intent: telnet_status and telnet_check both sound like health checks, and telnet_key and telnet_send both inject input. The descriptions resolve the ambiguity, but agents may need to read carefully to choose correctly.
Naming Consistency4/5
All tools share the consistent telnet_ prefix, and most use a clear verb-like pattern such as start, close, read, send, and list. A couple of names are nouns rather than actions—telnet_status and telnet_key—which is a minor deviation from the otherwise predictable convention.
Tool Count5/5
Ten tools is a well-scoped size for this server's purpose. Each tool covers a meaningful aspect of starting, interacting with, reading from, and closing a visible Windows Telnet session without unnecessary redundancy.
Completeness5/5
The tool surface covers the full lifecycle: start, list, focus, read, wait for output, send input, send special keys, close, and verify both process status and host capability. No obvious operational gaps remain for controlling a visible Telnet session.
Average 3.6/5 across 9 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false and destructiveHint=false, and the description adds context by specifying that the key goes to the visible Telnet console and that CTRL+] enters the Microsoft Telnet command prompt. This adds useful behavior beyond the annotations, though it does not disclose further side effects or state changes from key presses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the core action front-loaded. Every word contributes meaning, and the CTRL+] note is a valuable short addition without bloat.
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 two-parameter key-sending tool, the description is mostly sufficient, but it lacks usage guidance, return behavior, and any mention of whether the console must already be visible or focused. The schema covers the key enum and sessionId format, but the description does not fully compensate for the missing parameter explanations.
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 sessionId or enumerate key meanings. The only slight addition is 'named key' and the CTRL+] behavior note, but most parameter semantics are left entirely to the schema enum and 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 states a clear action ('Sends one named key') and a target ('the visible Telnet console'), so an agent can tell this is a keystroke-injection tool. It is not a tautology of the title, but it does not explicitly differentiate from sibling tools like telnet_send or telnet_focus.
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 gives no explicit guidance on when to use this tool versus alternatives such as telnet_send or telnet_wait_for_text. There is no mention of prerequisites like a visible or focused console, nor any exclusion criteria, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds a useful scoping detail: it checks a visible Windows process rather than a generic session. However, it does not disclose expected return values, behavior for an invalid or unknown sessionId, or whether the check is instantaneous.
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 with no filler; every word contributes meaning and the key scope qualifier ('visible') is included.
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 read-only check, the description conveys the high-level behavior, but there is no output schema and no explicit description of the result format. The agent must infer that the tool returns a running/not-running indication and cannot anticipate error behavior.
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 never mentions sessionId or how it relates to the process being checked. Since schema description coverage is 0%, the description was expected to compensate, but the schema's self-explanatory UUID field does most of the work.
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?
Description names a specific verb ('Checks whether ... is still running') and a concrete resource (visible Windows Telnet process), so the tool's core purpose is clear. It doesn't explicitly contrast with the sibling telnet_check, but the status/check wording largely differentiates it.
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 when-to-use or when-not-to-use guidance is given. With nine sibling tools, an agent gets no explicit hint about when to call telnet_status instead of telnet_check, telnet_list, or telnet_read; suitability is only implied by the name.
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?
The annotations already mark it read-only and open-world; the description adds meaningful behavior beyond that: it polls the real console, performs literal matching, and resolves on timeout. This is useful context for an agent deciding whether to call it and what to expect.
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 with no filler. Every phrase ('real console screen', 'literal text', 'timeout expires') adds a distinct piece of information.
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 six parameters, zero schema descriptions, and no output schema, the description is too sparse to fully support correct invocation. It omits the meaning of rows and pollMs, the case-sensitivity default, and what happens on timeout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to compensate, but it only loosely covers 'text' and 'timeout'. It does not explain sessionId, rows, pollMs, or caseSensitive beyond what their names and defaults suggest, leaving ambiguity around rows and polling behavior.
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 and resource ('Polls the real console screen') and clarifies that the operation is a blocking wait for literal text or timeout. It is clear on its own, though it does not explicitly contrast itself with siblings like telnet_check or telnet_read.
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 conveys that the tool waits/polls, but it gives no guidance on when to choose this tool over the sibling telnet_check, telnet_read, or telnet_send tools, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it clarifies that the tool affects the real conhost.exe window and brings it to the foreground, and annotations indicate it is neither read-only nor destructive. However, it does not mention side effects such as stealing focus, potential failure conditions, or whether it can reveal a minimized or hidden window.
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 clear, front-loaded sentence with no filler. It communicates the operation and target efficiently.
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 very simple tool with one parameter and no output schema, the purpose is stated clearly enough to attempt a call. Still, the description lacks usage conditions, parameter mapping, and behavioral side effects, so it is only minimally 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%, and the description does not mention sessionId or explain how it identifies the target Telnet session. The parameter name and UUID format make the meaning partially inferable, but the description itself provides no compensating semantic guidance.
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 exactly what the tool does: 'Restores and brings the real conhost.exe Telnet window to the foreground.' This distinguishes it clearly from sibling tools like telnet_start, telnet_close, and telnet_read by targeting window focus rather than session lifecycle or I/O.
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 given about when to use this tool versus alternatives, when it is appropriate, or what prerequisites exist (e.g., the session must already be started and its window must exist). The usage context must be inferred entirely from the tool 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?
The readOnlyHint annotation already covers the safety profile. The description adds useful scoping ('visible... started by this MCP server process') but leaves the term 'visible' undefined and does not disclose return format or pagination behavior. This adds context beyond annotations but not rich behavioral detail.
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 with no filler. Every word adds meaning: 'visible', 'Windows Telnet sessions', and 'started by this MCP server process' all contribute to the tool's purpose and scope.
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 no-parameter, read-only list tool, the description is mostly adequate: it states what is listed and the process scope. However, with no output schema, the description should hint at what the returned session list contains (e.g., IDs, names), and the ambiguous 'visible' could confuse an agent. This is a minor but real gap.
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, so the input schema is complete and there is nothing for the description to clarify. Baseline of 4 is appropriate; no parameter documentation is needed and the description correctly avoids inventing parameter details.
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 ('Lists') and resource ('visible Windows Telnet sessions started by this MCP server process'), which clearly defines scope. It does not explicitly name a sibling tool for differentiation, but the 'started by this MCP server process' qualifier distinguishes it from broader session queries.
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 telnet_status or telnet_check. The description implies it is for enumerating sessions, but it does not state exclusions or conditions that would route an agent to a sibling tool.
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?
Annotations already flag readOnlyHint=false and openWorldHint=true, so the agent knows this is an actuating, externally-facing operation. The description adds genuinely useful behavioral context beyond the annotations: it opens a real, user-visible conhost.exe window and uses the built-in telnet.exe, which has visible UI side effects. It does not mention whether the call blocks or returns a session handle, but the visible-window and outbound-connection details are meaningful.
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 efficient sentences with no filler. The first sentence front-loads the essential visible-window behavior, and the second adds the only conditional behavior worth calling out. It earns full credit for structure even though other dimensions have gaps.
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 8 parameters, no output schema, and an open-world annotation, the description is not complete enough for confident invocation. It explains host handling but leaves credentials-related fields (username/autoLogin), port defaults, terminalType, escapeCharacter, and logFile mostly unexplained, several of which also lack schema descriptions. The agent is also left guessing about return behavior and session lifecycle.
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%, with six of eight parameters undecorated. The description mostly restates the host behavior already present in the schema and does not explain port defaults, the meaning of autoLogin, terminalType choices, escapeCharacter semantics, or title/logFile behavior. With low schema coverage, the description needed to compensate but largely does not.
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 ('Opens') and resource ('conhost.exe window running the built-in Windows telnet.exe'), making the tool's action unmistakable. It also reveals the host-dependent outbound connection behavior, which clearly separates it from the sibling control/interaction tools.
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 gives conditional usage context: provide a host to connect, omit it to get the Telnet prompt. However, it never explicitly explains when to choose this tool over telnet_send, telnet_focus, telnet_close, or the other siblings, nor does it mention prerequisites like the Windows Telnet client being enabled.
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?
The annotations already signal a non-read-only, open-world operation, and the description adds useful behavioral context: it injects real keyboard events, targets the visible session, and that text may reach the remote Telnet server. This goes beyond the annotations without contradicting them.
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 filler. The primary action is front-loaded, and the appendEnter behavior is stated succinctly in the second 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?
For a simple three-parameter action with no output schema, the description covers the core behavior, the key flag, and the external transmission risk. It is mostly complete, though it could mention what happens on success or failure.
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 text as the injected payload and appendEnter as the line-submit flag, but sessionId is only implicit from its name and schema pattern. Most parameters get some semantic clarity, but not all are explicitly mapped.
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 that the tool injects text as Windows console keyboard events into a visible Telnet session, which is a specific verb and resource. It is clear in what it does, though it does not explicitly differentiate itself from the sibling tool telnet_key.
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 gives one concrete usage instruction: 'Set appendEnter=true to submit the line.' However, it does not explicitly say when to use this tool versus alternatives like telnet_key, nor does it mention any exclusions or prerequisites.
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?
The readOnlyHint annotation already signals no mutation, and the description adds useful context: the check is local, capability-oriented, and specific to a visible Windows Telnet client. No contradictory behavioral claims are present.
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?
One sentence delivers the complete purpose without filler. The key scoping information is front-loaded and the title reinforces the meaning.
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, read-only capability check, the description is nearly sufficient. 'Checks whether' implies a boolean or status result, though an explicit return contract would be marginally clearer given the absence of an output schema.
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 covers all relevant input. With no parameters, the description has no semantic burden for arguments.
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 ('checks whether') and a specific resource ('this machine can open and control a visible Windows Telnet client'). It is clearly not a status/read/send operation, though it does not explicitly name a sibling to distinguish itself from.
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 title says 'prerequisites' and the description implies this should be used before attempting to open/control a Telnet client. However, there is no explicit statement of when to use it versus telnet_status or telnet_start, nor any exclusions.
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?
Annotations already signal destructive and non-read-only behavior. The description adds concrete behavioral detail: graceful mode performs CTRL+] then quit, and force mode terminates the process if needed. This goes beyond what annotations alone provide and helps the agent anticipate side effects and failure fallbacks.
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 tight sentences, no fluff. The main purpose is front-loaded and the two modes are summarized efficiently. Every clause contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter close operation with no output schema, the description is largely sufficient. It explains the key behavioral choice via force and relies on the destructive annotation for safety. The only notable gap is that 'sessionId' semantics are not explicitly connected to the close action, but this is relatively minor given the schema and sibling context.
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 the 'force' boolean semantics via graceful vs force mode, which adds real value. However, it does not explicitly describe 'sessionId' beyond the schema's type/pattern, leaving its role to be inferred from the tool name and context.
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 opens with a specific verb and resource: 'Closes the visible Telnet session.' It is distinct from sibling tools (read, send, start, list) and clarifies two execution modes. The term 'visible' adds useful scoping about which session is affected.
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 when to use the tool (to end a telnet session) and even gives guidance on choosing graceful vs force mode. However, it does not explicitly compare against any sibling tools or mention when not to use it. The mode explanation provides usable context but stops short of full routing 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?
Annotations already declare readOnlyHint=true, and the description agrees by saying it 'Reads text'. It adds useful behavioral detail: the source is the real Windows console screen buffer, and the two modes return different scopes. It does not discuss edge cases, but the read-only annotation lowers the burden.
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 filler: it states the action, the source, and the meaningful mode distinction. The most important information is front-loaded in the first clause.
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-only tool with a simple parameter set and no output schema, the description gives enough to understand what is read, where it is read from, and how mode affects the result. It could be more explicit about how 'rows' behaves in tail mode, but overall the agent can correctly select and invoke the tool.
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?
With 0% schema description coverage, the description compensates for the critical mode parameter by defining 'visible' and 'tail'. However, 'rows' is only implied by 'recent buffer rows' and sessionId is left entirely to its name and schema format, so parameter coverage is incomplete.
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 ('Reads text') on a clear resource ('the real Windows console screen buffer') and distinguishes the tool from sibling send/key/wait operations by framing it as a non-mutating read. The mode options 'visible' and 'tail' further clarify 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use mode=visible ('exactly what the user can see') versus mode=tail ('recent buffer rows'). It does not enumerate when not to use this tool compared with sibling read/check tools, but the mode guidance provides clear context for the main decision.
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:

[![windows-telnet-mcp MCP server](https://glama.ai/mcp/servers/gethshap/windows-telnet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gethshap/windows-telnet-mcp)

Score Badge

Copy to your README.md:

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

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