Skip to main content
Glama

Open market operations

cb_open_market
Read-onlyIdempotent

List the Central Bank's weekly open market operation reports and read the newest repo auction figures, including participating banks, accepted value, term, lowest rate, and maturity status.

Instructions

List the Central Bank's weekly open market operation reports and read the newest one's repo auction figures.

Each week the bank lends to banks through repurchase agreements to steer the interbank rate. latest.repo gives the banks that took part, the value of orders accepted (trillion rials), the term in days, the lowest accepted rate (percent) and what matured or is still outstanding. Older reports come as PDF links. The figures are read from a PDF whose Persian text is damaged, so only numbers are returned; check them against the file link. Related: cb_policy_rates for the weekly interbank rate and corridor.

Input Schema

NameRequiredDescriptionDefault
yearNoJalali year of the list. Default: current.
limitNoHow many weekly reports to list (1-12).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive, open-world operation. The description adds important behavior not covered by annotations: older reports are PDF links, latest.repo returns specific auction fields, and damaged Persian PDF text means only numbers are returned and should be checked against the file link.

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 front-loaded with the core action and remains focused on useful operational details. It is slightly longer than minimal, but every sentence adds either scope, return-shape context, or a data-quality caveat.

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, so the description carries the return-value explanation and does so adequately by describing latest.repo fields, older PDF links, and the numeric-only extraction limitation. Combined with complete schema coverage and safety annotations, an agent has enough context to invoke the tool correctly.

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 both parameters (year and limit) are already documented in the input schema. The description does not add further parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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 states a specific verb and resource: list weekly open market operation reports and read the newest report's repo auction figures. It distinguishes the tool from related siblings by pointing to cb_policy_rates for the interbank rate and corridor, so an agent can identify its role without opening the schema.

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 clearly implies this tool is for open market operation reports and latest repo auction details, and explicitly routes related rate/corridor questions to cb_policy_rates. It does not give explicit when-not-to-use guidance beyond that related-tool pointer, so it falls short of full alternative routing.

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