infrabroker

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v3.1.2
Disambiguation5/5
Each tool targets a distinct operation: single command execution, session-based execution, session lifecycle, file transfer, and host discovery. The descriptions explicitly guide tool selection, e.g., preferring ssh_execute for isolated commands and ssh_session_open for stateful sessions, leaving no ambiguity.
Naming Consistency3/5
Naming is mixed: ssh_get_file, ssh_put_file, and ssh_list_servers follow a verb_noun pattern, while ssh_session_open, ssh_session_exec, and ssh_session_close reverse the order to noun_verb. ssh_execute also lacks a noun. The prefix is consistent and readable, but the conventions are not uniform.
Tool Count5/5
Seven tools is ideal for an SSH broker: host discovery, single command execution, file transfer (get/put), and persistent session management (open/exec/close). Each tool serves a clear purpose without unnecessary overlap or bloat.
Completeness5/5
The surface covers the full remote-administration lifecycle: list hosts, run commands directly or via sessions, transfer files in both directions, and manage session resources. No critical operations are missing for the stated domain.
Average 4.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 357 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that an unclosed session keeps its SSH connection until reaped by certificate expiry or idle/max-lifetime timeout, adding valuable lifecycle context. It does not detail idempotency or error handling, but the core behavior is well covered.
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: the first states the action directly, the second provides rationale and consequences. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple close operation with a well-documented parameter and an output schema, the description covers the purpose, when to use it, and the behavior of not using it. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (session_id with 'id of the session to close'), so the description adds no additional parameter detail. Schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Close a persistent SSH session and release the connection'), clearly stating what the tool does. It distinguishes itself from sibling tools like ssh_session_open and ssh_execute by focusing on the close operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Always call when done working with a session' and explains the consequences of not closing (connection remains until cert expiry or timeout), providing strong contextual guidance. It does not offer explicit exclusions or compare with alternatives, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnlyHint: base64 fallback for non-UTF-8, max_bytes error (not truncation), ephemeral credential, sha256 audit log entry, and no sudo. This fully discloses edge cases and operational implications.
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 information-dense and front-loaded with the primary purpose, followed by critical constraints and behavioral details. Every sentence adds value; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (host prerequisites, output encoding, size limits, audit logging), the description covers all essential aspects: prerequisites, error conditions, output format, permissions, and audit. An output schema exists, so return-value details are unnecessary.
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 already covers all parameters with descriptions (100% coverage), including the max_bytes error behavior. The description reiterates the default and error semantics but does not add new parameter-level meaning beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read a file from a Linux host via SSH with an ephemeral credential,' which is a specific verb+resource. It clearly distinguishes from sibling tools like ssh_put_file (write) and ssh_execute (execute commands) by focusing on reading file content.
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 provides explicit usage conditions: REQUIRES allow_file_transfer=true and 'if false DO NOT retry.' It also mentions 'see ssh_list_servers' for checking and clarifies the read runs as the configured user with no sudo. However, it does not explicitly name alternative tools for file-reading vs command execution, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds extensive context: overwrite behavior, no sudo, execution as configured user, command policy restrictions, size limit, and audit logging. It fully discloses side effects and constraints beyond what annotations provide.
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 paragraph with every sentence providing essential information: overwrite behavior, binary handling, host requirement, permission constraints, policy checks, size limit, and audit. Length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, permission model, policy constraints, size limits, and audit side effects. It fully contextualizes the tool's behavior, and with an output schema present, return value details are not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described clearly. The description reinforces the content_base64 semantics and mentions the size limit affecting content, but does not add substantial new meaning beyond 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 tool's function: writing a file to a Linux host via SSH with an ephemeral credential. It explicitly mentions creates/overwrites behavior and is distinct from siblings like ssh_get_file (reading) and ssh_execute (running commands).
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?
Provides explicit prerequisites (allow_file_transfer=true, command policy, writable destination, size limit) and instructs not to retry if the flag is false. It references ssh_list_servers for verification but does not explicitly contrast with alternatives like ssh_get_file for the reverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds substantial behavioral context beyond that: RBAC filtering, per-host capability fields, and specific failure expectations ('the signer will reject it'). It could further explain response behavior when no hosts are listed, but the provided detail is strong.
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 appropriately sized for the tool's complexity, is front-loaded with the primary purpose, and each field explanation earns its place by providing actionable guidance. No wasted words or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the annotations and the presence of an output schema, the description fully covers the tool's role, its relationship to sibling tools, RBAC privacy implications, and capability-dependent behavior. An agent can safely invoke this tool and correctly interpret results without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter meaning; instead, it thoroughly explains the output fields, which is the relevant semantic content for this zero-input tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the hosts accessible to the caller with their capabilities.' It also clarifies scope ('hosts outside the user's RBAC groups are not listed') and distinguishes itself from sibling tools by being a preflight discovery tool, not an execution or file-transfer tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'ALWAYS call before ssh_execute or ssh_session_open,' establishing when to use this tool. It also provides conditional guidance on when to avoid certain operations based on capabilities (e.g., 'allow_sudo=false → DO NOT attempt sudo'), which helps the agent avoid errors when using sibling tools.
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 annotations indicating destructiveHint=true and readOnlyHint=false, the description adds substantial context beyond this: it clarifies exit_code semantics (remote failure vs tool error), policy preflight behavior, audit-mode warnings, and that session state persists. It also warns that later commands are rejected if policy changes after session open. This fully discloses behavioral traits without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose and output. Subsequent sentences pack essential behavioral details without fluff. Every sentence provides unique value, making it appropriately sized for the complexity.
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?
Given the tool's complexity (policy preflight, state persistence, exit code semantics) and the existence of an output schema, the description is remarkably complete. It covers the purpose, return values, error semantics, policy interactions, and state behavior, leaving no major gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described: command and session_id). The description adds meaning by explaining that session_id comes from ssh_session_open, clarifying session state persistence, and mentioning mode implications. This goes beyond the schema descriptions, though not dramatically, so a 4 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 tool's function: 'Execute a command in a session opened with ssh_session_open.' This specific verb+resource combination distinguishes it from siblings like ssh_execute (standalone execution) and ssh_session_open (session creation). The name itself reinforces this purpose.
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 establishes clear usage context: it requires an existing session from ssh_session_open, implying it is not for standalone commands. It also mentions persistent session state for mode=shell or mode=pty, which helps differentiate from one-shot alternatives, though it does not explicitly name alternatives or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses session reuse, mode distinctions (exec/shell/pty), sudo behavior per mode, policy preflighting for open sessions, session closure and lifecycle timeouts, and the explicit need to close the session. This is comprehensive.
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 dense but every sentence contributes unique information. It front-loads the core purpose, then layered constraints, and ends with a critical closing instruction. No fluff; each clause earns its place given the complexity.
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?
Given the tool's complexity (persistent sessions, multiple modes, policy checks, lifecycle), the description covers all essential aspects: when to use, mode differences, sudo/pty prerequisites, policy revalidation, return value (session_id), and closing requirement. The output schema exists, so return value details are adequately handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed parameter descriptions, so baseline is 3. The description adds value by explaining mode semantics (state persistence, TTY for interactive programs) and sudo elevation behavior per mode, plus constraints tied to allow_sudo/allow_pty, which enriches the schema's meaning.
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 opens a persistent SSH session that reuses connections, with specific use cases for shared state or interactive programs. It explicitly distinguishes from the sibling ssh_execute by recommending it for isolated commands, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: multiple commands with shared state (e.g., cd then operate) or interactive programs. It names the alternative (ssh_execute) and explains why to prefer it for isolated commands, and also covers constraints like sudo and pty prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), description discloses ephemeral credential behavior, exit_code semantics, pty stdout/stderr merging, sudo/pty preconditions, and ttl_seconds default. No contradiction with annotations; significant added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose. Every sentence earns its place—there is no filler. Short imperative warnings ('DO NOT retry') and clear separation of concerns make it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 params and an output schema, but the description still covers key contextual aspects: purpose, preference over sibling, return values, exit_code interpretation, prerequisites, safety constraints, and parameter defaults. It is fully self-sufficient for an agent to invoke correctly.
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?
Schema covers all 7 parameters with descriptions, but the tool description adds vital operational semantics: sudo requires allow_sudo=true and 'DO NOT retry' if false, pty requires allow_pty=true, and ttl_seconds is optional with max-allowed default. These go beyond the schema's base 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 states 'Execute a single command on a Linux host via SSH with an ephemeral credential'—a specific verb, resource, and mode. It further distinguishes itself from sibling ssh_session_open by advising preference for single or independent commands.
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?
Explicitly tells when to use this tool vs ssh_session_open, requires calling ssh_list_servers before use, and gives conditional rules for sudo and pty with clear 'do not retry if not allowed' instructions. It also clarifies that non-zero exit_code means remote failure not a tool error.
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:

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

Score Badge

Copy to your README.md:

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

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/luisgf/infrabroker'

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