PiloTY

by yiwenlu66

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: session lifecycle, input methods (line, text, control, password, signal), output retrieval (snapshots, transcript), and waiting mechanisms (output, regex, prompt). No overlap or ambiguity.
Naming Consistency5/5
All tools use a consistent verb_noun snake_case pattern (e.g., create_session, send_line, wait_for_shell_prompt). No mixing of conventions.
Tool Count5/5
17 tools are well-scoped for a PTY management server, covering all necessary interactions without bloat. Each tool serves a distinct, necessary function.
Completeness5/5
The tool set covers session lifecycle, multiple input modes, output retrieval, and waiting for various states. It includes password handling and signal sending, appearing complete for typical terminal interaction use cases.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get the transcript file path', without disclosing if it's read-only, side effects, or behavior for missing sessions. Minimal transparency for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), making it concise, but it lacks structure (no headers, bullets) and misses important details that could be added without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and an undescribed parameter, the description is severely incomplete. It doesn't explain what the transcript file path is, its format, or potential errors, leaving the agent without enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'session_id' has no description in the schema (0% coverage), and the description does not add any information beyond the parameter name. It mentions 'this session' but doesn't link it to the parameter.
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 verb 'Get' and the resource 'transcript file path', specifying it's for 'this session'. This distinguishes it from sibling tools like snapshot_screen or snapshot_scrollback, but lacks specificity about the session context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contraindications. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the rejection of future calls with the same session_id, but does not explain permissions, reversibility, or cleanup. This is minimal transparency for a destructive action.
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 consists of two concise sentences, front-loading the core action and a key consequence. No extraneous words; every sentence 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 tool with one input parameter and no output schema, the description covers the essential action and a behavioral outcome. However, it lacks information about return values, error handling, or side effects, making it adequate but not comprehensive.
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% for the only parameter. The description mentions session_id in context but adds no additional meaning beyond the schema, such as format or validation rules.
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 verb 'Terminate' and the resource 'PTY session'. It distinguishes the tool from siblings like 'create_session' and 'list_sessions' by specifying its termination action.
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 implies when to use (to end a session) but lacks explicit guidance on when not to use or alternatives. It mentions that future calls with the same session_id are rejected, which is a consequence but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the action (clearing scrollback) and a prerequisite but does not disclose side effects, irreversibility, impact on other sessions, or performance implications. The description is minimal and leaves important behavioral aspects unaddressed.
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 extremely concise: two sentences totaling 16 words. The first sentence front-loads the primary action, and the second sentence adds necessary prerequisite. No wasted words.
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 it is a simple tool with one parameter and no output schema, the description covers the basic action and prerequisite. However, it omits details like irreversibility, confirmation of success, or error conditions. It is minimally complete for the tool's simplicity but has room for improvement.
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 adds context that 'session_id' must be from a session created via create_session(session_id, cwd). This gives meaning beyond the bare schema, but it does not explain the format or constraints of session_id. The addition is helpful but 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 clearly states the tool's purpose: 'Clear rendered scrollback history while preserving current screen.' This is a specific verb ('Clear') and resource ('rendered scrollback history'), and it distinguishes itself from sibling tools like snapshot_scrollback (which retrieves scrollback) and snapshot_screen (which captures screen).
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 mentions a prerequisite ('Requires an existing session created via create_session(session_id, cwd)') but provides no guidance on when to use this tool versus alternatives. For example, it does not contrast with snapshot_scrollback (for reading scrollback) or send_control (which might clear the screen). No when-not-to-use information is given.
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 labels the tool as a read operation ('Get'), implying no destructive side effects. Since annotations are absent, this is sufficient. However, it lacks further details like what metadata is returned or any security considerations.
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 long, wastes no words, and front-loads the core action. Every sentence serves a clear purpose.
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 (one parameter, no output schema, no annotations), the description covers the basic purpose and a prerequisite. However, it omits details about the return value (what metadata is included), which is important for an agent to understand the tool's output.
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 coverage, the description fails to add meaning to the session_id parameter beyond restating its name. The prerequisite mentions it's created via create_session, but the parameter's format, source, or validation rules are not explained, leaving the agent to infer.
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 it retrieves metadata for an existing PTY session, specifying the verb 'Get' and the resource. While it distinguishes itself from sibling tools like send_text or snapshot, it does not explicitly differentiate from other read-oriented siblings like transcript or snapshot_screen.
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 provides a prerequisite (existing session via create_session), which is helpful guidance. However, it does not offer any context on when to use this tool versus alternatives, such as when to choose get_metadata over snapshot_screen or transcript for reading session data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not describe what happens if the session does not exist, invalid signals, return values, or side effects beyond sending the signal. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and prerequisite. No unnecessary words, though a bit more detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and low schema coverage, the description should provide more context on valid signals, defaults, and expected behavior. It falls short, leaving gaps for the agent.
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 coverage is only 33% (only deadline_s has a description). The description adds no meaning for session_id or signal, leaving the agent to guess valid signal names or formatting.
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 verb 'Send', the resource 'OS signal', and the target 'foreground process in a session'. This distinguishes it from sibling tools like send_control or send_text that deal with input.
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 requires an existing session created via create_session with specific arguments. It does not provide when-not-to-use or alternatives, but the context of signaling vs input is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: passive snapshot, no ingestion of new PTY bytes, and requirement for a session. It does not mention what happens if the session_id is invalid, any limits on scrollback size, or the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. First sentence gives the main action, second provides prerequisite, third clarifies behavior. No 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 no annotations, no output schema, and missing parameter details, the description is incomplete. It covers precondition and passiveness but lacks explanation of output shape and parameter semantics. Sibling tools like snapshot_screen are not differentiated beyond the passive note.
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 descriptions are missing (0% coverage). The description explains session_id's role indirectly but fails to explain the 'lines' parameter, which controls how many lines are returned. The default of 200 is not mentioned in the description.
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 retrieves 'rendered terminal scrollback,' a specific resource. It distinguishes itself from siblings like snapshot_screen (current screen) and clear_scrollback (destructive) by noting it is a passive snapshot.
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?
Explicitly states the precondition: 'Requires an existing session created via create_session(session_id, cwd).' It also notes the tool is passive and does not ingest new bytes, implying safe use. However, no explicit guidance on when not to use or alternatives.
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, description bears full burden. It discloses that after sending line + '\n', the tool drains PTY bytes until quiescence or deadline. It also specifies deadline_s maximum of 300 seconds. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (approximately 150 words) and well-structured: action, prerequisite, behavior, constraint, example pattern. No superfluous 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 3 parameters and no output schema or annotations, the description covers behavior well but lacks explanation of return values or error conditions. For a tool that drains bytes, it's plausible but incomplete.
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 low (33%). The description adds meaning for 'line' (sent with newline) and 'deadline_s' (max 300, total budget). However, it does not fully compensate for all parameters; session_id is just a required field. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send one newline-terminated line to a stateful PTY session.' It specifies the verb 'send', resource 'line', and context 'stateful PTY session', distinguishing it from siblings like send_text or send_control.
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?
Explicitly states prerequisite: 'Requires an existing session created via create_session(session_id, cwd).' Provides a common SSH pattern as usage example, aiding when to use. Does not explicitly state when not to use, but pattern implies context.
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 fully bears the burden of disclosing behavior. It explains the waiting mechanism (drains until silent or deadline), mentions the quiescence timeout (PILOTY_QUIESCENCE_MS default 1000ms), and describes the outcome when deadline expires (partial output with 'outcome=deadline_exceeded'). This is good transparency, though it could mention error cases or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core purpose, followed by prerequisites (session requirement) and detailed behavior. Every sentence adds necessary information without redundancy.
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 no output schema, the description hints at the return format only by mentioning 'outcome=deadline_exceeded'. It does not describe other possible outcomes or the structure of captured output. It differentiates from one sibling but not all relevant ones (e.g., wait_for_regex). The tool is moderately complete but has 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 coverage is 50%, so the description should compensate. It adds meaning for deadline_s by noting the max of 300 seconds and the quiescence context. However, it does not elaborate on session_id and leaves some param details to the schema. The added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait for newly arriving PTY output without sending input.' It specifies the resource (PTY output) and the action (waiting), and distinguishes itself from sibling tools like wait_for_shell_prompt by noting that it waits for any new output, not specifically a prompt.
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 context on when to use the tool: after creating a session, and when waiting for output. It explicitly mentions an alternative: 'If you need to wait specifically for a shell prompt, use wait_for_shell_prompt().' However, it does not cover when not to use it or differentiate from wait_for_regex.
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 discloses key behaviors: it checks scrollback first then waits on new output, and deadline_s is capped at 300s. It lacks detail on timeout behavior but is mostly 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 concise with 4 clear sentences, no redundant information, and well-structured.
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?
While it explains the process well, it omits what the tool returns (e.g., match details or timeout error) and doesn't fully compensate for the lack of output schema.
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 only 33% (only deadline_s has a description). The description adds context about the overall operation but doesn't explain the pattern parameter's syntax or session_id usage beyond what's in 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 it waits for a regex match in rendered text and/or PTY bytes, distinguishing it from siblings like wait_for_output or wait_for_shell_prompt.
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 specifies prerequisite of an existing session and explains the order of checking scrollback then waiting. However, it doesn't explicitly contrast with alternatives or state when not to use.
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 full burden. It discloses that the 'description' parameter does not affect execution, which is transparent. However, it does not mention potential side effects (e.g., overriding existing sessions), required permissions, or error handling. For a tool that creates resources, some behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a short opening sentence followed by bullet-like parameter explanations. Each word adds value. It is front-loaded with the core purpose. No unnecessary repetition or verbose phrasing.
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 creation tool with no output schema and no annotations, the description covers the purpose, parameter meanings, and a usage rationale. It does not describe return values or possible errors, but given the tool's simplicity, it is largely complete for an agent to use correctly.
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 description coverage is only 33% (only the 'description' parameter has a schema description). The tool description adds meaningful semantics for all three parameters: 'session_id' as a stable identifier, 'cwd' as the working directory, and reiterates that 'description' is free-form. This compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a PTY session with an explicit working directory.' The verb 'create' and resource 'PTY session' are specific. It distinguishes from siblings which handle other session operations like clearing, configuring, or sending text.
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 explains why the 'cwd' parameter is required due to MCP lacking a standard field for the client's current working directory. This provides context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools for related tasks.
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?
In the absence of annotations, the description discloses key behavioral traits: it drains PTY bytes until quiescence or deadline, and specifies the default quiescence timeout and deadline_s maximum. This goes beyond a simple 'send' action, though it could mention potential error cases.
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 extremely concise with three sentences: primary action, prerequisite, and behavioral detail. Every sentence adds unique information, and the structure is logical and front-loaded.
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 tool with no output schema, the description covers the main action, prerequisites, and behavioral details. It lacks explicit mention of return values or error handling, but the core functionality is well described.
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 low (33%), but the description adds value for 'text' (raw, no newline) and explains how deadline_s is used. However, it does not describe the session_id parameter beyond the prerequisite, leaving some meaning to be inferred.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'send raw text', the resource 'stateful PTY session', and a key distinction 'without adding a newline', which differentiates it from sibling tools like send_line (which likely adds a newline).
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 notes the prerequisite of an existing session via create_session(), and describes the behavior after sending (draining until silence or deadline). It does not explicitly state when not to use or alternatives, but the context is clear enough for an AI agent to infer appropriate usage.
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 provides important context: it is a 'passive snapshot' and 'does not ingest new PTY bytes'. This clarifies it's a read-only operation without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: main action, prerequisite, behavioral note. No unnecessary words.
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?
Covers purpose, prerequisite, and behavior. Lacks information about the return format (e.g., plain text or structured data), but since there is no output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that `session_id` must belong to an existing session from `create_session`, adding context beyond the schema's title and required flag. But no format or validation details.
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 verb 'Get' and resource 'current VT100-rendered terminal screen snapshot'. It distinguishes from siblings like `snapshot_scrollback` by specifying 'screen' vs scrollback.
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?
Explicitly requires an existing session via `create_session(session_id, cwd)`. However, does not explicitly compare with siblings like `snapshot_scrollback` or `transcript`.
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 discloses key behaviors: it repeatedly ingests PTY output and re-runs prompt detection until deadline_s expires, and returns consumed output. It also notes the deadline_s maximum. This provides good transparency, though it could mention idempotency or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with 5 sentences covering purpose, prerequisites, behavior, customization, and constraints. No redundant information; every sentence adds value.
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 wait tool with two parameters and no output schema, the description adequately covers core behavior, prerequisites, customization, and output format ('Any output consumed... is returned in output'). It lacks detail on return value structure but is sufficient for use.
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 schema describes deadline_s with bounds and default, and session_id is required. The description adds context about deadline_s's maximum (already in schema) and mentions configure_session for prompt customization, which is not a parameter. It doesn't add significant meaning beyond schema, and schema coverage is 50%.
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 'wait' and resource 'shell prompt', clearly stating the tool's purpose. It distinguishes from siblings like wait_for_output and wait_for_regex by specifying it waits for a shell prompt exclusively, and mentions prerequisites and customization.
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 states the prerequisite of an existing session created via create_session, and advises how to handle custom prompts via configure_session. It provides clear context for when to use this tool, though it doesn't explicitly mention when not to use it.
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?
Discloses that description is free-form and does not affect execution, and explains how shell_prompt_regex is used. However, with no annotations, it lacks details on whether updates overwrite or merge existing settings.
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?
Well-structured with main purpose first, then parameter details. Some redundancy about 'description' but overall efficient.
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?
Covers key aspects: function, parameter usage, and pre-creation capability. Lacks mention of return value or error states, but acceptable given it's a configuration 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?
Adds meaning beyond schema for description and shell_prompt_regex (e.g., regex matched against last visible line). Does not explain session_id parameter, which is required and undocumented in 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?
Clearly states it updates session metadata and shell prompt detection. Distinguishes from sibling tools which focus on input, output, and session lifecycle.
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?
Explains it can be called before a session exists and that values are applied on creation. Provides context but does not explicitly mention alternatives or when not to use.
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 fully covers behavioral details: it explains the draining of PTY bytes until quiescence or deadline expiry, and specifies defaults for quiescence timeout and deadline limit. It could mention error handling or return behavior, but overall 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 concise and well-structured: a brief opening, bullet-point key list, and a paragraph on draining. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers sending, draining, and timeout. It lacks explicit mention of return output or error conditions (e.g., invalid key), but overall sufficient for agent invocation.
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 description coverage is only 33% (only deadline_s documented). The description compensates by enumerating valid key values and their meanings, and clarifying session_id as required from an existing session. deadline_s is elaborated with context about draining.
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 'Send a control character to the terminal,' specifying the verb and resource. It lists the supported keys (c, d, z, l, [, escape) and their effects, distinguishing this tool from siblings like send_text, send_line, etc.
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 requires an existing session via create_session, and constrains deadline_s to at most 300 seconds. While it doesn't explicitly list alternatives or when-not-to-use, the context and sibling tool names imply that this is for control characters only.
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?
With no annotations provided, the description carries the full burden. It thoroughly explains behavioral traits: forces terminal echo off, disables transcript logging, returns PTY bytes with password redaction, waits for quiescence or deadline expiry. No contradictions or omissions.
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-organized with sections, but the security model block is somewhat lengthy. However, every sentence adds value, and the structure aids readability for an AI agent.
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?
Despite no output schema, the description fully explains return behavior (redacted PTY bytes with prefix). It covers preconditions, constraints (deadline_s maximum 300s), and detailed security measures. No gaps remain for an AI agent to invoke this tool correctly.
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 description coverage is 33% (only deadline_s described). The description adds meaning: explains password and session_id by context, details deadline_s constraints and behavior, and the overall purpose of each parameter. This compensates for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send a password plus newline.' It further elaborates on the specific security-focused behavior (echo off, log off), distinctly differentiating it from siblings like send_text and send_line which lack these security measures.
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 specifies the prerequisite: 'Requires an existing session created via create_session(session_id, cwd).' It also implies usage context (password entry) and constrains deadline_s. However, it does not explicitly state when not to use or provide alternatives, though the security model strongly suggests it's for sensitive input only.
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:

[![PiloTY MCP server](https://glama.ai/mcp/servers/yiwenlu66/PiloTY/badges/card.svg)](https://glama.ai/mcp/servers/yiwenlu66/PiloTY)

Score Badge

Copy to your README.md:

[![PiloTY MCP server](https://glama.ai/mcp/servers/yiwenlu66/PiloTY/badges/score.svg)](https://glama.ai/mcp/servers/yiwenlu66/PiloTY)

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/yiwenlu66/PiloTY'

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