boi-mcp

Bank of Israel interest rate

get_interest_rate

Fetches the Bank of Israel policy interest rate on a selected date and returns each change in the look-back window with date, previous rate, and basis-point move.

Instructions

Get the Bank of Israel policy interest rate (ריבית בנק ישראל, percent) on a date (default today) plus every change in the look-back window (default 2 years) with its date, previous rate and change in basis points.

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": "get_interest_rate"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No	Optional date, YYYY-MM-DD. Defaults to today in Israel
`since`	No	Optional start of the look-back window for changes, YYYY-MM-DD. Defaults to two years before date

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full behavioral burden and does reasonably well: it discloses the return contents (rate value, each change's date, previous rate, and change in basis points) and the defaulting behavior for both parameters. It omits edge-case behavior such as what happens for non-business days or dates outside available history, and doesn't restate that this is a read-only lookup, though 'Get' strongly implies it.

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?

A single dense sentence that front-loads the primary result (the policy rate on a date) before the secondary result (change history), with defaults inline. Slight redundancy in repeating defaults already present in the schema, but no filler sentences.

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?

There is no output schema, so the description must sketch the return shape, and it does so adequately by enumerating the fields returned for each change. Combined with full schema coverage for both parameters, an agent has nearly everything needed to call it correctly; only ordering and edge-case semantics are 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 both parameters are already fully documented in the input schema, including the same defaults restated in the description. The description adds only the framing that 'since' bounds the change history rather than the rate lookup itself, which is marginal beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and a precisely scoped resource: the Bank of Israel policy interest rate, with the Hebrew term and unit (percent) given for disambiguation. It also clarifies that the tool returns both the point-in-time rate and the change history, which implicitly separates it from a pure history or pure latest-rate tool, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the parenthetical defaults ('default today', 'default 2 years') tell an agent the tool works without arguments, but there is no explicit guidance on when to use this versus get_rate, get_rate_history, or get_latest_rates, and no stated exclusions or prerequisites.

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

Deploy Server