Skip to main content
Glama

CeylonCharts - Colombo Stocks Exchange (CSE) data for AI Agents

Get corporate actions

get_corporate_actions
Read-onlyIdempotent

Get a calendar of corporate actions (dividends, rights issues, share splits) — announcement details, not just a price-adjustment factor. This is the tool for dividends/rights/splits specifically; for other company disclosures (board changes, AGM/EGM notices, trading suspensions, etc.), use get_announcements instead. Omit all filters to browse every corporate action in the dataset, past and future, oldest first; pass from= to jump straight to upcoming ones, which is the most common need. Optionally scope to one company (matches every one of its share classes, not just one) and/or one kind. Returns CSV, one row per action. If the symbol is ambiguous, returns JSON candidates instead.

Input Schema

NameRequiredDescriptionDefault
toNoEnd date in YYYY-MM-DD format (by effective/ex-date). Omit for no upper bound.
fromNoStart date in YYYY-MM-DD format (by effective/ex-date). Omit for no lower bound.
kindNoRestrict the calendar to one kind of corporate action — split (a share split or consolidation), rights (a rights issue), or dividend.
limitNoMax entries to return, oldest first — use `offset` to page further in.
offsetNoSkip this many of the earliest matching entries before taking `limit` — use to page further in.
symbolNoA CSE ticker or company name (e.g. "SAMP" or "Sampath Bank"), typo-tolerant. Matches every share class of that company. Omit for a market-wide calendar. If ambiguous, the response returns candidates instead of data; ask the user to pick one and call again with the exact symbol.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"Restrict to one kind of corporate action."New value: +"Restrict the calendar to one kind of corporate action — split (a share split or consolidation), rights (a rights issue), or dividend."
    • changedInput schema / properties / limit / description
      Previous value: -"Max entries to return, oldest first. Default 50, max 500."New value: +"Max entries to return, oldest first — use `offset` to page further in."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description goes further by disclosing return format (CSV, one row per action), default ordering (oldest first), and the ambiguity fallback (JSON candidate list instead of data). The JSON-candidates behavior is a non-obvious failure mode an agent must handle, and it is stated clearly.

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-loaded with purpose and routing before defaults and return format; each sentence carries distinct information (boundary, default behavior, scoping, output shape). No filler or restatement of the tool name.

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 compensates by explaining the CSV row format and the JSON-candidates edge case. Combined with complete schema descriptions for all six optional parameters, an agent has everything needed to call this 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, but the description adds real meaning beyond the schema: that symbol matches every share class rather than one, and that an omitted symbol yields a market-wide calendar. It doesn't explain the limit/offset paging interaction beyond what the schema already says, keeping it just short of a 5.

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 and resource ('Get a calendar of corporate actions') and enumerates the covered kinds (dividends, rights issues, share splits). It explicitly draws the boundary against the sibling get_announcements, so an agent can distinguish the two 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?

Names the alternative tool (get_announcements) and the exact condition that selects it (board changes, AGM/EGM notices, trading suspensions). It also gives positive guidance on the most common call pattern (omit filters to browse all, or from=<today> for upcoming).

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.

Resources