Skip to main content
Glama
Sign In
Helios

Helios

by brazaoo4
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_client_setup_bundle

Read-onlyIdempotent

Generate client onboarding configs and directives to install, reconfigure, switch roles, or uninstall Helios on local AI tools while preserving custom rules.

Instructions

Generate read-only client onboarding configs, idempotent global agent directives (), and /remember skill files for local AI tools. Supports full client lifecycle management via action: 'install_or_update' outputs non-destructive MCP and directive snippets tailored to client, os_platform, and instance_role ('workstation' vs headless 'server-cli'); 'switch_role' updates role-specific rules; 'uninstall' provides surgical removal instructions that preserve user custom rules. Use get_client_setup_bundle to install, reconfigure, or uninstall Helios on a client machine; use manage_server_config to modify server-side settings, or export_bundle to back up the database.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_client_setup_bundle"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionNoLifecycle action: 'install_or_update' (idempotently set or refresh client config and directive blocks), 'switch_role' (change machine role between 'workstation' and 'server-cli'), or 'uninstall' (instructions to cleanly remove Helios from MCP config, strip the HELIOS marker block, and remove the /remember skill).install_or_update
clientNoTarget client environment to configure.all
os_platformNoTarget operating system for config file paths.auto
instance_roleNoRole of this machine ('workstation' for IDE/laptop or 'server-cli' for headless host with strict log-truncation rules).workstation

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.3

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description's main added value is explaining what is produced: configs, directive snippets, role-specific rules, and uninstall instructions that preserve user custom rules. It is mostly clear that the tool generates artifacts/instructions rather than applying changes, though the phrase 'switch_role updates role-specific rules' could be read slightly more ambiguously.

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 front-loaded and organized around outputs, lifecycle actions, and alternatives. It is efficient overall, though the second sentence is dense and packs several action semantics into one semicolon-separated construction.

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?

With an output schema and rich annotations already present, the description still provides the needed context about outputs, lifecycle actions, role targeting, and sibling alternatives. Nothing essential for correct tool selection or invocation appears missing.

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%, so the enum descriptions already carry most parameter meaning. The description adds useful context by explaining that outputs are tailored to client, os_platform, and instance_role, including the workstation versus headless server-cli distinction.

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 concrete resources: generating read-only client onboarding configs, agent directive blocks, and /remember skill files. It also distinguishes the tool from siblings by naming manage_server_config and export_bundle with their respective purposes.

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 says to use this tool to install, reconfigure, or uninstall Helios on a client machine, and it names alternatives: manage_server_config for server-side settings and export_bundle for database backup. The action enum is also framed by lifecycle intent.

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

Deploy Server

Other Tools