Skip to main content
Glama
Sign In
pathiel

pathiel

by Julian-dev28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

update_config

DestructiveIdempotent

Change trading configuration on this machine at once for all later orders. Pass only the keys to modify: mode, coin allowlists and blocklists, HIP-3 dex filters, or risk profile.

Instructions

Change the trading config on this machine; it applies at once to every later order. Pass only the keys to change: mode (LIVE or OFF), enable_hip3, coin_allowlist, coin_blocklist, hip3_dex_allowlist, hip3_dex_blocklist, or any other top-level key get_config shows, such as risk_profile; nested objects merge into the current ones and a list replaces the old list. mode is a label only: OFF does not stop the live-money tools. A call with nothing to change is refused. Read current values with get_config first, and call only when the user asked for this exact change. Not for one coin's leverage (set_leverage) or for sizing questions (get_risk_limits). Returns the updated config.

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

Input Schema

NameRequiredDescriptionDefault
modeNoAgent mode label, LIVE or OFF, read by the preflight check and metrics. The live-money tools here do not refuse on OFF.
enable_hip3NoAllow HIP-3 markets (xyz:, vntl:, ...).
coin_allowlistNoOnly these coins (empty: all).
coin_blocklistNoNever these coins.
hip3_dex_allowlistNoOnly these HIP-3 dexes (empty: all).
hip3_dex_blocklistNoNever these HIP-3 dexes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare idempotent and destructive; the description adds the traits that actually matter: the change takes effect immediately for every later order, nested objects merge while lists replace wholesale, the call returns the updated config, and — critically — 'mode is a label only: OFF does not stop the live-money tools.' That last caveat prevents a serious misuse that no annotation or schema field conveys. Consistent with destructiveHint=true.

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?

Front-loaded with the effect and the key list, then caveats, then routing. Dense but almost every clause carries information; the restatement that mode is a label and that live-money tools do not refuse on OFF duplicates the schema's mode description, though the safety value justifies it.

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?

There is no output schema, and the description closes that gap ('Returns the updated config'). For a mutation tool with open-ended properties, side effects, merge semantics, and prerequisites are all covered, so an agent has everything needed to call it safely.

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 baseline is 3, but the description adds real semantics beyond the schema: how values combine (nested merge, list replacement) and that additionalProperties are allowed for any top-level key get_config exposes, such as risk_profile. It stops short of explaining the interaction between allowlist and blocklist when both are set.

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?

States a specific verb and resource ('Change the trading config') plus its scope ('on this machine'), and explicitly names what it is not for (set_leverage for one coin's leverage, get_risk_limits for sizing). An agent can distinguish it from get_config and the other siblings without opening a 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?

Gives an explicit prerequisite ('Read current values with get_config first'), a gating condition ('call only when the user asked for this exact change'), two named exclusions with the correct alternatives, and the refusal case ('A call with nothing to change is refused'). This is the full when/when-not/alternative pattern.

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