de en es ja ko ru zh

depreciation-mcp

Name: depreciation-mcp
Author: boam79

by boam79

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

depreciation-mcp

法人税法に基づく固定資産の耐用年数・減価償却・税務調整の参考値をModel Context Protocol (MCP)で提供するサーバーです。

計算結果は参考用です。申告や会計処理には、適用法令・事実関係・専門家による検討が必要です。

PRD背景 (MCP-DEP-001-v1)

以下のプロジェクト概要、問題定義、目標ユーザー、主要ユーザーシナリオは、PRD『施設減価償却計算MCP v1.0（修正版）』の第1・2・3・6章をREADME用に転載したものです。

1. プロジェクト概要

固定資産の減価償却は、決算および法人税申告において繰り返し行われる重要な実務である。しかし、現場では以下の問題が繰り返されている。

資産タイプ別の耐用年数を確認するために、施行規則［別表5・6］を直接探さなければならない。
会計チームや総務チームがスプレッドシートの数式に依存して計算している。
定額法/定率法の選択、耐用年数の範囲検討、税務調整の計算が分断されており、作業が煩雑である。
担当者変更時に判断基準が残らず、一貫性に欠ける。

本MCPは、このプロセスを標準化し、ユーザーが資産情報を入力すれば 法人税法に基づく耐用年数の照会 → 減価償却計算 → 税務調整の参考値 → 一括処理および比較分析までを一貫して提供することを目標とする。

2. 問題定義

2.1 現在の実務における不便さ

法令照会の反復性 資産分類と業種別の基準年数を毎回手動で確認しなければならない。
計算の非一貫性 同じ資産でも担当者によって異なる耐用年数や計算式が適用される可能性がある。
税務調整の分離管理 会計上の減価償却費と税務上の償却限度額の比較を別途計算しなければならない。
多数資産処理の非効率性 決算シーズンには数十件の資産を繰り返し計算しなければならない。
業種別比較検討の難しさ 同一資産を異なる業種基準で検討する場合、手作業が多くなる。

3. 目標ユーザー

ユーザーグループ	主要資産	主要ニーズ
病院・医療機関総務チーム	医療機器、建物附属設備、車両	高額資産の耐用年数および償却方法の検討
製造業会計チーム	機械装置、工場設備、車両	定率法基準の計算と税務調整
IT・サービス企業総務チーム	サーバー、ネットワーク機器、ソフトウェア、家具	資産分類および耐用年数の標準化
中小企業代表/経理	車両、備品、事務設備	迅速かつミスのない基準計算
決算担当者	多数資産ポートフォリオ	一括計算および要約表の確認

4. 主要ユーザーシナリオ (PRD第6章)

シナリオA — 医療機器の耐用年数照会

ユーザー:

「MRI装置を医療業基準で見ると、耐用年数は何年か教えて。」

処理フロー

get_useful_life を呼び出し
Q86 + 医療機器基準を照会
基準耐用年数、許容範囲、償却方法、法的根拠を返却

シナリオB — 単一資産の減価償却計算

ユーザー:

「取得価額15億、取得日2026-03-01、耐用年数5年で減価償却スケジュールを計算して。」

処理フロー

calc_depreciation_schedule を呼び出し
定額法/定率法/生産高比例法のうち該当方式で計算
年度別の減価償却費、帳簿価額、累積額を返却

シナリオC — 税務調整計算

ユーザー:

「会計上の減価償却費と税務上の償却限度額の差を教えて。」

処理フロー

calc_tax_adjustment を呼び出し
損金不算入額、認容不足額、追認可能額を計算
説明メモと共に返却

シナリオD — 決算シーズンにおける多数資産の一括処理

ユーザー:

「資産50件を一度に計算して、年間減価償却費と損金不算入額を要約して。」

処理フロー

calc_bulk_depreciation を呼び出し
資産ごとに計算を実行
総減価償却費、総税務限度額、総損金不算入額の要約を返却

シナリオE — 業種間比較

ユーザー:

「同じサーバー機器を、医療業とソフトウェア業の基準で比較して。」

処理フロー

compare_industry_life を呼び出し
業種別の耐用年数および年度別の減価償却差を比較
比較表を返却

Related MCP server: ko-stock-mcp

要件

Node.js 20以上
pnpm 9以上 (または npm/corepack で pnpm を有効化)

インストール (共通)

リポジトリをクローンした後、依存関係のインストールとビルドを行います。

git clone https://github.com/boam79/depreciation-mcp.git
cd depreciation-mcp
pnpm install
pnpm run build

ビルド終了後、実行ファイルは dist/index.js です。 (dist/ はリポジトリに含まれていないため、必ずローカルで pnpm run build が必要)

開発モード (ビルドなしで実行)

pnpm exec tsx src/index.ts

Cursor AIへの接続方法

1) グローバルMCP設定ファイル

Cursorで Settings → MCP に移動するか、設定JSONを直接開きます。
macOSでのユーザーMCP設定は通常以下のパスです。 ~/.cursor/mcp.json
mcpServers 内に以下のブロックを追加します。 args のパスは、自身のPCでクローン・ビルドしたフォルダの絶対パスに変更してください。

{
  "mcpServers": {
    "depreciation-mcp": {
      "command": "node",
      "args": ["/절대경로/depreciation-mcp/dist/index.js"]
    }
  }
}

例 (ダウンロードフォルダに置いた場合):

"depreciation-mcp": {
  "command": "node",
  "args": ["/Users/본인계정/Downloads/depreciation-mcp/dist/index.js"]
}

Cursorを完全に終了してから再起動します。
チャットのMCPツールリストに get_useful_life、calc_depreciation_schedule などが表示されれば接続完了です。

2) プロジェクト専用 (選択)

プロジェクトルートの .cursor/mcp.json を使用するワークスペースであれば、同じJSONをそのファイルに記述できます。(CursorのバージョンによりUIパスが異なる場合があります。)

3) ビルドなしで `tsx` を使用して接続 (選択)

"depreciation-mcp": {
  "command": "pnpm",
  "args": ["exec", "tsx", "/절대경로/depreciation-mcp/src/index.ts"],
  "cwd": "/절대경로/depreciation-mcp"
}

Claude Desktopへの接続方法 (macOS)

Claude Desktopを終了します。
設定ファイルを開きます。 ~/Library/Application Support/Claude/claude_desktop_config.json
最上位に mcpServers がなければ作成し、以下を追加します。

{
  "mcpServers": {
    "depreciation-mcp": {
      "command": "node",
      "args": ["/절대경로/depreciation-mcp/dist/index.js"]
    }
  }
}

ファイルを保存し、Claude Desktopを再起動します。
新しい会話でMCPツールが露出されるか確認します。

Windowsユーザーは、Claude公式ドキュメントの設定ファイルパスを確認した後、同様に command / args を合わせれば動作します。

提供ツール (6種)

ツール	説明
`get_useful_life`	資産タイプ・業種・建物構造基準の耐用年数・許容範囲・基本償却方式
`calc_depreciation_schedule`	定額・定率・生産高比例スケジュール
`calc_tax_adjustment`	会計 vs 税務限度額の差 (損金不算入・認容不足・追認の単純モデル)
`list_asset_categories`	資産分類リスト
`calc_bulk_depreciation`	最大100件の一括・要約計算
`compare_industry_life`	業種別の耐用年数・償却比較

スクリプト

コマンド	説明
`pnpm run build`	TypeScript → `dist/`
`pnpm start`	`node dist/index.js` (stdio MCP)
`pnpm run dev`	`tsx src/index.ts`
`pnpm test`	Vitest
`pnpm smoke`	stdio接続・ツール6種・`get_useful_life` サンプル呼び出し検証

接続テスト (ローカル)

ビルド後、プロジェクトルートで:

pnpm smoke

OK: listTools および OK: get_useful_life が表示されれば、MCPサーバープロセスとプロトコルは正常です。

データについて

src/data/annex5.ts、annex6.ts などは実務補助用の要約データです。法令改正時は内容を更新し、pnpm test で検証してください。

リポジトリ

https://github.com/boam79/depreciation-mcp

Available Tools

6 tools

calc_bulk_depreciation일괄 감가상각C

최대 100건, 회계 스케줄 vs 세무 기본 스케줄로 당기 손금부인 등 요약

ParametersJSON Schema

Name	Required	Description
`assets`	Yes	자산 목록
`fiscal_year`	Yes
`output_format`	No

TDQS

C2.6/5.0

Behavior2/5

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

Description provides minimal behavioral context: limit of 100 assets, comparison of accounting vs tax schedules, and a summary output. No disclosure of whether the tool mutates data, requires authentication, or any side effects. Since no annotations exist, the description should carry the full burden but fails to cover key traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence, very concise, but it omits structure like a separate purpose statement or parameter details. It is not excessively long, but the brevity sacrifices completeness. A more structured format would improve usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, nested objects, and no output schema, the description lacks crucial details: what the summary contains, how to interpret the output, and any prerequisites. The tool is moderately complex but the description does not adequately inform an agent how to use it or what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 3 parameters with only 33% description coverage (only 'assets' has label '자산 목록'). The tool description adds no parameter-level context; it does not explain fiscal_year or output_format beyond the enum values. Despite low coverage, the description does not compensate, leaving parameter semantics unclear.

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?

Description indicates bulk depreciation calculation for up to 100 assets, comparing accounting and tax schedules, producing a summary including tax deduction denial. This differentiates from sibling tools like calc_depreciation_schedule (likely single asset) and calc_tax_adjustment (likely more detailed adjustment). However, the phrasing '등 요약' is vague, slightly reducing clarity.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not-to-use guidance. No mention of alternatives or prerequisites. The description implies bulk usage via '최대 100건' but does not clarify when to choose this tool over calc_depreciation_schedule or calc_tax_adjustment.

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

calc_depreciation_schedule감가상각 스케줄B

단일 자산의 정액법·정률법·생산량비례법 스케줄(연도별)

ParametersJSON Schema

Name	Required	Description
`asset_name`	Yes	자산명
`asset_type`	Yes	자산 유형(내용연수 자동참조 시 사용)
`industry_code`	No
`cost`	Yes	취득가액
`acquired_date`	Yes	취득일 YYYY-MM-DD
`method`	No	미입력 시 내용연수 조회 결과의 기본 상각방식
`useful_life_years`	No	미입력 시 업종·자산 기준 표준 내용연수
`total_units`	No
`current_units`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so description carries full burden. It only states the calculation without disclosing side effects, permissions, output format, or behavior on invalid inputs. Minimal transparency for a tool with 9 parameters.

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?

Single sentence, front-loaded with key info (single asset, methods, yearly). Every word is functional, but could be slightly expanded for clarity without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and no output schema, the description fails to explain the schedule's structure (e.g., yearly breakdown columns, totals) or return format. Lacks completeness for a tool of this complexity.

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 67% (6 of 9 parameters have descriptions). The description does not add meaning beyond schema; it merely lists methods. No explanation of parameter interplay or defaults.

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?

Description explicitly states single asset and three depreciation methods (정액법·정률법·생산량비례법) and yearly schedule. The name and description contrast with sibling `calc_bulk_depreciation`, clearly differentiating scope.

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?

The description implies single-asset usage but does not explicitly state when to choose this over siblings like `calc_bulk_depreciation` or `compare_industry_life`. No when-not or alternative guidance provided.

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

calc_tax_adjustment세무조정 참고B

회계 감가상각비 vs 세무 상각범위액 → 손금부인·시인부족·추인(단순모형)

ParametersJSON Schema

Name	Required	Description
`book_depreciation`	Yes
`tax_limit`	Yes
`carried_over_denial`	No	전기 이월 손금부인액

TDQS

B3.2/5.0

Behavior2/5

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 mentions the tool computes specific adjustments but does not disclose side effects, return format, error handling, or assumptions. The description is minimal and lacks behavioral details.

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 very concise, capturing the core purpose in a single line. However, it is not structured to highlight parameter usage or provide additional context. It is front-loaded but benefits could be improved with parameter mapping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, how to use the carried_over_denial parameter, or any assumptions of the simple model. Context is lacking for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one of three parameters has a description in the schema, and the description does not explain any parameters. The Korean text hints at book depreciation and tax limit but does not map explicitly to the schema parameters. With low schema coverage (33%), the description fails to compensate.

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 clearly states the tool compares accounting depreciation vs tax depreciation limit and computes adjustments like denial, shortfall, and carryforward. It distinguishes from sibling tools like calc_bulk_depreciation and calc_depreciation_schedule which focus on different aspects of depreciation.

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?

The description implies usage for tax adjustment calculations but does not explicitly state when to use this tool versus alternatives like calc_bulk_depreciation or get_useful_life. No guidance on prerequisites or exclusions is provided.

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

compare_industry_life업종 간 내용연수·상각 비교B

동일 자산·취득가에 대해 업종별 표준 내용연수 및 1년차·5년 누적 상각(비교용)

ParametersJSON Schema

Name	Required	Description	Default
`asset_type`	Yes
`cost`	Yes
`industry_codes`	Yes
`method`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description only states what the tool does without disclosing behavioral traits such as output format, precision, or any side effects. The description does not compensate for the missing annotations.

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 a single concise sentence that front-loads the purpose. However, it could be slightly more structured by including parameter information without being overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description lacks completeness. It does not explain the output format, how results are presented for multiple industries, or additional context needed for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description only vaguely mentions 'asset and acquisition cost' and 'by industry', failing to provide meaningful details about the four parameters, their enumerations, or how to use them.

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 title and description explicitly state the tool compares standard useful life and depreciation across industries for a given asset and cost. It clearly differentiates from siblings like calc_depreciation_schedule (full schedule) and get_useful_life (single value).

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?

The description implies the use case of cross-industry comparison but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

get_useful_life내용연수 조회B

자산 유형·업종·건물구조 기준 기준내용연수·허용범위·기본 상각방식·법적근거

ParametersJSON Schema

Name	Required	Description
`asset_type`	Yes	자산 유형
`industry_code`	No	KSIC 스타일 코드 (예: Q86, J62). 미입력 시 별표5 공통
`structure`	No	건물(asset_type=building)일 때 구조

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It does not explicitly state that the tool is read-only, nor does it disclose behavior for missing inputs or errors. The description only lists outputs without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the key criteria and outputs. No unnecessary words; every element earns its place.

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?

For a retrieval tool with no output schema, the description lists the four output fields (standard useful life, allowable range, default depreciation method, legal basis), which is fairly complete. Missing details on output format or typical use cases, but overall adequate for simple lookup.

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?

Input schema has 100% description coverage, so baseline is 3. The description adds little beyond the schema; it repeats the criteria but does not explain output format or parameter interactions beyond what the schema already 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?

The description clearly states the criteria (asset type, industry, building structure) and outputs (standard useful life, allowable range, default depreciation method, legal basis). It distinguishes from sibling calculation tools by being a retrieval tool, but could explicitly state 'lookup' or 'retrieve' for clarity.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The sibling tools are all calculation-oriented (calc_bulk_depreciation, etc.), but the description does not explicitly direct the agent to use get_useful_life for retrieval and the others for computations.

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

list_asset_categories자산 분류 목록B

업종별(또는 공통) 자산 분류·내용연수·상각률 요약

ParametersJSON Schema

Name	Required	Description	Default
`industry_code`	No
`asset_filter`	No
`show_rates`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral details such as read-only nature, default behavior with empty parameters, or the scope of data returned. This is a significant gap for a list tool.

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 a single concise sentence that front-loads the key purpose. However, it could be more structured with details, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of schema descriptions, annotations, and output schema, the description is far from complete. It does not explain parameter usage, output format, or provide enough context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% coverage with no descriptions, and the tool description does not explain any parameter semantics (e.g., industry_code format, asset_filter enum meaning, show_rates effect). The description adds no value beyond parameter names.

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 clearly states it provides a summary of asset classifications, useful lives, and depreciation rates by industry (or common), which distinguishes it from sibling calculation tools.

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?

No explicit guidance on when to use this tool versus alternatives like calc_depreciation_schedule. Usage is implied as a lookup tool, but no when-not or alternative recommendations are given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0May 3, 2026
- First observedcalc_bulk_depreciation
- First observedcalc_depreciation_schedule
- First observedcalc_tax_adjustment
- First observedcompare_industry_life
- First observedget_useful_life
- First observedlist_asset_categories

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-05-03 01:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct function: bulk calculation, single schedule, tax adjustment, industry comparison, useful life lookup, and category listing. No overlap in purpose.

Naming Consistency5/5

All tools use snake_case with a consistent verb_noun pattern (calc_, compare_, get_, list_). No mixing of conventions.

Tool Count5/5

6 tools is well-scoped for a depreciation-focused server, covering core calculations, lookups, and comparisons without being excessive.

Completeness4/5

Covers key operations: schedule calculation, bulk processing, tax adjustment, useful life retrieval, and category listing. Minor gap: no explicit method for depreciation method enumeration, but still highly functional for its purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

asset-register A
io.github.theluckystrike
Fixed assets and depreciation from bundled Polish KST, HMRC and IRS MACRS tables.
Finance ERP Systems
91
XBOSS B
kr.xdata
Korean national tax and social insurance filings, invoices and payroll data as MCP tools.
Finance ERP Systems Payments & Billing
2661
MyDART A
kr.eocpa
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Finance Legal & Compliance Open Data
151
MyKIFRS A
kr.eocpa
Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
Search Documentation Access
62

Related MCP Servers

taxlaw-nts-mcp
Government Data Legal & Compliance Search
kim-go-chon
A
license
A
quality
B
maintenance
Enables searching and retrieving tax law data from the Korean National Tax Service database, including interpretations, rulings, forms, publications, and site menus via MCP tools.
Updated a month ago (2026-09-10 05:24 UTC)
14
1
MIT
ko-stock-mcp
Finance Government Data
okdoittttt
A
license
A
quality
D
maintenance
Provides Korean stock market data, including DART electronic disclosures and KRX trading information, enabling users to query company profiles, financial statements, and stock trade details via MCP clients.
Updated 3 months ago (2026-07-04 01:58 UTC)
9
MIT
mcp-finance-tools
Finance
jack200250-collab
F
license
A
quality
D
maintenance
Provides Korean-specific financial calculators (4 insurances, salary net, severance pay, capital gains tax, DSR/DTI, FX conversion, housing subscription score) as MCP tools for AI agents.
Updated 3 months ago (2026-07-12 03:22 UTC)
7
-
kasb-accounting-mcp
Legal & Compliance Search Databases
myheart9393-svg
F
license
Not graded
quality
B
maintenance
MCP server for searching and retrieving Korean accounting standards (K-IFRS, general corporate accounting standards) and Q&A summaries from the KASB database. Provides four tools: keyword search of standards and Q&As, real-time full text of standards, and cached Q&A details.
Updated 11 days ago (2026-10-04 22:11 UTC)
-

depreciation-mcp

PRD背景 (MCP-DEP-001-v1)

1. プロジェクト概要

2. 問題定義

2.1 現在の実務における不便さ

3. 目標ユーザー

4. 主要ユーザーシナリオ (PRD第6章)

シナリオA — 医療機器の耐用年数照会

シナリオB — 単一資産の減価償却計算

シナリオC — 税務調整計算

シナリオD — 決算シーズンにおける多数資産の一括処理

シナリオE — 業種間比較

要件

インストール (共通)

開発モード (ビルドなしで実行)

Cursor AIへの接続方法

1) グローバルMCP設定ファイル

2) プロジェクト専用 (選択)

3) ビルドなしで tsx を使用して接続 (選択)

Claude Desktopへの接続方法 (macOS)

提供ツール (6種)

スクリプト

接続テスト (ローカル)

データについて

リポジトリ

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

3) ビルドなしで `tsx` を使用して接続 (選択)