WinTerminal MCP Server

by priesdelly

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation—listing, opening, writing, reading, closing, sending control bytes, and debugging—so there is no real overlap in purpose. The only adjacent pair, list_terminal_sessions and debug_inspect_sessions, is clearly separated by the diagnostic framing of the latter.
Naming Consistency4/5
All tool names use snake_case and begin with an imperative verb, which makes the set predictable. debug_inspect_sessions is slightly less clean because it stacks two verb-like words, but the overall convention remains consistent.
Tool Count5/5
Seven tools is well-scoped for a terminal session server: create, list, write, read, control, close, and debug. Each tool earns its place, and the set is neither too thin nor too heavy.
Completeness5/5
The tools cover the full lifecycle of persistent terminal sessions, including opening, enumerating, writing input, reading output, interrupting commands, and closing. Minor conveniences like session resizing are absent, but no core terminal workflow has a dead end.
Average 4.6/5 across 7 of 7 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, and the description aligns by saying it terminates and forgets the session. It adds useful context beyond annotations: the exact error message for an already-closed session and the fact that the session is forgotten, not just stopped.
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 compact and front-loaded with the key action, followed by an Args block and an error note. The Args block is somewhat redundant with the schema, but the overall length is appropriate and every element is relevant.
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 single-parameter destructive tool with no output schema, the description covers the action, parameter, and failure behavior. It does not describe the success return value, but that is a minor gap given the tool's simplicity and the annotations already signaling destructive behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the session parameter as "Session name to close." The description repeats this in the Args block without adding new meaning, so it earns the baseline score.
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 uses a specific verb ("Terminates") and resource ("a session's shell process"), and adds "forgets it" to distinguish closing from mere suspension. This clearly differentiates it from siblings like open_terminal_session, list_terminal_sessions, and write_to_terminal.
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 intended use is implied by the destructive verb "Terminates" and the reference to closing a session, but there is no explicit guidance about when to prefer this over siblings. The error note hints that the session must exist, but it does not suggest checking list_terminal_sessions first or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals key behaviors: it returns immediately without waiting for the command to finish, auto-creates the default session, enforces a dangerous-command safety filter, and can fail with a readOnlyMode error. This gives the agent a clear picture of consequences and side effects.
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 well-structured with Args, Returns, and Errors sections, and it front-loads the core behavior. It is somewhat verbose and partially duplicates the schema, but the additional operational details are relevant and not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the key contextual gaps: the return behavior, the follow-up read_terminal_output step, error conditions, and safety checks. Combined with the annotations and full schema coverage, an agent has enough information to use the tool correctly.
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 already documents all four parameters with descriptions and defaults (100% coverage). The description's Args section mostly paraphrases the schema, adding only minor context like "default shell" and the dangerousPatterns config reference, so it does not substantially expand parameter understanding beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it "writes a command or text into a session's shell input, exactly as if a person typed it, then presses Enter." This clearly distinguishes it from sibling tools like read_terminal_output, open_terminal_session, and send_control_character.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable workflow guidance: use read_terminal_output afterward to see results, and for non-default sessions call open_terminal_session or list_terminal_sessions first. It also explains when confirm=true is required. It does not explicitly contrast itself with send_control_character, but the context is otherwise clear.
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, idempotentHint=true, and destructiveHint=false. The description adds concrete behavioral context by revealing the exact internal state inspected (pid, alive status, buffer size) and its diagnostic purpose, which goes beyond what annotations alone convey.
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: the first front-loads the purpose and output fields, the second provides the usage trigger and negative guidance. Every word earns its place with no filler or redundant rephrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic tool, the description fully covers what it does, what it returns, and when to use it. There is no output schema, but the listed fields are enough for an agent to understand the result. No critical gaps are present.
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 input schema is empty with zero parameters, so the description carries no burden for parameter documentation. With zero parameters, baseline 4 applies; the description needs no parameter details and adds nothing that could confuse an agent.
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 ('dumps') and resource ('daemon's internal state for every session'), including the exact data fields returned (pid, alive status, buffered character count). This clearly distinguishes it from sibling terminal tools by framing it as a diagnostic inspection rather than a normal session operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('when a session seems stuck...') and when not to ('Not needed for normal use'), which is strong guidance. However, it doesn't name the specific alternative tools for normal use (e.g., list_terminal_sessions), so it falls just short of full routing.
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 cover safety (read-only, idempotent, non-destructive), so the description adds valuable extra behavior: it enumerates the returned fields, lists shell types, and clarifies that a process is marked alive or false if exited or killed. No contradiction with annotations exists, and no hidden mutation is implied.
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 three front-loaded sentences: what the tool does, what it returns, and when to use it. Every sentence adds decision-relevant information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter list tool, and the description fully accounts for the missing output schema by enumerating the return fields. Combined with the annotations and the explicit usage guidance, nothing necessary for correct invocation is missing.
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 already represents this with an empty properties object. There is no parameter meaning for the description to add, so the baseline score of 4 applies.
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 uses a specific action ('Lists') and a clearly bounded resource ('every session this server currently knows about'). It also explains the real backing shell process and distinguishes this inspection tool from the mutation/communication siblings like write_to_terminal and read_terminal_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: before write_to_terminal/read_terminal_output when session names are uncertain, and to check whether an exited session must be reopened. This gives the agent a concrete decision rule and names the related tools it supports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations, disclosing that escape codes are stripped, carriage-return rewrites are collapsed, output may be truncated from the start, polling behavior depends on waitForIdleMs, and full-screen apps appear as scrolling logs. This gives the agent an accurate model of the tool's quirks.
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 efficiently front-loaded with the core purpose, then systematically covers arguments, return shape, and the most important caveat. Every sentence adds useful information without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description responsibly documents the return object fields, truncation behavior, and the full-screen repaint limitation. An agent has enough information to call this tool correctly and interpret its results in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds valuable meaning by explaining the 'wait for output to stop changing' heuristic and clarifying that lines=0 means everything captured so far, which enriches the bare schema definitions.
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 begins with a specific verb and resource: 'Reads a session's captured output transcript'. It clearly distinguishes itself from sibling write/control tools and even clarifies it is not a full terminal screen emulation, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly positions this as the read-only counterpart to terminal-write tools and explains when to use waitForIdleMs as a heuristic for waiting until a command finishes. It does not explicitly name alternatives or state when not to use it, but the context and sibling list make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal a non-read-only, non-idempotent mutation, so the description carries the behavioral burden. It discloses safety boundaries ('physically cannot reach any other process', 'no keyboard/focus involved'), transport limitations ('Ctrl+Break is not supported'), and platform-specific caveats (PowerShell line editor behavior). 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 main purpose is front-loaded in the first sentence, followed by concise safety rationale, args, limitations, and reliability guidance. Each paragraph adds distinct value, and the structure is easy to scan without padding.
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 2-parameter tool with no output schema, the description thoroughly covers purpose, behavior, limitations, and alternatives. The only notable gap is that it never explicitly states that the target session must already be open (implied by sibling open_terminal_session), nor what happens if an invalid session ID is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that 'key' is a single letter for Ctrl+<key>, that 'C' is for interrupt, and that Ctrl+Break is not representable over this transport. The 'session' parameter is not expanded, but the added key semantics justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sends a real Ctrl+<key> control byte ... directly into a session's own shell input.' It also distinguishes itself from the sibling write_to_terminal by emphasizing it writes a literal ASCII control byte into the input pipe, not keyboard simulation or regular text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance ('Reliably interrupts a command that is actually running', 'Use "C" to interrupt a running command') and when-not-to-use guidance ('not a reliable way to cancel text already typed into the prompt...'). It also gives an alternative action: 'To discard an unsent fragment, close and reopen the session instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since all annotation hints are false, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It covers persistence, process isolation, name registration, automatic shell fallback with a warning, and the non-idempotent behavior of erroring on duplicate names. This goes well beyond what the annotations themselves reveal.
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 well-structured with a core opening sentence, a concise Args block, and then direct usage-oriented guidance. Every sentence contributes either to understanding the tool's behavior or to deciding when to use it. The explicit example of 'server' vs 'git' sessions is illustrative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and sparse annotations, but the description covers the essential runtime behavior, error conditions, default session behavior, and fallback logic. An agent has enough information to call this tool correctly, understand what will happen, and know how to handle common pitfalls. There is no critical missing context.
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 input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds extra value by explaining shell fallback behavior ('Falls back to powershell automatically (with a warning in the result) if pwsh.exe is not installed') and by framing the name parameter as the key to creating independently named sessions. It does not purely repeat schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb and resource: 'Starts a new, persistent shell process attached to its own pseudo console, and registers it under a name you choose.' It clearly differentiates from siblings by explaining when write_to_terminal auto-creates the 'default' session, and it mentions the distinct use case for named sessions. This is more than adequate for an agent to know exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this tool explicitly when you want a second, independently named session... or want to pick the shell/starting directory yourself.' It also states when it is not needed: 'You do not need to call this before write_to_terminal - writing to the "default" session name auto-creates it.' The error condition ('Errors if a session with that name is already open - close it first or pick a different name') further clarifies the usage boundary.
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:

[![Win-Terminal-MCP MCP server](https://glama.ai/mcp/servers/priesdelly/Win-Terminal-MCP/badges/card.svg)](https://glama.ai/mcp/servers/priesdelly/Win-Terminal-MCP)

Score Badge

Copy to your README.md:

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

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