Skip to main content
Glama
Sign In
Helios

Helios

by brazaoo4
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

manage_server_config

Idempotent

Inspect, override, or reset live Helios runtime settings in SQLite without restarting the server.

Instructions

Inspect, override, or reset live Helios runtime settings in SQLite without restarting the server. action='list' returns all settings with secrets redacted; action='set' (requires key and value) persists an immediate runtime override; action='reset' (requires key) removes the SQLite override to revert to environment or default values. Security-locked keys (HELIOS_API_KEY, HELIOS_WEBHOOK_SECRET, MEMORY_DATA_DIR) cannot be altered at runtime, and changing HELIOS_GIT_API_URL or HELIOS_GIT_PROVIDER automatically clears any stored runtime HELIOS_GIT_TOKEN. Use manage_server_config for server-side tunables; use get_client_setup_bundle for local IDE/CLI onboarding or manage_scope_alias for project scope mappings.

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": "manage_server_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoSetting name to modify or reset (e.g., 'HELIOS_WORD_LIMIT', 'HELIOS_EPISODIC_TTL_DAYS', 'HELIOS_GIT_PROVIDER', 'HELIOS_GIT_API_URL', 'HELIOS_GIT_TOKEN', 'HELIOS_WEBHOOK_URL', 'HELIOS_PUBLIC_URL').
valueNoNew value to apply when action='set'.
actionNoAction: 'list' (show all configurable settings, active values, and source: db/env/default), 'set' (override a setting live in SQLite without restarting), or 'reset' (delete SQLite override and revert to env/default).list

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.3

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint=false and destructiveHint=false, the description still adds substantial context: secrets are redacted on list, overrides take effect immediately without a restart, security-locked keys (HELIOS_API_KEY, HELIOS_WEBHOOK_SECRET, MEMORY_DATA_DIR) cannot be altered, and changing HELIOS_GIT_API_URL/HELIOS_GIT_PROVIDER silently clears a stored runtime HELIOS_GIT_TOKEN. That last side-effect is exactly the kind of non-obvious behavior an agent could not infer from the schema or annotations.

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 capability statement and the action breakdown are front-loaded, and the security/side-effect warnings follow logically. Density is high with no filler, though the third sentence packs two unrelated warnings into one long clause chain, slightly hurting scanability.

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 mutation-capable config tool with an output schema present (so return shape needn't be explained), the description covers action semantics, required parameters per action, locked keys, cascading side effects, and sibling routing. Nothing an agent needs to invoke it safely is 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 a baseline of 3 applies, but the description goes further by binding parameters to actions ('set' requires key and value; 'reset' requires key) even though the schema marks nothing required. It does not add format or validation detail for the value field, keeping it short of a 5.

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?

Opening sentence states three specific verbs (inspect, override, reset) against a precise resource (live Helios runtime settings in SQLite) with the key differentiator "without restarting the server." An agent can immediately distinguish this from export_bundle or manage_git_webhooks without opening the schema.

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?

Each action is mapped to its condition ('list' returns settings with secrets redacted, 'set' requires key and value, 'reset' reverts to env/default), and the final sentence explicitly routes the agent away to get_client_setup_bundle and manage_scope_alias for adjacent needs. Both when-to-use and when-to-use-something-else are covered.

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