Skip to main content
Glama
Sign In
trading-mcp-server

trading-mcp-server

by mukul8896
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

update_trading_config

Update runtime trading configurations such as risk limits and intraday/swing flags in the .env file. Does not modify live-trading switches or credentials.

Instructions

Update runtime-updatable config keys in .env (risk limits, intraday/swing enable flags). Live-trading switches, ALLOW_DELIVERY_SELL and credentials can NOT be changed here — a human must edit .env.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "updates": "<updates>"
    },
    "name": "update_trading_config"
  }
}

Input Schema

NameRequiredDescriptionDefault
updatesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the mutation of .env and scope of changes, but does not detail immediate effect on runtime, authorization needs, or error handling. Lacks depth beyond the basic mutation fact.

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?

Two sentences: first states purpose, second states restrictions. No unnecessary words, front-loaded with actionable information.

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

Completeness3/5

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

Given the flexible parameter and no output schema, the description adequately covers what the tool does and its constraints. It lacks information on return value (e.g., success/failure indication) or side effects, but is likely sufficient for an AI agent to use correctly.

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 0% with a single free-form object parameter. The description adds critical semantics by listing example updatable keys and exclusions, providing meaning beyond the bare schema. However, it does not enumerate all valid keys or value formats.

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 clearly states the tool updates runtime-updatable config keys in .env (risk limits, intraday/swing enable flags) and explicitly lists what cannot be changed (live-trading switches, ALLOW_DELIVERY_SELL, credentials), distinguishing it from siblings like get_trading_config or switch_to_live_mode.

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 provides explicit when-to-use (updating specific config keys) and when-not-to-use (for live-trading switches and credentials, requiring human .env editing), giving clear context for agent decision.

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