Host Terminal MCP

by ankitaa186

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 has a clearly distinct purpose with no overlap. approve_command handles permissions, change_directory and get_current_directory manage directories, execute_command runs commands, and get_permission_status and set_permission_mode control permission settings. The descriptions clearly differentiate their functions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., approve_command, change_directory, execute_command). The naming is uniform across all six tools, using snake_case throughout without any deviations or mixed conventions.
Tool Count5/5
With 6 tools, this is well-scoped for a terminal management server. Each tool serves a specific, necessary function in the domain of executing commands and managing permissions, with no redundant or missing tools that would suggest an inappropriate count.
Completeness5/5
The tool set provides complete coverage for terminal operations and permission management. It includes command execution, directory navigation, permission status checks, and mode settings, with no obvious gaps. The domain is fully covered, allowing agents to handle all core workflows without dead ends.
Average 3.7/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 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 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 provided, the description carries full burden for behavioral disclosure. It states the tool changes the directory 'for subsequent commands', which implies state mutation, but doesn't address permissions needed, error conditions (e.g., invalid paths), or whether the change persists. This leaves significant gaps for a mutation tool.
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, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it highly concise and well-structured for quick comprehension.
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 moderate complexity (state-changing with one parameter) and lack of annotations or output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavior, errors, or integration with siblings, leaving room for improvement in completeness.
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 description adds no parameter-specific information beyond what's in the schema, which has 100% coverage and fully documents the 'path' parameter. This meets the baseline of 3, as the schema adequately handles parameter semantics without requiring description compensation.
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's purpose with a specific verb ('change') and resource ('current working directory'), making it immediately understandable. It doesn't explicitly distinguish from sibling tools like 'get_current_directory', but the verb 'change' versus 'get' provides implicit 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_current_directory' or 'execute_command'. It mentions 'for subsequent commands' which hints at context, but offers no explicit when/when-not rules or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get') but doesn't specify whether it requires permissions, returns a specific format, or has any side effects. The description is minimal but accurate for a simple query tool, though more context would be helpful.
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, clear sentence with no wasted words. It is front-loaded and efficiently communicates the core function, making it easy for an agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It states what the tool does but lacks details on return values or behavioral context, which could be useful for integration. It meets the minimum viable threshold for such a straightforward tool.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline expectation for a parameterless tool. No additional semantic value is required or provided.
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's purpose with a specific verb ('Get') and resource ('current working directory'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'change_directory' or 'execute_command', which prevents a perfect score.
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 alternatives like 'change_directory' or 'execute_command'. It lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read-only informational tool (consistent with 'get' terminology), but doesn't specify authentication requirements, rate limits, error conditions, or what the output format looks like. The description adds basic context about what information is retrieved but lacks detailed 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, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized for a simple informational tool and front-loads the essential information. 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 informational tool with one optional parameter and no output schema, the description provides adequate context about what information is retrieved. However, without annotations or output schema, it doesn't specify the response format or structure, leaving some ambiguity about what exactly will be returned. The description is complete enough for basic understanding but could be more comprehensive.
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 100% description coverage, with the single parameter 'show_all_allowed' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides, so it meets the baseline expectation when schema coverage is complete.
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's purpose with a specific verb ('Get') and resource ('information about the current permission mode and allowed commands'). It distinguishes itself from siblings like 'set_permission_mode' (which modifies permissions) and 'execute_command' (which runs commands). However, it doesn't explicitly differentiate from all siblings (e.g., 'get_current_directory' is also informational).
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 when needing to check permission status, but doesn't explicitly state when to use this tool versus alternatives like 'approve_command' or 'set_permission_mode'. No guidance is provided on prerequisites or exclusions, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond what the input schema offers by explaining permission controls based on configuration, default allowances for read-only commands, and guidance on using 'cd'. However, it lacks details on potential side effects (e.g., destructive commands), error handling, or output format, which are important for a command execution tool.
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 front-loaded with the core purpose, followed by essential usage notes in three concise sentences. Each sentence earns its place by addressing key aspects: execution context, permission controls, allowed commands, and handling of 'cd'. There is no redundant or verbose language, making it highly efficient.
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 complexity of executing terminal commands (which can have security and side-effect implications), no annotations, and no output schema, the description is moderately complete. It covers purpose, basic usage, and permissions but lacks details on output structure, error cases, or advanced behavioral traits. This leaves gaps for an AI agent to fully understand the tool's behavior in practice.
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 100% description coverage, providing clear documentation for both parameters. The description adds minimal value beyond the schema by implying that 'working_directory' can be used as an alternative to 'cd', but it does not elaborate on parameter interactions, constraints, or examples. Baseline 3 is appropriate since the schema handles most of the parameter semantics.
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 specific action ('execute a terminal command') and resource ('on the host machine'), distinguishing it from siblings like 'approve_command' (which suggests a permission step) or 'change_directory' (which focuses on navigation). It provides a concrete verb+resource combination that leaves no ambiguity about the tool's core function.
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 offers clear context for usage by mentioning that 'read-only commands like ls, cat, git status are generally allowed by default' and advises on handling 'cd' via a separate command or the working_directory parameter. However, it does not explicitly state when to use this tool versus alternatives like 'approve_command' or 'change_directory', nor does it provide exclusions or prerequisites beyond the implied permission controls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool does (changes permission modes) and provides caution about 'allow_all', but doesn't disclose important behavioral aspects like whether this requires admin privileges, if changes are immediately effective, what happens to pending commands during mode transition, or error conditions. The description adds value but leaves significant behavioral 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 perfectly front-loaded with the core purpose in the first sentence, followed by specific mode explanations. Every sentence earns its place by providing essential information about the three modes and their implications. No wasted words or redundant information.
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 a mutation tool with no annotations and no output schema, the description should do more to explain behavioral implications, error conditions, and system impact. While it adequately explains what the tool does and what the modes mean, it lacks information about permissions required, immediate vs delayed effects, and what the tool returns. The description is complete enough for basic understanding but insufficient for safe, informed use.
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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining what each mode value means ('allowlist' = only allow listed commands, 'ask' = prompt for unlisted commands, 'allow_all' = allow all commands), which provides semantic understanding beyond the schema's enum listing. However, it doesn't mention the 'persist' parameter at all, leaving that detail solely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Change the permission mode') and resource ('permission mode'), with explicit enumeration of the three possible modes. It distinguishes this tool from sibling tools like 'get_permission_status' (which reads rather than changes) and 'approve_command' (which handles individual commands rather than system-wide modes).
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 about when to use each mode ('allowlist' for only listed commands, 'ask' for prompting, 'allow_all' for allowing all commands), including a caution for 'allow_all'. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'approve_command' for individual command approvals or 'get_permission_status' for checking current mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool is for approving/denying commands, it's session-specific ('for this session only'), and it operates under specific conditions. However, it lacks details on error handling, response format, or side effects, which are important for a mutation tool.
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 front-loaded with the core purpose in the first sentence, followed by usage context and behavioral detail. Every sentence adds value without redundancy, making it efficient and well-structured for an AI agent.
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 moderate complexity (mutation with 2 parameters) and no annotations or output schema, the description is fairly complete. It covers purpose, usage conditions, and session-limited behavior, but lacks details on return values or error cases, which could be helpful for full transparency.
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 100%, so the schema already documents both parameters (command and approve). The description adds context by explaining that 'command' is 'the exact command to approve' and implies 'approve' controls approval/denial, but this doesn't significantly enhance the schema's information. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('approve a command') and the resource ('command that requires permission'), distinguishing it from siblings like execute_command or set_permission_mode. It explicitly mentions the condition 'when permission_mode is 'ask' and a command is not in the allow list,' which adds precision.
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 states when to use this tool: 'when permission_mode is 'ask' and a command is not in the allow list.' It implies alternatives by referencing the allow list and permission_mode, though it doesn't name specific sibling tools like set_permission_mode. This provides clear contextual 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:

[![host-terminal-mcp MCP server](https://glama.ai/mcp/servers/ankitaa186/host-terminal-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ankitaa186/host-terminal-mcp)

Score Badge

Copy to your README.md:

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

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