Skip to main content
Glama
ofsazib

dse-mcp

by ofsazib

Get Index History

get_index_history

Fetch daily Dhaka Stock Exchange index history for DSEX, DS30, and totals over the last N days, up to 365 days from the rolling archive. Specify days to get the period needed for index analysis.

Instructions

Daily index history (DSEX, DS30, totals) for the last N days (max ~365; DSE keeps a rolling one-year archive).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key limitation: the data is only retained for ~365 days due to DSE's rolling archive, which is critical for an agent to know before requesting longer ranges. It does not explain the return format, but an output schema exists to cover that.

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?

A single sentence with no unnecessary words. The core action and resource are front-loaded, followed by the essential constraint in a parenthetical. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with an output schema, the description is nearly complete. It covers the purpose, the rolling-year limitation, and the specific indices. The only minor gap is not clarifying what 'totals' refers to, but this is not critical for invoking the tool 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?

The input schema provides no description for the 'days' parameter (0% coverage). The description compensates by explaining 'last N days' and the 365-day maximum, directly mapping to the parameter's meaning. It doesn't explicitly name the parameter, but the semantics are clear and inferable.

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 a specific verb and resource: 'Daily index history' for DSEX, DS30, and totals. It also specifies the time range (last N days), making it easy to distinguish from sibling tools like get_price_history which would apply to individual securities. The scope is concrete and unambiguous.

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 establishes a clear context: retrieving historical index data over a rolling period. It does not explicitly name alternatives or exclusions, but the mention of 'DSEX, DS30, totals' makes the intended use obvious for index-level analysis. This is clear context without explicit alternative routing.

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