iran-bourse-mcp

capital_calendar

Read-onlyIdempotent

Retrieve Iran bourse corporate-action calendar for capital increases, price adjustments, rights listings, and share-count changes, filtered by date window, market flow, and upcoming/recent direction.

Instructions

Market-wide corporate-action calendar (افزایش سرمایه و تعدیل قیمت), sorted by date: capital increases with the old and new share count, added shares and increase %, and price adjustments (reference-price cuts around dividends and rights) with the adjustment factor, for the days after today, the days up to today, or both. Forward visibility is short: the exchange lists a share-count change only a few days before it takes effect, and price adjustments only after the fact. Not in this feed: dividend per share, ex-dividend and AGM dates, rights exercise price; they are in Codal letters (use codal_filings).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "capital_calendar"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	How far from today the window reaches (max 366)
`flow`	No	1 or 'bourse' (default), 2 or 'fara', 4 or 'base' (Fara base market), or 'all' for the three
`kind`	No	'capital_increase', 'price_adjustment', 'capital_decrease', 'rights_symbol' (a rights instrument listed or removed), 'share_count_roundtrip' (bookkeeping pairs) or 'all' (default: the first four)	all
`limit`	No	Maximum rows to return (1-500); the server rejects larger values
`direction`	No	'upcoming' (after today, default), 'recent' (up to and including today) or 'all' (both sides)	upcoming

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the short look-ahead on share-count changes and the after-the-fact nature of price adjustments. The remaining gaps, pagination behaviour and result ordering beyond 'sorted by date', are minor.

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?

It is a single dense paragraph with the resource and contents front-loaded before the caveats. Every clause carries information, though the length and lack of breaks make it harder to scan than it needs to be.

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?

There is no output schema, yet the description spells out the returned fields well enough (old/new share count, added shares, increase %, adjustment factor) that an agent knows what comes back. Selection, filtering and fallback routing are all covered for this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the description is not required to carry parameter meaning. The description nonetheless reinforces the direction semantics by describing the after-today, up-to-today and both windows, and the kind enumeration is fully documented in the schema.

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 names a specific resource (market-wide corporate-action calendar) and enumerates exactly what it contains: capital increases with old/new share counts, added shares and increase %, plus price adjustments with adjustment factors. It also scopes the output to date-sorted windows and explicitly names what the feed does not contain, so an agent can tell it apart from codal_filings.

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?

It gives concrete usage context: forward visibility is short because share-count changes are listed only days before effect and price adjustments only after the fact, which tells the agent not to rely on it for planning. It also routes dividend/ex-dividend/AGM/rights-exercise-price needs to codal_filings. It does not explicitly contrast with the sibling corporate_actions tool, which is the remaining gap.

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