Skip to main content
Glama

sylve_jail_template

Destructive

List, show, capture, deploy, or delete jail templates across a Sylve cluster or target node to manage reusable jail configurations.

Instructions

List, show, capture, deploy, or delete jail templates.

Input Schema

NameRequiredDescriptionDefault
jailNoSource jail (capture).
nameNoTemplate name (capture).
nodeNoTarget cluster node hostname or UUID. Omit for cluster-wide.
countNo
actionYes
contextNoNamed login context from ~/.config/sylve/config.yaml.
template_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, but because five actions with very different risk profiles are bundled, the description should say that 'delete' is the destructive path and that 'list'/'show' are safe reads. It says none of that, nor does it note permissions or that delete removes the template from the cluster.

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?

A single compact sentence with no filler, action verbs front-loaded and easy to scan. It is efficient, though its brevity comes at the cost of the conditional detail this five-action tool requires.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter, five-action, destructive, non-idempotent tool with no output schema, the description leaves the entire action-parameter contract and the read/write risk split unstated. An agent could plausibly invoke 'delete' with only template_id or 'capture' without a source jail and have no warning.

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 57%, with count, template_id, and the action enum undocumented in both places. More critically, the description never maps parameters to actions (jail/name for capture, template_id/count for deploy, template_id for delete), which is the key semantic the agent needs and the schema does not provide.

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?

States specific verbs (list, show, capture, deploy, delete) against a specific resource (jail templates), so the agent knows the domain and the action surface. It does not differentiate this multi-action tool from siblings like sylve_jail_list, sylve_jail_show, or sylve_vm_template, leaving overlap to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this consolidated tool versus the per-action siblings (sylve_jail_list, sylve_jail_show, sylve_jail_delete, sylve_vm_template). The description merely enumerates actions already in the enum; there are no preconditions, no exclusions, and no routing logic.

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