Skip to main content
Glama

host_create

Creates a new SSH host entry, encrypts supplied credentials at rest, and returns public metadata with the uid required to reference it in host listings.

Instructions

Create a new SSH host entry. The supplied password or private key is encrypted at rest and never returned by any tool. The response contains the new host's public metadata, including the uid that identifies it in host_list.

Input Schema

NameRequiredDescriptionDefault
ssh_portNoSSH port, default 22.
is_enableNoWhether SSH tools can target this host. Default true.
ip_addressYesUnique IP address or hostname of the host.
system_nameNoHuman-readable name (e.g. 'web-01').
ssh_passwordNoPlaintext password (encrypted at rest). Required when auth_method=password.
ssh_usernameNoSSH username, default 'root'.
ssh_auth_methodNo'password' (default) or 'pubkey'.
ssh_private_keyNoPlaintext private key (encrypted at rest). Required when auth_method=pubkey.
ssh_private_key_passphraseNoPassphrase protecting the private key (encrypted at rest). Only used with auth_method=pubkey.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden well by disclosing that passwords/private keys are encrypted at rest and never returned by any tool. It also states that the response contains public metadata including the uid, though it does not cover permissions, duplicate-IP behavior, or idempotency.

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, front-loaded with the core action, followed by security behavior and response identity. Every sentence adds useful information without repetition or waste.

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 create mutation with no annotations and no output schema, the description covers the action, sensitive-data handling, and the key returned identifier. It could say more about prerequisites or duplicate handling, but the detailed schema compensates for most field-level gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all nine parameters in detail. The description reinforces secret-handling semantics for password/private key fields but does not add parameter-level guidance beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Create a new SSH host entry." It also references `host_list` for the uid, helping distinguish the created host from listing behavior.

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?

Usage is implied by "Create a new SSH host entry," but the description does not explicitly say when to use this versus `host_update`, `host_delete`, or other sibling tools. The `host_list` reference explains the returned uid but not tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.