Skip to main content
Glama
myfinancialria

MyFinancial Market Data MCP

by myfinancialria
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Tapetide Score (one stock)

get_tapetide_score
Read-onlyIdempotent

Retrieve a stock's Tapetide Score (0-100) with six pillar sub-scores, weights, band, and governance flags to understand its rating.

Instructions

Get the Tapetide Score for ONE stock — a deterministic, non-LLM 0-100 composite rating from the latest complete scoring run, plus the six pillar sub-scores (quality, valuation, growth, momentum, financial_health, ownership), their weights, the coarse band and its label, the percentile within that run, data-confidence, coverage, and any governance caps or red flags. USE THIS for 'what is Tapetide's score for X', 'why is X rated Y', or as the rating input to a fundamental write-up. HOW TO READ IT: (1) the band matters more than the exact number — the score distribution is narrow and a 1-3 point gap is inside the noise; (2) a pillar can be null, meaning the underlying data is unavailable — it is NOT a zero, so never average over it or call the company weak on that pillar; (3) status: "insufficient_data" means no score is publishable for this stock — report that, do not substitute a number from elsewhere; (4) caps_applied / red_flags mean a governance overlay limited the score, which is itself worth saying; (5) there is deliberately NO category label — say what the pillar numbers show, in your own words, not a stock phrase. Decision-support only. The Tapetide Score is data analysis, not investment advice. Tapetide is not a SEBI-registered research analyst or investment adviser. Bands are intentionally coarse; small point differences may not be meaningful.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNoREQUIRED. The stock symbol, e.g. "RELIANCE" or "NATIONALUM".
tickerNoAlias for `symbol`.
identifierNoAlias for `symbol`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds substantial behavioral nuance beyond that: deterministic non-LLM, band vs exact number, null pillars meaning unavailable data, status insufficient_data, caps/red flags, and the deliberate absence of a category label. It also includes disclaimers about decision-support and SEBI registration.

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 long but front-loaded with the core purpose and then structured as a 'HOW TO READ IT' list with numbered points. Each point adds necessary interpretive guidance, so no sentence feels redundant. It is verbose but purposeful, earning a 4 rather than a 3.

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 no output schema, the description must explain the return value and does so comprehensively: the composite score, six pillars, weights, band, percentile, data-confidence, coverage, and governance flags. It also covers edge cases like null pillars and insufficient_data status. Nothing an agent needs to correctly interpret the result is missing.

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 description coverage is 100%, so all three parameters (symbol, ticker, identifier) are already documented as aliases. The description does not add any additional meaning or usage notes about the parameters beyond what the schema provides, so the baseline of 3 applies.

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 clearly states the verb 'Get', the resource 'Tapetide Score for ONE stock', and enumerates the returned components. It distinguishes itself from the sibling 'screen_tapetide_scores' by explicitly restricting to a single stock, so an agent can tell it apart without ambiguity.

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?

The description provides explicit use cases ('what is Tapetide's score for X', 'why is X rated Y', rating input for a write-up) but does not mention when NOT to use it or name the alternative screening tool. The 'for ONE stock' phrasing implies the distinction, but there is no explicit exclusion.

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