XIRR(확장 내부 수익률) 계산을 위한 MCP 서버로, 라쿠텐 증권(楽天証券) 거래 CSV를 기본 지원합니다.
Claude Desktop 또는 Claude Code에 연결하고 증권사에서 내보낸 CSV를 전달한 뒤 다음과 같이 질문하세요:
「이 CSV와 현재 평가액 ¥1,500,000으로 실적 연이율을 계산해 줘」
Claude가 불규칙한 입출금을 고려하여 XIRR을 계산하고 결과를 설명해 줍니다.
🧮 calculate_xirr — 임의의 현금 흐름 시리즈와 현재 평가액을 통한 XIRR 계산
📄 parse_rakuten_csv — 라쿠텐 증권 거래 내역(取引履歴) CSV를 정규화된 현금 흐름으로 파싱
🔌 순수 stdio MCP 서버, 네트워크 액세스 불필요
📦 런타임 설정 제로, 단일 npx 명령어로 실행
Related MCP server: ibkr-mcp
~/Library/Application Support/Claude/claude_desktop_config.json(macOS) 또는 %APPDATA%\Claude\claude_desktop_config.json(Windows)을 편집하세요:
{
"mcpServers": {
"xirr": {
"command": "npx",
"args": ["-y", "@kimagure-dd/xirr-mcp"]
}
}
}Claude Desktop을 재시작하세요. calculate_xirr 및 parse_rakuten_csv 도구가 나타나야 합니다.
claude mcp add xirr -- npx -y @kimagure-dd/xirr-mcpClaude에게 다음과 같이 질문하세요:
「다음 현금 흐름으로 XIRR을 계산해 줘. 2020-01-01에 100만 엔 투자, 2022-01-01에 50만 엔 추가, 현재(2025-01-01) 평가액 200만 엔」
Claude가 구조화된 입력값으로 calculate_xirr을 호출하여 다음과 같이 반환합니다:
{
"annualRate": 12.34,
"annualRateFormatted": "12.34%",
"totalInvestment": 1500000,
"totalGain": 500000,
"gainRateFormatted": "33.33%",
"converged": true
}라쿠텐 증권 로그인 → 거래 내역(取引履歴) → CSV 다운로드
(Shift_JIS로 다운로드되므로 UTF-8로 변환)
Claude에게 파일 내용을 전달하고 「이걸로 실적 연이율을 계산해 줘. 현재 평가액은 ¥X」라고 요청
Claude가 자동으로 CSV를 parse_rakuten_csv → calculate_xirr 순으로 파이프 처리합니다.
calculate_xirr날짜별 현금 흐름 목록과 현재 평가액을 사용하여 XIRR을 계산합니다.
입력:
필드 | 타입 | 설명 |
| array |
|
| number | 현재 포트폴리오 평가액. |
| string | YYYY-MM-DD. |
출력:
필드 | 타입 | 설명 |
| number | 백분율로 표시된 연간 수익률. |
| number | 월간 수익률(연간으로 복리 계산). |
| number | 모든 현금 흐름의 합계. |
| number |
|
| number | 투자액 대비 총 수익률(백분율). |
| boolean | 반복 솔버가 수렴했는지 여부. |
parse_rakuten_csv라쿠텐 증권 거래 CSV를 파싱합니다.
입력:
필드 | 타입 | 설명 |
| string | 원본 CSV 텍스트(UTF-8 디코딩됨). |
필수 CSV 헤더:
約定日, 取引, ファンド名, 受渡金額/(ポイント利用)[円]
동작:
買付 행 → 양수(투자)
기타 거래 유형(예: 売却) → 음수(인출)
유효하지 않은 행은 경고와 함께 건너뜀
뉴턴-랩슨(Newton-Raphson) 반복법을 기본 솔버로 사용
뉴턴법 수렴 실패 시 이분법(Bisection)으로 대체
시간 단위: 월(월당 365.25 / 12일 사용)
수렴 임계값: 1e-7
kimagure-dd.dev의 브라우저 기반 XIRR 계산기와 동일한 로직을 사용하므로 결과가 동일합니다.
이 도구는 정보 제공 목적으로만 투자 성과를 계산합니다. 세금, 거래 수수료, 환전 비용은 고려되지 않습니다. 출력 결과는 투자 조언을 구성하지 않습니다.
npm install
npm run build
npm test배포 전 로컬에서 서버를 테스트하려면:
npm pack
# Then point Claude Desktop to the .tgz pathMIT © kimagure-dd
🌐 kimagure-dd.dev — 브라우저 기반 금융 계산기
🐙 소스 코드
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.
v0.1.0calculate_xirrparse_rakuten_csvScored across 2 tools
The 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.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Research US-listed companies and funds with the StockPortfolio.pro MCP server. Tools cover SEC filing-grounded financials, filing timelines, company comparisons, watchlist screens, fund profiles, and cited filing questions. Filed figures include their fiscal period and EDGAR source URL; missing filing data is returned as null. Public tools work without authentication; optional API-key or OAuth access is supported. US-listed, USD-reporting companies only. Keyless access includes 3 free AI questions per rolling 30-day window. To get more now, choose the Dev plan ($19.99/month, 200 credits) at https://www.stockportfolio.pro/register?plan=dev, then follow https://www.stockportfolio.pro/docs/api-mcp to connect with OAuth or an API key. Or wait for the free allowance to renew.
MCP server exposing the Backtest360 engine API as tools for AI agents.
