Skip to main content
Glama
myfinancialria

MyFinancial Market Data MCP

by myfinancialria
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Resolve a Symbol/ISIN As-Of a Date

resolve_identifier_asof
Read-onlyIdempotent

Resolve a historical ticker or ISIN to the owning company for any past date, preventing renamed or recycled symbols from skewing backtests. Returns certainty status to quarantine ambiguous mappings.

Instructions

Resolve a historical symbol or ISIN to the company that held it ON a given date. USE THIS when working with old data whose ticker may since have been renamed, reused, or reassigned — e.g. a 2018 holdings file, an old research note, or a backtest that must not treat one company as two securities (or worse, merge two different companies because a ticker was recycled after a delisting). Returns present | uncertain | not_found | out_of_coverage with certainty ranges. uncertain means the date falls in an open bracket around a rename/ISIN change — quarantine it rather than asserting the mapping. The response states its own coverage window; a date outside it returns out_of_coverage and must not be reported as 'no such symbol'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoAs-of date, YYYY-MM-DD. Defaults to today (IST) when omitted.
kindNoWhich identifier kind `value` is (default nse_symbol)nse_symbol
valueNoREQUIRED. The identifier value, e.g. "TRENT" or "INE849A01020".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses the return statuses ('present' | 'uncertain' | 'not_found' | 'out_of_coverage'), the meaning of 'uncertain' (open bracket around rename), and the coverage window behavior. This is valuable behavioral context not covered by 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?

The description is well-structured, starting with the core purpose, then usage context, then response semantics. It is somewhat long but every sentence adds value. The front-loading of the purpose is good, and the format is readable. Slightly verbose but not wasteful.

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?

Given the complexity of as-of resolution (renames, recycles, coverage windows) and the absence of an output schema, the description covers all critical aspects: return statuses, the uncertain bracket, coverage window, and handling guidance. Nothing essential is missing for an agent to call it correctly.

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?

Schema descriptions cover all three parameters (date, kind, value) at 100% coverage, so the baseline is 3. The description adds some context (e.g., examples 'TRENT' or 'INE849A01020') but does not provide additional parameter-level semantics beyond what the schema already states. It reinforces the schema but doesn't add new meaning.

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?

The description states a specific verb ('Resolve') and resource ('historical symbol or ISIN') with an explicit temporal scope ('ON a given date'). It clearly differentiates from generic lookup tools by explaining the as-of resolution and mentions the edge cases of renames/reassignments, which distinguishes it from sibling tools like get_identifiers_asof without naming them.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance ('USE THIS when working with old data...') with concrete examples (2018 holdings, old research notes, backtests). It also gives behavioral instructions for handling the response: quarantine uncertain results and do not report out_of_coverage as 'no such symbol'. This is comprehensive usage guidance.

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

Deploy Server

Other Tools