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

Ein Server, der Referenzwerte für die Nutzungsdauer, Abschreibung und steuerliche Anpassung von Anlagevermögen gemäß dem Körperschaftsteuergesetz über das Model Context Protocol (MCP) bereitstellt.

Die Berechnungsergebnisse dienen nur zu Referenzzwecken. Für Steuererklärungen und Buchhaltungszwecke sind die geltenden Gesetze, die tatsächlichen Gegebenheiten und eine fachliche Prüfung erforderlich.

PRD-Hintergrund (MCP-DEP-001-v1)

Die folgenden Projektübersicht, Problemdefinition, Zielgruppe und Kern-Benutzerszenarien sind eine Übernahme der Kapitel 1, 2, 3 und 6 des PRD MCP für die Anlagenabschreibungsberechnung v1.0 (überarbeitete Fassung) für diese README.

1. Projektübersicht

Die Abschreibung von Anlagevermögen ist eine zentrale Aufgabe, die bei Jahresabschlüssen und Körperschaftsteuererklärungen wiederholt durchgeführt wird. In der Praxis treten jedoch regelmäßig folgende Probleme auf:

Man muss die Durchführungsverordnung [Anhang 5·6] manuell nachschlagen, um die Nutzungsdauer nach Anlageart zu ermitteln.
Buchhaltungs- oder Verwaltungsteams verlassen sich bei der Berechnung auf Tabellenkalkulationsformeln.
Die Auswahl zwischen linearer/degressiver Abschreibung, die Prüfung des Nutzungsdauerbereichs und die Berechnung steuerlicher Anpassungen sind voneinander getrennt, was den Arbeitsaufwand erhöht.
Bei einem Wechsel des zuständigen Mitarbeiters gehen die Entscheidungsgrundlagen verloren, was die Konsistenz beeinträchtigt.

Dieses MCP zielt darauf ab, diesen Prozess zu standardisieren, sodass der Benutzer nach Eingabe der Anlagendaten konsistent folgende Ergebnisse erhält: Abfrage der Nutzungsdauer gemäß Körperschaftsteuergesetz → Abschreibungsberechnung → Referenzwerte für steuerliche Anpassungen → Stapelverarbeitung und Vergleichsanalyse.

2. Problemdefinition

2.1 Unannehmlichkeiten in der aktuellen Praxis

Wiederholte gesetzliche Abfragen Die Anlagenklassifizierung und die branchenspezifischen Standardnutzungsdauern müssen jedes Mal manuell überprüft werden.
Inkonsistenz bei Berechnungen Für denselben Vermögenswert können je nach zuständigem Mitarbeiter unterschiedliche Nutzungsdauern oder Berechnungsmethoden angewendet werden.
Getrennte Verwaltung steuerlicher Anpassungen Die Abschreibung nach Handelsrecht und die steuerliche Abschreibungsgrenze müssen separat berechnet werden.
Ineffizienz bei der Verarbeitung vieler Vermögenswerte Während der Abschlussperiode müssen Dutzende von Vermögenswerten wiederholt berechnet werden.
Schwierigkeiten beim branchenspezifischen Vergleich Der Vergleich desselben Vermögenswerts auf Basis verschiedener Branchen erfordert viel manuelle Arbeit.

3. Zielgruppe

Benutzergruppe	Hauptvermögenswerte	Hauptbedürfnisse
Verwaltungsteam von Krankenhäusern/medizinischen Einrichtungen	Medizinische Geräte, Gebäudeausstattung, Fahrzeuge	Prüfung der Nutzungsdauer und Abschreibungsmethode für teure Anlagen
Buchhaltungsteam in der Fertigung	Maschinen, Fabrikanlagen, Fahrzeuge	Berechnung nach degressiver Methode und steuerliche Anpassung
Verwaltungsteam von IT-/Dienstleistungsunternehmen	Server, Netzwerkgeräte, Software, Möbel	Standardisierung von Anlagenklassifizierung und Nutzungsdauer
Geschäftsführer/Buchhalter in KMUs	Fahrzeuge, Einrichtungsgegenstände, Büroausstattung	Schnelle und fehlerfreie Standardberechnung
Verantwortliche für den Jahresabschluss	Portfolio mit vielen Vermögenswerten	Stapelberechnung und Überprüfung der Zusammenfassung

4. Kern-Benutzerszenarien (PRD Kapitel 6)

Szenario A — Abfrage der Nutzungsdauer für medizinische Geräte

Benutzer:

„Sag mir, wie viele Jahre die Nutzungsdauer für ein MRT-Gerät in der Medizinbranche beträgt.“

Prozessablauf

Aufruf von get_useful_life
Abfrage basierend auf Q86 + medizinische Geräte
Rückgabe der Standardnutzungsdauer, des zulässigen Bereichs, der Abschreibungsmethode und der gesetzlichen Grundlage

Szenario B — Abschreibungsberechnung für einen einzelnen Vermögenswert

Benutzer:

„Berechne den Abschreibungsplan für einen Anschaffungswert von 1,5 Mrd. KRW, Anschaffungsdatum 01.03.2026, Nutzungsdauer 5 Jahre.“

Prozessablauf

Aufruf von calc_depreciation_schedule
Berechnung nach linearer/degressiver/leistungsbezogener Methode
Rückgabe der jährlichen Abschreibung, des Buchwerts und des kumulierten Betrags

Szenario C — Berechnung steuerlicher Anpassungen

Benutzer:

„Zeig mir den Unterschied zwischen der buchhalterischen Abschreibung und der steuerlichen Abschreibungsgrenze.“

Prozessablauf

Aufruf von calc_tax_adjustment
Berechnung des nicht abzugsfähigen Aufwands, des unzureichenden Abschreibungsbetrags und des nachholbaren Betrags
Rückgabe zusammen mit einer erläuternden Notiz

Szenario D — Stapelverarbeitung vieler Vermögenswerte zur Abschlusszeit

Benutzer:

„Berechne 50 Vermögenswerte auf einmal und fasse die jährliche Abschreibung sowie den nicht abzugsfähigen Aufwand zusammen.“

Prozessablauf

Aufruf von calc_bulk_depreciation
Durchführung der Berechnung pro Vermögenswert
Rückgabe der Zusammenfassung der gesamten Abschreibung, der gesamten steuerlichen Grenze und des gesamten nicht abzugsfähigen Aufwands

Szenario E — Branchenvergleich

Benutzer:

„Vergleiche denselben Server basierend auf der Medizinbranche und der Softwarebranche.“

Prozessablauf

Aufruf von compare_industry_life
Vergleich der Nutzungsdauer und der jährlichen Abschreibungsunterschiede nach Branche
Rückgabe einer Vergleichstabelle

Related MCP server: ko-stock-mcp

Anforderungen

Node.js 20 oder höher
pnpm 9 oder höher (oder Aktivierung von pnpm über npm/corepack)

Installation (Allgemein)

Nach dem Klonen des Repositorys werden die Abhängigkeiten installiert und der Build-Prozess gestartet.

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

Nach Abschluss des Builds befindet sich die ausführbare Datei unter dist/index.js. (dist/ ist nicht im Repository enthalten, daher ist ein lokaler pnpm run build zwingend erforderlich)

Entwicklungsmodus (Ausführung ohne Build)

pnpm exec tsx src/index.ts

Verbindung mit Cursor AI

1) Globale MCP-Konfigurationsdatei

Gehen Sie in Cursor zu Settings → MCP oder öffnen Sie die Konfigurations-JSON direkt.
Unter macOS befindet sich die Benutzer-MCP-Konfiguration normalerweise unter: ~/.cursor/mcp.json
Fügen Sie den folgenden Block innerhalb von mcpServers hinzu. Der Pfad in args muss durch den absoluten Pfad des auf Ihrem PC geklonten/gebauten Ordners ersetzt werden.

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

Beispiel (falls im Download-Ordner abgelegt):

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

Cursor vollständig beenden und neu starten.
Wenn in der Chat-Oberfläche in der Liste der MCP-Tools get_useful_life, calc_depreciation_schedule usw. erscheinen, ist die Verbindung erfolgreich.

2) Projektspezifisch (optional)

Wenn Sie einen Workspace mit einer .cursor/mcp.json im Projektstammverzeichnis verwenden, können Sie dieselbe JSON-Struktur dort einfügen. (Der UI-Pfad kann je nach Cursor-Version variieren.)

3) Verbindung über `tsx` ohne Build (optional)

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

Verbindung mit Claude Desktop (macOS)

Claude Desktop beenden.
Konfigurationsdatei öffnen: ~/Library/Application Support/Claude/claude_desktop_config.json
Falls mcpServers nicht existiert, erstellen Sie es und fügen Sie Folgendes hinzu:

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

Datei speichern und Claude Desktop neu starten.
Überprüfen Sie in einem neuen Chat, ob die MCP-Tools angezeigt werden.

Windows-Benutzer sollten den Pfad zur Konfigurationsdatei in der offiziellen Claude-Dokumentation prüfen und dann entsprechend command / args anpassen.

Verfügbare Tools (6)

Tool	Beschreibung
`get_useful_life`	Nutzungsdauer, zulässiger Bereich, Standard-Abschreibungsmethode basierend auf Anlagenart/Branche/Gebäudestruktur
`calc_depreciation_schedule`	Plan für lineare/degressive/leistungsbezogene Abschreibung
`calc_tax_adjustment`	Differenz zwischen Buchhaltung und steuerlicher Grenze (einfaches Modell für nicht abzugsfähigen Aufwand, unzureichende Abschreibung, Nachholung)
`list_asset_categories`	Liste der Anlagenkategorien
`calc_bulk_depreciation`	Stapelverarbeitung/Zusammenfassung von bis zu 100 Objekten
`compare_industry_life`	Vergleich von Nutzungsdauer und Abschreibung nach Branche

Skripte

Befehl	Beschreibung
`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`	Überprüfung der stdio-Verbindung, der 6 Tools und Beispielaufruf von `get_useful_life`

Verbindungstest (lokal)

Nach dem Build im Projektstammverzeichnis:

pnpm smoke

Wenn OK: listTools und OK: get_useful_life erscheinen, sind der MCP-Server-Prozess und das Protokoll in Ordnung.

Über die Daten

src/data/annex5.ts, annex6.ts usw. sind Zusammenfassungsdaten zur Unterstützung der Praxis. Aktualisieren Sie die Inhalte bei Gesetzesänderungen und überprüfen Sie diese mit 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.

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-Hintergrund (MCP-DEP-001-v1)

1. Projektübersicht

2. Problemdefinition

2.1 Unannehmlichkeiten in der aktuellen Praxis

3. Zielgruppe

4. Kern-Benutzerszenarien (PRD Kapitel 6)

Szenario A — Abfrage der Nutzungsdauer für medizinische Geräte

Szenario B — Abschreibungsberechnung für einen einzelnen Vermögenswert

Szenario C — Berechnung steuerlicher Anpassungen

Szenario D — Stapelverarbeitung vieler Vermögenswerte zur Abschlusszeit

Szenario E — Branchenvergleich

Anforderungen

Installation (Allgemein)

Entwicklungsmodus (Ausführung ohne Build)

Verbindung mit Cursor AI

1) Globale MCP-Konfigurationsdatei

2) Projektspezifisch (optional)

3) Verbindung über tsx ohne Build (optional)

Verbindung mit Claude Desktop (macOS)

Verfügbare Tools (6)

Skripte

Verbindungstest (lokal)

Über die Daten

Repository

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

3) Verbindung über `tsx` ohne Build (optional)