ValuEdge Stock Research MCP

Get stock technical analysis

get_stock_technicals

Read-onlyIdempotent

Use this when the user requests verified daily technical analysis of one confirmed stock: SMA 20/50/200, RSI 14, trend states, momentum, price performance, ATR, relative volume, and historical volatility. Requires ValuEdge OAuth and uses one unit from the existing account research/valuation allowance; the same ledger and plan limits apply to web and MCP. This is an end-of-day snapshot, not an intraday price feed. Do not claim MACD, chart patterns, support or resistance levels unless independently available. Never fill null indicators or issue buy/sell instructions.

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": {
      "ticker": "<ticker>"
    },
    "name": "get_stock_technicals"
  }
}

Input Schema

Name	Required	Description	Default
`ticker`	Yes

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`metadata`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the auth requirement (ValuEdge OAuth), a metered cost (one unit from the research/valuation allowance, same ledger as web and MCP), and the data recency model (end-of-day snapshot, not intraday). It also states null-handling policy and forbids fabricated indicators or recommendations — context an agent cannot get from the 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?

Front-loaded with the trigger condition and the indicator payload, then pricing/auth, then data-freshness, then output constraints — a sensible priority order. Dense but each sentence carries distinct information; the compliance-flavored closing sentence is the only part bordering on boilerplate.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description instead covers the things structured fields can't: auth, metered cost, snapshot timing, and which derived indicators must not be asserted. For a one-parameter read tool this leaves nothing material an agent needs before calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single ticker parameter has 0% schema description coverage, so the description must carry the meaning, and it only contributes the qualifier "one confirmed stock" — implying a single, already-validated identifier rather than a fuzzy query. It adds no guidance on accepted formats (exchange suffixes, index symbols like ^) that the schema pattern allows.

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?

Names a specific verb+resource ("daily technical analysis of one confirmed stock") and enumerates the exact indicator set returned (SMA 20/50/200, RSI 14, trend, momentum, ATR, relative volume, historical volatility). That enumeration cleanly separates it from siblings like get_stock_fundamentals and get_stock_valuation without the agent needing to open any schema.

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

Usage Guidelines4/5

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

"Use this when the user requests verified daily technical analysis of one confirmed stock" gives an explicit trigger condition, and the negative constraints (don't claim MACD/chart patterns/support-resistance, don't fill nulls, no buy/sell calls) bound the scope of use. It stops short of naming which sibling to call instead for fundamentals or valuation, so routing to alternatives is left implicit.

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

All ValuEdge Stock Research MCP tools Inspect

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

Need Help?