This server provides deterministic financial calculation tools for day-count fractions and accrued interest.
Calculate Day-Count Fraction (day_count_fraction): Compute the exact day-count fraction between two ISO YYYY-MM-DD dates using a specified market convention (30/360, 30E/360, 30E/360 ISDA, ACT/360, ACT/365F, ACT/ACT ISDA). Supports an endIsTermination flag for 30E/360 ISDA.
Compute Accrued Interest (accrued_interest): Calculate simple accrued interest (notional × rate × day-count fraction) given a notional amount, annual rate (as a decimal), date range, and day-count convention. Supports the same conventions and endIsTermination flag.
List Supported Conventions (list_conventions): Retrieve all supported day-count conventions available on the server.
Provably correct day-count, holiday-calendar, business-day, and payment-schedule calculations. A small, dependency-light TypeScript library and an MCP server, so an AI agent can get the exact date or number instead of guessing.
LLMs are unreliable at date and money math: they pick the wrong day-count convention, forget market holidays, and miscompute accrued interest. shikamaru does it deterministically and proves it against published reference values. Do not let a model guess your interest accrual or your settlement date.
Related MCP server: SSCMFI Bond Analytics MCP Server
Day-count fraction between two dates under seven market conventions: 30/360, 30E/360, 30E/360 ISDA, ACT/360, ACT/365F, ACT/ACT ISDA, ACT/ACT ICMA (with reference periods and stub decomposition).
Simple accrued interest: notional x rate x day-count fraction.
Holiday calendars as rules in code, no data feed: us-federal, nyse, sifma-us, target, uk.
Business-day math: is-business-day, next/previous, ISDA adjustment conventions (following, modified-following, preceding, modified-preceding), T+N settlement.
Payment schedules: monthly to annual, backward or forward roll, short or long stubs, end-of-month rule, per-period unadjusted and adjusted dates.
All of it exposed as a library and as an MCP server.
Every MCP tool is annotated read-only and returns structured output (typed JSON under an output schema) alongside the plain-text result, so an agent client can consume the numbers without parsing text.
Calendars are published rules plus a short pinned table of historical one-off closures, current as of this version. Rules generate correct dates arbitrarily far forward; one-off closures (a mourning day, a proclaimed extra holiday) are added when announced and ship in a patch release. A scheduled CI run re-checks every calendar against the latest QuantLib weekly, so drift is detected, not discovered.
npm install @jayofemi/shikamaruimport {
accruedInterest, addBusinessDays, adjustDate, dayCountFraction,
generateSchedule, isBusinessDay,
} from "@jayofemi/shikamaru";
dayCountFraction("2003-11-01", "2004-05-01", "ACT/ACT ISDA"); // 0.4977...
accruedInterest({
notional: 1_000_000,
rate: 0.05,
start: "2024-01-01",
end: "2024-04-01",
convention: "ACT/365F",
});
isBusinessDay("2024-06-19", "nyse"); // false (Juneteenth)
adjustDate("2024-03-29", "modified-following", "target"); // "2024-03-28" (Good Friday, stays in March)
addBusinessDays("2024-07-02", 2, "us-federal"); // "2024-07-05" (T+2 over July 4th)
generateSchedule({
effective: "2024-01-15",
termination: "2026-01-15",
frequency: "semiannual",
calendar: "target",
}); // four periods with unadjusted and adjusted datesDates are strict ISO YYYY-MM-DD. Rate is an annual decimal (0.05 = 5%).
From source (local dev):
npm install
npm run build
node dist/cli.jsOr launch the published package directly:
npx @jayofemi/shikamaruPoint any MCP client (Claude Desktop, an IDE, etc.) at that command over stdio.
Claude Code users can also install it as a plugin, which registers the MCP server automatically:
/plugin marketplace add JayOfemi/shikamaru
/plugin install shikamaru@shikamaruThe test suite exercises the server end to end in memory, covering tool listing, read-only annotations, structured output against each output schema, and a call to every tool. For an interactive check, use the official MCP Inspector:
npm run build
npx @modelcontextprotocol/inspector node dist/cli.jsIt opens a local UI, connects over stdio, lists the tools, and lets you call them. Sanity check: day_count_fraction with start 2003-11-01, end 2004-05-01, convention ACT/ACT ISDA returns about 0.4977.
Conventions follow the ISDA 2006 definitions; calendars follow their published sources (OPM, NYSE rules, SIFMA recommendations, ECB TARGET rules, gov.uk proclamations). The test suite checks published reference vectors (ISDA worked examples, official holiday lists, the OpenGamma conventions guide), property checks, and differential batteries against QuantLib, the de-facto reference: day-count fractions, full per-calendar holiday lists across decades, business-day adjustment and advancing, schedules compared date by date, and ACT/ACT ICMA fractions including stubs.
To (re)generate the QuantLib batteries (needs Python + pip):
pip install QuantLib
npm run vectorsThis writes test/vectors/quantlib.json and test/vectors/quantlib-calendar.json (commit both). npm test then checks shikamaru against every QuantLib value. CI regenerates the batteries from the latest QuantLib on every push AND on a weekly schedule (the drift watchdog), so a real-world calendar change surfaces as a red run even when the repo is quiet. The proof is the product.
npm install
npm run build
npm testMIT. Copyright (c) 2026 Jay Ofemi.
Exact simple accrued interest (notional * rate * day-count fraction) between two dates. Dates are ISO YYYY-MM-DD; rate is the annual rate as a decimal (0.05 = 5%). Deterministic.
| Name | Required | Description | Default |
|---|---|---|---|
| notional | Yes | Face / principal amount. | |
| rate | Yes | Annual rate as a decimal, e.g. 0.05 for 5%. | |
| start | Yes | ISO calendar date, YYYY-MM-DD (e.g. 2024-03-15). Zero-padded, no time or timezone. | |
| end | Yes | ||
| convention | Yes | Day-count convention, e.g. ACT/ACT ISDA or 30/360. | |
| endIsTermination | No | 30E/360 ISDA only: true if the end date is the instrument's maturity date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Deterministic' implying no side effects, but for a computation tool, that is baseline. It does not disclose edge cases, error handling, or behavior when inputs are invalid (e.g., negative notional, reversed dates). With no annotations, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core purpose, the second adds format details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input and formula but does not describe the return value (presumably a number, likely in the same currency as notional). For a tool without an output schema, this omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema description coverage, the schema already documents parameters. The description adds value by clarifying the formula (notional * rate * day-count fraction) and emphasizing that rate is a decimal, which reinforces the schema. This goes beyond the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes exact simple accrued interest using notional, rate, and day-count fraction between two dates. It distinguishes from sibling tools (day_count_fraction, list_conventions) by focusing on the full interest calculation rather than just the fraction or conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention that day_count_fraction is for obtaining the fraction alone, nor does it specify any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact day-count fraction between two dates under a market convention. Dates are ISO YYYY-MM-DD. Deterministic; do not estimate this with a model.
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | ISO calendar date, YYYY-MM-DD (e.g. 2024-03-15). Zero-padded, no time or timezone. | |
| end | Yes | ||
| convention | Yes | Day-count convention, e.g. ACT/ACT ISDA or 30/360. | |
| endIsTermination | No | 30E/360 ISDA only: true if the end date is the instrument's maturity date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description calls the tool 'exact' and 'deterministic', which covers behavioral traits well in the absence of annotations. However, it does not disclose what the output looks like (e.g., a floating-point number), nor does it mention any edge cases or error handling, leaving some behavioral details implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose. Every word is necessary; no filler or redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (including an optional boolean) and no output schema, the description is insufficiently complete. It does not explain the return format, precision, error behavior (e.g., invalid dates, start after end), or provide examples, leaving agents without enough context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description repeats information already in the schema (e.g., 'Dates are ISO YYYY-MM-DD'). It adds no new meaning beyond what the input schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'compute day-count fraction between two dates under a market convention', which is specific and unambiguous. The sibling tools 'accrued_interest' and 'list_conventions' are clearly distinct in purpose, so no confusion arises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises against using a model to estimate the fraction ('Deterministic; do not estimate this with a model'), implying that this tool should be used for exact calculations. However, it does not explicitly state when to use this tool over alternatives, nor does it provide context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the supported day-count conventions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists conventions, which is simple and transparent. However, it does not disclose any potential side effects, authentication needs, or rate limits, but for a read-only list tool this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded. Every word is necessary and there is no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and a simple purpose, the description is complete. It tells the agent exactly what the tool does without missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds no parameter information, but with zero parameters, the baseline is 4. The description does not explain what conventions are or the output format, but the absence of parameters means no additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported day-count conventions, with a specific verb ('list') and resource ('supported day-count conventions'). It distinguishes itself from sibling tools like 'accrued_interest' and 'day_count_fraction' which are computation tools, not listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when not to use it or any prerequisites, which is a gap given two sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: calculating accrued interest, computing day-count fractions, and listing supported conventions. No overlap in functionality.
All names use lowercase and underscores, but patterns vary: 'accrued_interest' (adjective+noun), 'day_count_fraction' (compound noun), 'list_conventions' (verb+noun). Slight inconsistency but clear and readable.
Three tools are well-scoped for a financial calculations server. Each tool serves a necessary function without redundancy or missing essentials.
The set covers core operations: listing conventions, computing day count fractions, and calculating accrued interest. Minor gaps like date validation exist but don't hinder primary workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Industry-standard bond math for AI agents: price, yield, accrued interest, duration, yield-to-worst
High-precision finance & business calculations for AI agents — exact decimals, never floats.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JayOfemi/shikamaru'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
