mcp-remote-control

by shiharuharu

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.2.3
Disambiguation5/5
Each tool targets a distinct resource or action: endpoint manages host lifecycle, exec runs non-interactive commands, fs handles filesystem operations, screen provides interactive PTY, ps manages PowerShell runspaces, console handles serial devices, and config manages profiles. Overlapping tools like screen and console are explicitly differentiated by hardware type, while exec and ps differ in interactivity and persistence.
Naming Consistency5/5
All tool names are single lowercase words (endpoint, exec, fs, screen, ps, console, config) following a consistent, predictable pattern. There is no mixing of conventions such as camelCase or snake_case.
Tool Count5/5
Seven tools is well-scoped for a remote control server, covering all major operation areas (connection, command execution, files, terminal, PowerShell, serial, configuration) without unnecessary overlap or bloat.
Completeness5/5
The tool set provides comprehensive coverage of remote management workflows: endpoint lifecycle, command/script execution, file transfer and manipulation, interactive sessions, persistent PowerShell, serial console access, and profile/secret configuration. There are no obvious dead ends or missing critical operations.
Average 3.6/5 across 6 of 7 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'path= absolute preferred' but does not disclose side effects (destructive ops like rm, write), permissions, error handling, or return behavior. Minimal transparency.
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 and front-loaded with the operation list. No wasted words, but the terse style (ep=, path=) reduces readability and requires inference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-operation tool with 6 parameters, no output schema, and no annotations. The description covers only the op list and path preference, leaving most operational semantics unexplained. Inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'op' values and hints that 'path' should be absolute, but 'ep', 'local', 'content', and 'recursive' are left undefined. Partial compensation at best.
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 identifies this as a filesystem tool by listing operations (list|stat|read|write|put|get|mkdir|rm). This distinguishes it from sibling tools like exec and config, though the verb 'operate' is implied rather than explicit.
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 given on when to use this tool vs alternatives like exec or endpoint. The op list implies filesystem tasks, but there are no exclusions, prerequisites, or alternative tool references.
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. It mentions 'non-interactive' and 'remote' but omits important behaviors such as output handling, exit codes, side effects, privilege requirements, or failure modes.
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 dense sentence, front-loaded with the core action and parameter alternatives. No filler words; every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 9-parameter tool with no annotations, output schema, or parameter descriptions, this is thin. It does not mention return values, error behavior, environment context, or prerequisites, leaving significant gaps for an agent to use it 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?
All 9 parameters are referenced in the description with usage patterns (alternatives like command/argv/script, optional runtime/script_args/cwd/timeout), adding structural meaning beyond the bare schema. However, it does not explain individual semantics like timeout units or what 'runtime' means.
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 'Remote non-interactive exec on ep=' using a specific verb (exec) and resource (ep). It conveys remote command execution and is distinguishable from sibling tools like fs or ps, though it does not explicitly differentiate itself.
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 parameter invocation patterns but no guidance on when to use this tool versus alternatives like console or screen. It lacks exclusions, recommended use cases, or contextual selection criteria.
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. It discloses that the runspace is persistent and uses WinRM, but it does not explain side effects, cleanup obligations, authentication requirements, error behavior, or what happens to state across calls. Key behavioral aspects like the need to close the runspace or the output of invoke are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the core purpose and then provides the operation-parameter mapping. Every phrase contributes necessary information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool managing persistent remote sessions, the description is incomplete. It lacks information about return values, authentication, error handling, resource cleanup if close is never called, and the format of endpoint (ep). The absence of an output schema makes this more critical, but the description does not compensate.
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%, and the description compensates by explaining the conditional parameter requirements: 'open needs ep=; invoke/close need id=; invoke uses script='. This adds meaning beyond the raw schema by mapping parameters to operations, though it does not define each parameter's full purpose or format.
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 manages a 'Persistent PowerShell runspace (WinRM)' and enumerates the operations (open/invoke/close), which gives a specific verb-resource mapping. It is distinct from siblings by naming the resource, but it does not explicitly differentiate itself from sibling tools like 'exec' or 'endpoint'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the term 'Persistent' and lists operation-specific parameter requirements, which gives some context on when to use each operation. However, it does not explicitly state when this tool should be preferred over siblings or mention exclusions/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?
With no annotations, the description must disclose side effects and safety. It doesn't mention whether close is destructive, if operations are reversible, or what happens to existing endpoints. It only scopes the tool to 'lifecycle' and gives parameter usage, but lacks 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?
Two sentences, front-loaded with purpose, dense with relevant details, and 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 3-parameter tool with no annotations and no output schema, this description covers operation semantics and parameter mapping but omits return values, error conditions, and side-effect details. It's sufficient for a basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does map op values to parameters (open uses profile, close uses ep), which adds meaning beyond the bare schema, but it doesn't define what ep or profile actually represent or the behavior of the default op=list.
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 handles 'Host endpoint lifecycle only' and enumerates the specific operations (list, open, close). It distinguishes itself from the console tool for serial ports, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: it says when to use profile= (for open) and ep= (for close), and it directly says 'Not for serial ports — use the console tool,' which gives both an exclusion and an alternative.
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 and does disclose important behavior: passwords are not private and must be written inline, and shell-editing config files is forbidden. It also clarifies the relationship between put_profile and put_secret for SSH keys. However, it does not mention return values, persistence, or side effects of operations like delete_profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose and follows with a warning, operation list, and examples. Every sentence adds value, though the examples create a run-on feel; a structured layout would improve scannability.
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 complex tool with 14 parameters, no output schema, and no annotations, the description covers common operations and gives recipes but leaves several parameters undocumented and omits return/error behavior. The 'op=help for recipes' pointer mitigates this, but the agent is still left guessing about body, content, port, and label.
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 several parameters through examples: name, transport, host, username, auth, ssh, winrm, defaults, caps, and key_path (though key_path is not in the schema). However, parameters like body, content, port, and label remain unexplained, and the phantom key_path adds confusion.
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 'Complete self-config for profiles', immediately identifying the tool's purpose as managing profile configuration. It enumerates a clear list of operations (ops) and gives concrete examples, distinguishing itself from sibling tools like exec or endpoint by focusing on profile setup rather than execution or connection.
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 explicit do-not usage ('Do NOT shell-edit config files') and directs to 'op=help for recipes'. It includes concrete recipes for SSH password, SSH key, and WinRM profiles, making it clear when and how to use the 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?
With no annotations provided, the description carries the full burden. It discloses that the tool is an interactive PTY session with a structured lifecycle (open, send, close) and a framing step. However, it omits details on what 'frame' means, error behavior, or authentication requirements, so it is not fully 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 exceptionally concise—two sentences that pack in the operation set, usage pattern, and sibling exclusion without any fluff. 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 an interactive PTY tool with six parameters and no output schema or annotations, the description provides a useful high-level workflow and the key constraint about serial hardware, but lacks details on parameter semantics, expected output, and edge cases. It is moderately complete but leaves significant gaps.
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%, and the description only explains 'ep' and 'op' (the latter with its enum values). It mentions 'actions' in the loop but does not clarify the structure of 'actions', and entirely omits 'id', 'shot', and 'wait'. Thus, it adds some meaning but does not compensate for the lack of parameter descriptions.
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 specifies the tool's resource ('Interactive PTY screen'), the host parameter 'ep=', and the supported operations 'open|send|close|list'. It also distinguishes itself from the sibling 'console' tool by explicitly stating it is not for serial hardware.
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 provides an explicit usage loop ('open → frame → send(actions) → frame → close') and a clear exclusion/alternative ('Not for serial hardware — use the console tool'). This gives strong guidance on when to use this tool versus the 'console' sibling.
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 behavioral disclosure burden. It goes beyond basic invocation by revealing that opening a console starts background capture immediately, that max_lines defaults to a huge buffer, and that view queries operate on the captured buffer rather than driver receive. These are meaningful behavioral traits not derivable from the schema, though it doesn't discuss close/send side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is efficiently organized by operation with semicolon-separated sub-specifications. Every clause provides necessary information for a complex multi-op tool; however, some formatting (e.g., line breaks per op) could improve scanability without adding length.
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 has 16 parameters, no output schema, and multiple operation modes, the description is highly complete: it covers op-specific parameter requirements, default behaviors, and capture semantics. Minor gaps remain around return value shapes, error conditions, and lifecycle side effects, but for the tool's complexity, this is a strong profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description names and contextualizes every parameter: op, path/device, baud, max_lines, id, data/data_b64, newline, mode, n, since, contains, context, settle_ms, with_seq, and sessions. It explains parameter combinations per operation and even specifies value vocabularies like mode=tail|since|contains. This fully compensates for the otherwise opaque 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 clearly identifies the tool as a Serial Console for embedded device links, distinguishing it from PTY/SSH interfaces. It enumerates the specific operations (list, open, send, views, close, sessions) and their scopes, making the purpose unambiguous and differentiating it from sibling tools like 'screen' or 'exec'.
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 operation-specific usage instructions, including which parameters apply to each op and constraints like 'do not scan /dev or drivers' and 'queries capture buffer (not driver recv)'. It lacks explicit 'when to use vs alternatives', but the 'not PTY/SSH' and embedded-device context provide clear situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-remote-control MCP server](https://glama.ai/mcp/servers/shiharuharu/mcp-remote-control/badges/card.svg)](https://glama.ai/mcp/servers/shiharuharu/mcp-remote-control)

Score Badge

Copy to your README.md:

[![mcp-remote-control MCP server](https://glama.ai/mcp/servers/shiharuharu/mcp-remote-control/badges/score.svg)](https://glama.ai/mcp/servers/shiharuharu/mcp-remote-control)

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/shiharuharu/mcp-remote-control'

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