Skip to main content
Glama
Sign In

SimianX AI

by io.github.SimianX-AI
OverviewDiscussionsAdmin

Quick read: the live agents once

quick_read

Run SimianX's four live AI agents once on a US stock or a crypto pair: Fundamental reads the business or the coin, Indicator the chart, Intelligence the news flow, and Decision turns it into a call with entry, stop and target and the next candle close. Returns a run id right away; each agent's result arrives in get_updates (or get_quick_read with wait) as it finishes, the decision last. After starting, follow it until done and tell the user every finished step; never wait for the user to ask. (uses points, metered on the models used like the website)

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": {
      "asset": "<asset>",
      "symbol": "<symbol>"
    },
    "name": "quick_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
tierNoModel tier (default fast)
assetYescrypto or stock (US stocks and ETFs)
agentsNoSubset of the four live agents (default all four)
modelsNoPer-agent model override, agent -> model id from list_models (paid plans)
symbolYesStock ticker (NVDA) or coin (BTC); crypto also takes a pair id such as BTC-USDT-SWAP
languageNoLanguage of the write-ups, e.g. en, zh-CN, ja (default: the account's)
timeframeNoCandle timeframe. Crypto: 1m 5m 15m 1H 4H 1D. Stock: 1m 15m 1H 1D 1W 1mo. Default 15m

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that the call is asynchronous ("Returns a run id right away"), where results surface (get_updates / get_quick_read with wait), the completion ordering (decision last), and the cost model ("uses points, metered on the models used"). With annotations only covering readOnly/openWorld/idempotency, this adds the behavior an agent actually needs to drive the tool.

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 action and asset scope, then the async return path, then the cost note. Dense but each clause carries information; the final parenthetical on points is terse and placed last, which is appropriate.

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

Completeness4/5

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

No output schema exists, yet the description covers what a call returns (a run id) and how to retrieve results, closing the main gap. It does not say how long a run takes, what a failed/partial run looks like, or whether a run can be stopped, which would matter for an async multi-minute job.

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 description coverage is 100%, so the baseline is 3; the description adds some meaning by naming the four agents (fundamental, indicator, intelligence, decision) that the `agents` subset parameter selects from and by reinforcing the stock/crypto asset split. It adds nothing for tier, models, language, or timeframe beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Run SimianX's four live AI agents once on a US stock or a crypto pair") and enumerates what each agent produces, plus that Decision yields entry/stop/target. It does not explicitly distinguish itself from similarly named siblings (run_live_analysis, start_live_session, run_autopilot_agent), which is the only missing piece.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the asset scoping and by the explicit follow-up protocol ("each agent's result arrives in get_updates (or get_quick_read with wait)... follow it until done"), which is good operational guidance. However, there is no statement of when to prefer this over run_live_analysis, start_live_session, or ask_deep_analysis, which the agent must infer from near-identical sibling names.

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

All SimianX AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources