Provides tools for parsing Rakuten Securities transaction CSV and calculating XIRR (Extended Internal Rate of Return) from cash flows, enabling automated investment performance analysis.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@kimagure-dd/xirr-mcp calculate XIRR from my Rakuten CSV with current value ¥1,500,000"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for XIRR (Extended Internal Rate of Return) calculation, with built-in support for Rakuten Securities (楽天証券) transaction CSV.
Plug it into Claude Desktop or Claude Code, hand it a CSV exported from your brokerage, and ask:
「この CSV と現在の評価額 ¥1,500,000 で、実績年利を計算して」
Claude will compute the XIRR for you — accounting for irregular contributions and withdrawals — and explain the result.
🧮 calculate_xirr — XIRR from arbitrary cash flow series + current valuation
📄 parse_rakuten_csv — Parse Rakuten Securities transaction CSV (取引履歴) into normalized cash flows
🔌 Pure stdio MCP server, no network access required
📦 Zero runtime config, single npx command
Related MCP server: ibkr-mcp
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"xirr": {
"command": "npx",
"args": ["-y", "@kimagure-dd/xirr-mcp"]
}
}
}Restart Claude Desktop. The calculate_xirr and parse_rakuten_csv tools should appear.
claude mcp add xirr -- npx -y @kimagure-dd/xirr-mcpAsk Claude:
「以下のキャッシュフローで XIRR を計算して。2020-01-01 に 100万円投資、2022-01-01 に 50万円追加、現在（2025-01-01）の評価額 200万円」
Claude will call calculate_xirr with structured input and return:
{
"annualRate": 12.34,
"annualRateFormatted": "12.34%",
"totalInvestment": 1500000,
"totalGain": 500000,
"gainRateFormatted": "33.33%",
"converged": true
}楽天証券にログイン → 取引履歴 → CSV ダウンロード
(Shift_JIS でダウンロードされるため UTF-8 に変換)
Claude にファイル内容を渡して「これで実績年利を計算して。現在の評価額は ¥X」と依頼
Claude will pipe the CSV through parse_rakuten_csv → calculate_xirr automatically.
calculate_xirrCalculates XIRR from a list of dated cash flows and a current valuation.
Input:
Field | Type | Description |
| array | List of |
| number | Current portfolio valuation. |
| string | YYYY-MM-DD. Date of |
Output:
Field | Type | Description |
| number | Annualized return as a percentage. |
| number | Monthly rate (compounded to annual). |
| number | Sum of all cash flows. |
| number |
|
| number | Total gain as a percentage of investment. |
| boolean | True if the iterative solver converged. |
parse_rakuten_csvParses a Rakuten Securities transaction CSV.
Input:
Field | Type | Description |
| string | Raw CSV text (UTF-8 decoded). |
Required CSV headers:
約定日, 取引, ファンド名, 受渡金額/(ポイント利用)[円]
Behavior:
買付 rows → positive amount (investment)
Other transaction types (e.g. 売却) → negative amount (withdrawal)
Invalid rows are skipped with warnings
Newton-Raphson iteration as the primary solver
Bisection fallback when Newton fails to converge
Time unit: months (using 365.25 / 12 days per month)
Convergence threshold: 1e-7
The same logic is used in the browser-based XIRR calculator on kimagure-dd.dev, so results are identical.
This tool computes investment performance for informational purposes only. Taxes, transaction fees, and currency conversion are not considered. The output does not constitute investment advice.
npm install
npm run build
npm testTo test the server locally before publishing:
npm pack
# Then point Claude Desktop to the .tgz pathMIT © kimagure-dd
🌐 kimagure-dd.dev — Browser-based financial calculators
Calculate XIRR (Extended Internal Rate of Return) from a series of dated cash flows and a current portfolio valuation. Returns annualized rate, monthly rate, total gain, and convergence status. Useful for measuring actual investment performance accounting for irregular contributions and withdrawals.
| Name | Required | Description | Default |
|---|---|---|---|
| cashFlows | Yes | List of cash flows. Use positive amounts for investments (buy), negative for withdrawals (sell). | |
| currentValue | Yes | Current valuation of the portfolio at valuationDate. | |
| valuationDate | Yes | Date of the current valuation in YYYY-MM-DD format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates the outputs (annualized rate, monthly rate, total gain, convergence status) but does not mention potential issues like convergence failures, input validation, or performance limitations.
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, front-loaded with the purpose and return values. Every word is informative and there is no redundancy.
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 lack of output schema, the description adequately lists the return values (annualized rate, monthly rate, total gain, convergence status). It covers the essential outputs for a financial calculation tool.
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 input schema has 100% coverage, so the description adds limited semantic value beyond what's already documented. It reiterates that positive amounts are investments, which is already in the schema, but does not provide new details.
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 action 'Calculate XIRR' and the resource 'from a series of dated cash flows and a current portfolio valuation'. It distinguishes this tool from its sibling parse_rakuten_csv, which handles CSV parsing, by focusing on financial computation.
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 explains when to use the tool ('useful for measuring actual investment performance...'), but does not explicitly mention when not to use it or provide alternatives. However, given the distinct sibling tool, no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Rakuten Securities transaction CSV (取引履歴) and convert it into a normalized cash flow list. Handles 買付/売却 transaction types automatically. The output can be fed directly into calculate_xirr.
| Name | Required | Description | Default |
|---|---|---|---|
| csvContent | Yes | Raw CSV text exported from Rakuten Securities. Note: Rakuten exports are typically Shift_JIS encoded; decode to UTF-8 before passing. |
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 discloses the automatic handling of transaction types and encoding issues, but lacks details on error behavior, file size limits, or other edge cases. It is partially transparent but leaves gaps.
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 that are efficiently front-loaded. The first sentence states the core purpose, the second adds key details. Every sentence is meaningful with no superfluous words.
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 simple tool (1 param, no output schema), the description covers input format, handling, and integration with calculate_xirr. It could mention the output structure more explicitly, but it is sufficient for an agent to understand 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?
The schema has 100% coverage with a single parameter. The description adds value by explaining the parameter is raw CSV text and specifically notes the Shift_JIS encoding issue, which is critical for correct usage. This exceeds the baseline of 3 for high schema coverage.
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 parses Rakuten Securities transaction CSV and converts to normalized cash flow list, handling specific transaction types. It implicitly distinguishes from the sibling tool calculate_xirr by indicating the output feeds into it.
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 says when to use the tool (when you have a Rakuten Securities CSV) and hints at the workflow with calculate_xirr. It provides encoding context but doesn't explicitly state when not to use it or list alternatives, though the sibling count is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0calculate_xirrparse_rakuten_csvThe two tools have clearly distinct purposes: parse_rakuten_csv converts a specific CSV into cash flows, and calculate_xirr performs the actual rate calculation. No overlap exists.
Both tools follow a consistent verb_noun pattern using snake_case: parse_rakuten_csv and calculate_xirr. Perfectly consistent.
With only 2 tools, the server is very focused but appropriately scoped for the specific use case of Rakuten CSV processing and XIRR calculation. A slightly broader tool count could be argued, but it's reasonable.
For the domain of computing XIRR from Rakuten CSV data, the server is complete. The parse-then-calculate workflow covers all necessary steps without missing functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
MCP server exposing the Backtest360 engine API as tools for AI agents.
MCP server for stocksense-ai documentation, generated by doc2mcp.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kimagure-dd/xirr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server