Skip to main content
Glama

Tapetide - Indian Stock Market MCP

Identifiers Held By a Stock As-Of a Date

get_identifiers_asof
Read-onlyIdempotent

The REVERSE of resolve_identifier_asof: given a company's symbol and a date, return which symbol and ISIN that company held at that time. USE THIS to label historical output correctly — e.g. reporting a 2019 backtest position under the ticker it actually traded as then, rather than its current name. Also useful for explaining a rename to a user who is confused why a symbol they remember no longer resolves. Pass the symbol the company trades as today (resolve_identifier_asof maps an old ticker to it). Coverage bounds are stated in the response — outside them the answer is out_of_coverage, not 'no identifiers'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoAs-of date, YYYY-MM-DD. Defaults to today (IST) when omitted.
symbolNoREQUIRED. The company's current stock symbol, e.g. "TRENT".
tickerNoAlias for `symbol`.
stock_idNoDeprecated. Use `symbol`.
identifierNoAlias for `symbol`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / identifier
      Added value: +{
      +  "description": "Alias for `symbol`.",
      +  "type": "string"
      +}
    • changedInput schema / properties / stock_id / description
      Previous value: -"REQUIRED. The internal stock id, as returned in other tools' meta.stock_id."New value: +"Deprecated. Use `symbol`."
    • addedInput schema / properties / symbol
      Added value: +{
      +  "description": "REQUIRED. The company's current stock symbol, e.g. \"TRENT\".",
      +  "type": "string"
      +}
    • addedInput schema / properties / ticker
      Added value: +{
      +  "description": "Alias for `symbol`.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds a genuinely useful behavioral trait: coverage bounds are stated in the response and out-of-range returns `out_of_coverage` rather than an empty result. It does not fully describe return shape, but that is minor here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core relationship ('REVERSE of resolve_identifier_asof') and then adds use cases and a coverage caveat. Despite length, every sentence carries distinct information; there is no filler.

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?

No output schema exists, yet the description states what is returned (symbol and ISIN as of the date) and the edge-case semantics (out_of_coverage). Combined with annotations covering safety, an agent has everything needed to invoke it correctly.

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 the baseline is 3. The description adds meaning beyond the schema by clarifying which symbol to pass — the one the company trades as TODAY, with the reverse mapping handled by resolve_identifier_asof — which resolves the today-vs-historical ambiguity the schema leaves open.

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 verb+resource ('given a company's symbol and a date, return which symbol and ISIN that company held'). It explicitly frames itself as the REVERSE of resolve_identifier_asof, so the agent can distinguish it from that sibling without opening either schema.

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?

Gives concrete when-to-use cases (labeling historical/backtest output, explaining a rename) and names the alternative relationship to resolve_identifier_asof. Nothing is left to inference about when this tool is the right pick.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.