Skip to main content
Glama
mt5-mcp

mt5-mcp

by ramanthind02

symbol_tick

Read-only

Retrieve current bid, ask, last price, and timestamp for one symbol to check market quotes and support read-only monitoring.

Instructions

Return the latest bid, ask, last, and time for one symbol.

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

Input Schema

NameRequiredDescriptionDefault
symbolYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the returned fields (bid, ask, last, time), which is genuine behavioral value, but says nothing about quote staleness, snapshot vs streaming semantics, or what happens for an unknown or disconnected symbol.

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?

One short sentence with the resource stated immediately and no filler. It is well front-loaded, though it spends its entire budget on output fields rather than on selection guidance.

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?

For a one-parameter, read-only quote lookup with no output schema, the description adequately says what comes back. It is incomplete on symbol format, freshness guarantees, and error behavior, which matter for a live-market data call where openWorldHint is true.

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 0% for the single 'symbol' parameter, so the description must carry the meaning — and it does clarify that the call is scoped to exactly one symbol rather than a list. It still gives no format guidance (ticker vs broker-qualified name), so it does not fully compensate for the coverage gap.

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?

The description gives a specific verb ('Return') and a precise resource ('latest bid, ask, last, and time for one symbol'), so an agent knows exactly what data it retrieves. It is not explicitly differentiated from siblings like symbol_info or list_symbols, which is the only thing keeping it from a 5.

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

Usage Guidelines2/5

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

There is no statement of when to use this instead of symbol_info, list_symbols, or select_symbol, nor any prerequisite such as a connected terminal or selected symbol. Usage is only inferable from the tool name and the word 'latest'.

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