Skip to main content
Glama
harshitagarwal2

tradingrearchagents

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TRADINGAGENTS_LEGACY_PATHNoPath to a compatible TradingAgents checkout. Takes precedence over the pinned upstream extra. Set when using the legacy upstream execution path.
TRADINGAGENTS_CODEX_AUTH_PATHNoOptional path to Codex OAuth auth.json (default ~/.codex/auth.json). Used only with the openai_codex provider on a checkout containing TradingAgents PR #1195.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
discover_capabilityA

Discover executors, tools, safety boundaries, and default fixture.

get_feature_matrixA

Return implemented features, safety exclusions, and runtime readiness.

prepare_fixtureA

Validate and expand the deterministic ORCL fixture without running it.

run_fixtureB

Run all stages deterministically and store the in-memory result and events.

prepare_host_runB

Return the canonical plan for the active host harness; accepts no model credentials.

import_host_runB

Validate completed host stage outputs and atomically publish the final dossier.

create_host_runC

Create a durable credential-free host run with decision-memory recall.

start_host_runA

Start a prepared durable host run and return its first stage.

append_run_receiptsC

Append safe live stage/tool receipts without prompts, raw arguments, or credentials.

commit_host_stageA

Commit and checkpoint one completed host stage, then return the next stage.

pause_host_runC

Pause a host run at its next portable stage boundary.

resume_host_runB

Resume from the first incomplete portable stage; replay interrupted work.

get_run_controlB

Return durable lifecycle status, revision, checkpoint, cancellation, and next stage.

poll_run_eventsC

Read live lifecycle events after a monotonic cursor.

request_run_cancellationB

Request cooperative cancellation; the host owns interruption.

acknowledge_run_cancellationC

Acknowledge host interruption and make cancellation terminal.

finalize_host_runA

Validate all committed stages and atomically publish the completed dossier.

export_completed_runA

Export a bundle with atomic first publication and crash-recoverable validated overwrite.

query_decision_memoryA

Recall up to five same-symbol and three cross-symbol prior decisions.

record_decision_outcomeB

Append a host-observed outcome and reflection to a prior research decision.

get_conformance_reportB

Validate portable observable invariants; optionally verify pinned checkout identity.

get_runA

Return a compact dashboard-oriented run record.

get_run_eventsB

Return the ordered event stream for a run.

get_run_resultB

Return the full typed result for a run.

get_run_viewA

Return the complete UI-ready run projection for inline harness rendering.

launch_local_dashboardC

Serve the local dashboard assets and JSON APIs on loopback.

get_dashboard_reportB

Return the presentation-safe dashboard summary for a run.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.7/5.0

Scored across 27 tools

Disambiguation2/5

Several tools have overlapping boundaries: get_run, get_run_events, get_run_result, get_run_view, get_run_control all retrieve run data but differ subtly in scope and purpose. Similarly, run_fixture, create_host_run, and start_host_run all initiate executions, and import_host_run vs finalize_host_run both validate and publish dossiers. The differences are hard to discern from names alone.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (get_, create_, start_, run_, pause_, resume_, finalize_), with a few camelCase outliers like launch_local_dashboard, prepare_host_run, and append_run_receipts that break the underscore convention. The dominant pattern is readable and predictable, but the mixed style is a minor inconsistency.

Tool Count2/5

27 tools is on the heavy side, especially for what appears to be a single-purpose trading research harness. Many tools (get_run, get_run_events, get_run_result, get_run_view, get_run_control, poll_run_events) overlap substantially in the retrieval space, suggesting the surface could be consolidated significantly.

Completeness4/5

The host-run lifecycle is comprehensively covered: create, start, commit, pause, resume, cancel, finalize, export, and query. Decision memory has both recall and record-outcome operations. Minor gaps exist around fixture editing or host-run deletion, but the core research workflow appears fully covered with no obvious dead ends.

Maintenance

ActivitySlowing
ResponsivenessNo issues