Skip to main content
Glama
Sign In

DocStoX

by com.docstox
OverviewDiscussionsAdmin

Get global markets

get_global_markets
Read-onlyIdempotent

Commodities, GIFT Nifty, Indian and world indices and FX, refreshed every minute.

  • commodities_in: MCX Gold (rupees per 10 g), Silver (per kg), Crude Oil (per barrel), Natural Gas (per mmBtu), Copper (per kg). The most-traded futures contract, held for the day; contract names it.

  • gift: GIFT Nifty (NSE IX Nifty future) with gift_vs_nifty50_points, its gap to Nifty 50's last level: the early read on the next NSE open.

  • india_indices: Nifty 50, Sensex, Bank Nifty, Next 50, Midcap/Smallcap, sector indices, India VIX.

  • global_indices: S&P 500, Nasdaq, Dow, FTSE, DAX, CAC, Euro Stoxx 50, Nikkei, Hang Seng, Shanghai, KOSPI, Taiwan, ASX 200 (in their own currencies).

  • commodities_global: COMEX Gold/Silver (US$ per troy oz), Brent and WTI (US$/bbl).

  • fx_rates: USD/INR (NSE monthly future), dollar index, US 10Y yield (%).

Every price carries its unit and status. MCX prices are futures, not retail jewellery rates (those add GST and making charges). MCX is quoted in Rs per 10 g and COMEX in US$ per troy oz, so the two differ in both unit and currency.

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

Input Schema

NameRequiredDescriptionDefault
itemNoName or id, matched loosely: 'gold', 'silver', 'crude', 'gift nifty', 'nasdaq', 'usd/inr', 'MCX_GOLD'
groupNoRestrict to one section; omit for the whole board
history_daysNoDaily session closes for ONE item (needs `item`)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive and closed-world, so safety is settled; the description goes well beyond by disclosing the one-minute refresh cadence, that every price carries unit and status, that MCX prices are the most-traded futures contract held for the day rather than retail rates, and that Indian and COMEX metals differ in both unit and currency.

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 a one-line summary (what it is plus refresh rate) followed by tight, per-section bullets. The bullets are somewhat long but every one carries distinct content vocabulary that helps an agent map items to sections, so little is wasted.

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?

With an output schema present, return shape needn't be documented, and annotations carry the safety profile. The description supplies what structured fields cannot: the coverage of each section, the future-vs-retail price caveat, and the per-unit/per-currency semantics, leaving no practical gap for correct invocation.

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 baseline is 3, but the prose adds real meaning: each `group` enum value is spelled out with the instruments it contains, and the MCX-vs-COMEX unit/currency distinction clarifies what the returned values mean. It stops short of explaining the loose `item` matching rules (gold, usd/inr, MCX_GOLD) or `history_days` behavior beyond the schema.

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 resource (a multi-section global markets board) and enumerates its exact sections: commodities_in, gift, india_indices, global_indices, commodities_global, fx_rates. An agent can tell this apart from siblings like get_stock_quote, get_india_vix, or get_market_pulse without opening 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 Guidelines3/5

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

Usage is implied by the section list and the 'omit for the whole board' framing, so an agent can infer that this is the broad-board tool and that group/item narrow it. However, it never names an alternative sibling (e.g. get_india_vix for VIX alone, get_stock_quote for a single stock) or states a when-not-to-use condition.

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

All DocStoX 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