How do I use depreciation-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@depreciation-mcp calculate depreciation schedule for a server acquired for 50 million won on 2024-01-15 with a 3-year useful life" 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.

de en es ja ko ru zh

depreciation-mcp

by boam79

Overview Schema Related Servers Score Discussions

TypeScript

Local

depreciation-mcp

A server that provides fixed asset useful life, depreciation, and tax adjustment reference values based on the Corporate Tax Act via the Model Context Protocol (MCP).

Calculation results are for reference only. Reporting and accounting treatments require application of relevant laws, facts, and professional review.

PRD Background (MCP-DEP-001-v1)

The following Project Overview, Problem Definition, Target Users, and Key User Scenarios are adapted from Chapters 1, 2, 3, and 6 of the PRD Facility Depreciation Calculation MCP v1.0 (Revised) for this README.

1. Project Overview

Fixed asset depreciation is a core practical task performed repeatedly during closing and corporate tax filing. However, the following problems recur in the field:

Users must manually look up Enforcement Rules [Table 5 & 6] to verify useful life by asset type.
Accounting or general affairs teams rely on spreadsheet formulas for calculations.
Tasks are cumbersome because selecting the straight-line/declining-balance method, reviewing useful life ranges, and calculating tax adjustments are disconnected.
Consistency is low because decision criteria are not documented when personnel change.

This MCP aims to standardize this process, providing a consistent flow from looking up useful life based on the Corporate Tax Act → calculating depreciation → tax adjustment reference values → batch processing and comparative analysis once the user inputs asset information.

2. Problem Definition

2.1 Inconveniences in Current Practice

Repetitiveness of Legal Research Asset classification and standard years by industry must be manually checked every time.
Inconsistency in Calculation The same asset may be subject to different useful lives or calculation formulas depending on the person in charge.
Disconnected Management of Tax Adjustments Accounting depreciation expenses and tax-deductible limit amounts must be calculated separately.
Inefficiency in Processing Multiple Assets During the closing season, dozens of assets must be calculated repeatedly.
Difficulty in Comparative Review by Industry There is a lot of manual work involved in reviewing the same asset based on different industry standards.

3. Target Users

User Group	Key Assets	Key Needs
Hospital/Medical Institution Admin Team	Medical equipment, building attachments, vehicles	Review of useful life and depreciation methods for high-value assets
Manufacturing Accounting Team	Machinery, factory equipment, vehicles	Declining-balance method calculations and tax adjustments
IT/Service Company Admin Team	Servers, network equipment, software, furniture	Standardization of asset classification and useful life
SME Owner/Accountant	Vehicles, fixtures, office equipment	Fast and error-free standard calculations
Closing Manager	Large asset portfolios	Batch calculation and summary table verification

4. Key User Scenarios (PRD Chapter 6)

Scenario A — Looking up Useful Life for Hospital Equipment

User:

"Tell me the useful life of MRI equipment based on the medical industry."

Process Flow

Call get_useful_life
Look up Q86 + medical device criteria
Return standard useful life, allowable range, depreciation method, and legal basis

Scenario B — Single Asset Depreciation Calculation

User:

"Calculate the depreciation schedule for an acquisition cost of 1.5 billion KRW, acquisition date 2026-03-01, and a useful life of 5 years."

Process Flow

Call calc_depreciation_schedule
Calculate using the appropriate method (Straight-line/Declining-balance/Production-based)
Return annual depreciation expense, book value, and accumulated amount

Scenario C — Tax Adjustment Calculation

User:

"Tell me the difference between accounting depreciation and tax-deductible limits."

Process Flow

Call calc_tax_adjustment
Calculate non-deductible expenses, insufficient depreciation, and deductible amounts
Return with explanatory notes

Scenario D — Batch Processing of Multiple Assets during Closing Season

User:

"Calculate 50 assets at once and summarize the annual depreciation expense and non-deductible expenses."

Process Flow

Call calc_bulk_depreciation
Perform calculations per asset
Return summary of total depreciation, total tax limit, and total non-deductible expenses

Scenario E — Comparison Between Industries

User:

"Compare the same server equipment based on medical industry vs. software industry standards."

Process Flow

Call compare_industry_life
Compare useful life and annual depreciation differences by industry
Return comparison table

Related MCP server: OpenKRX MCP Server

Requirements

Node.js 20 or higher
pnpm 9 or higher (or enable pnpm via npm/corepack)

Installation (Common)

Clone the repository and proceed with dependency installation and build.

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

Once the build is complete, the executable file is dist/index.js. (dist/ is not included in the repository, so you must run pnpm run build locally)

Development Mode (Run without build)

pnpm exec tsx src/index.ts

How to Connect to Cursor AI

1) Global MCP Configuration File

In Cursor, go to Settings → MCP or open the configuration JSON directly.
On macOS, the user MCP configuration is usually at: ~/.cursor/mcp.json
Add the block below inside mcpServers. Change the path in args to the absolute path of the folder you cloned and built on your PC.

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

Example (if placed in the Downloads folder):

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

Completely exit and restart Cursor.
If you see get_useful_life, calc_depreciation_schedule, etc., in the MCP tool list in chat, it is connected.

2) Project-Specific (Optional)

If you are using a workspace that uses .cursor/mcp.json in the project root, you can put the same JSON in that file. (UI paths may vary depending on the Cursor version.)

3) Connect via `tsx` without build (Optional)

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

How to Connect to Claude Desktop (macOS)

Exit Claude Desktop.
Open the configuration file: ~/Library/Application Support/Claude/claude_desktop_config.json
If mcpServers does not exist at the top level, create it and add the following:

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

Save the file and restart Claude Desktop.
Check if the MCP tools are exposed in a new chat.

Windows users should check the configuration file path in the official Claude documentation and match the command / args accordingly.

Provided Tools (6)

Tool	Description
`get_useful_life`	Useful life, allowable range, and basic depreciation method based on asset type/industry/building structure
`calc_depreciation_schedule`	Straight-line, declining-balance, production-based schedules
`calc_tax_adjustment`	Accounting vs. tax limit difference (simple model for non-deductible/insufficient/deductible)
`list_asset_categories`	List of asset categories
`calc_bulk_depreciation`	Batch/summary for up to 100 items
`compare_industry_life`	Useful life/depreciation comparison by industry

Scripts

Command	Description
`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`	Verify stdio connection, 6 tools, and `get_useful_life` sample call

Connection Test (Local)

After building, in the project root:

pnpm smoke

If OK: listTools and OK: get_useful_life appear, the MCP server process and protocol are normal.

About Data

src/data/annex5.ts, annex6.ts, etc., are summary data for practical assistance. Update the content when laws are revised and verify with pnpm test.

Repository

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MyDART A
kr.eocpa
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Finance Legal & Compliance Open Data
161
APICK Business A
app.apick
Korean business registry, corporate info, parcel tracking, validation APIs
Government Data Open Data
1611
Finance Fintech Mcp A
io.github.varvararatta
Unlock the power of real-time financial data with our Finance MCP. Easily retrieve the latest
Finance Search
42
APICK Identity A
app.apick
Korean ID document verification and PII masking APIs
Security Legal & Compliance
1611

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-08-07 17:03 UTC)
14
1
MIT
OpenKRX MCP Server
Finance Open Data
RealYoungk
A
license
Not graded
quality
D
maintenance
Provides Korean Exchange (KRX) Open API data as MCP tools, supporting 31 APIs for indices, stocks, ETP, bonds, derivatives, commodities, and ESG.
Updated 6 months ago (2026-02-20 13:06 UTC)
1
MIT
ko-stock-mcp
Finance Government Data
okdoittttt
A
license
A
quality
C
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 2 months ago (2026-07-04 01:58 UTC)
9
MIT
mcp-finance-tools
Finance
jack200250-collab
F
license
A
quality
C
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 2 months ago (2026-07-12 03:22 UTC)
7

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/boam79/depreciation-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

depreciation-mcp

PRD Background (MCP-DEP-001-v1)

1. Project Overview

2. Problem Definition

2.1 Inconveniences in Current Practice

3. Target Users

4. Key User Scenarios (PRD Chapter 6)

Scenario A — Looking up Useful Life for Hospital Equipment

Scenario B — Single Asset Depreciation Calculation

Scenario C — Tax Adjustment Calculation

Scenario D — Batch Processing of Multiple Assets during Closing Season

Scenario E — Comparison Between Industries

Requirements

Installation (Common)

Development Mode (Run without build)

How to Connect to Cursor AI

1) Global MCP Configuration File

2) Project-Specific (Optional)

3) Connect via tsx without build (Optional)

How to Connect to Claude Desktop (macOS)

Provided Tools (6)

Scripts

Connection Test (Local)

About Data

Repository

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

3) Connect via `tsx` without build (Optional)