Content
# Tool List
## tsugu-mcp
A tool for generating inheritance documents in Go. Outputs the following PDFs from JSON: date display in Japanese calendar (`-era` for switching).
- **Family Relationship Chart**(1 page): Left-to-right horizontal family tree, individuals are represented by `(relationship) name` without frames, marriages are represented by vertical double lines, and parent-child relationships are represented by bracket lines. The decedent's details (last address, registered domicile, birth, and death) are on the left, creation date and creator are at the bottom left, and "余白" (margin) is at the bottom right.
- **Inheritance Registration Application**(multiple pages): A broken line frame for the reception number at the top of the first page, followed by the registration purpose, cause, heirs, applicants (multiple + shares), attached information, application date, taxable value, and registration tax. Then, the description of the property (land/building/condominium) is inserted. If there are many properties, the pages are automatically turned.
- **Division Agreement**(multiple pages): The decedent, co-heirs, acquisition correspondence (acquirer + share), and property/assets are inserted into the text, and a signature and seal column is added at the end.
- **Division Certificate**(one page per heir): An individual document type where each heir certifies acquisition. The decedent, acquirer, co-heirs, and all participants' information are generated.
## Usage
### CLI
```sh
go build -o tsugu ./cmd/tsugu
./tsugu chart -in testdata/sample_full.json -out chart.pdf # Family Relationship Chart
./tsugu touki -in testdata/touki_sample.json -out touki.pdf # Inheritance Registration Application
./tsugu bunkatsu -in testdata/bunkatsu_sample.json -out bunkatsu.pdf # Division Agreement
./tsugu certificate -in testdata/certificate_sample.json -out cert.pdf # Division Certificate
./tsugu chart -era both < family.json > chart.pdf # Standard input/output / Western calendar notation
```
Subcommands `chart` (Family Relationship Chart) / `touki` (Inheritance Registration Application) / `bunkatsu` (Division Agreement) / `certificate` (Division Certificate). Each has common flags:
| Flag | Default | Description |
|--------|------|------|
| `-in` | Standard input | Input JSON path |
| `-out` | Standard output | Output PDF path |
| `-era` | `wareki` | Date notation: `wareki` (Japanese calendar) / `both` (Japanese + Western calendar) / `seireki` (Western calendar) |
### Library
```go
// Family Relationship Chart
pdf, err := relationchart.GenerateFromJSON(chartJSON, relationchart.DefaultOptions())
// Inheritance Registration Application
pdf, err := registration.GenerateFromJSON(toukiJSON, registration.DefaultOptions())
// Division Agreement
pdf, err := agreement.GenerateFromJSON(bunkatsuJSON, agreement.DefaultOptions())
// Division Certificate
pdf, err := agreement.GenerateCertificateFromJSON(certJSON, agreement.DefaultOptions())
```
### MCP Server (stdio)
An MCP server for generating document PDFs from LLM/agents.
```sh
go build -o tsugu-mcp ./cmd/tsugu-mcp
```
**Document Generation Tool** (input `{ document, outputPath?, era? }`, returns the **file path** of the generated PDF. `document` is the same as "Input JSON" below. If `outputPath` is omitted, a temporary file is used):
- `generate_relationship_chart` — Family Relationship Chart
- `generate_registration_application` — Inheritance Registration Application (automatically calculates registration tax if `value` = evaluation value is passed for each property)
- `generate_division_agreement` — Division Agreement
- `generate_division_certificate` — Division Certificate (one page per heir)
**Knowledge-driven and Judgment Tools** (`docs/knowledge` based. Not legal advice, but information provision, and disclaimers are added to the output):
- `calculate_registration_tax` — Registration tax calculation (taxable base aggregation, fractional processing, and exemption provisions)
- `list_required_documents` — Required document navigation (inheritance method and heir pattern-specific attached information classification)
- `calculate_statutory_shares` — Statutory share calculation (current, Civil Code Articles 900/901. Half-blood and representation are calculated in irreducible fractions. No distribution judgment)
- `select_application_pattern` — Case-specific form selection (A statutory inheritance to H spouse's residence right purpose, cause, application structure, tax rate, and attachment)
- `guide_heir_notification` — Application obligation deadline calculation and heir notification registration guidance
**Knowledge Resource**: `docs/knowledge`'s 8 documents are published under `knowledge://<slug>` (`knowledge://index` is the entry point). The host/LLM refers to it when necessary.
**Prompt**: `prepare_inheritance_registration` — A guide to proceed with hearing → case judgment → required documents → tax amount → document generation in a single process.
Client registration example (Claude Desktop/Code):
```json
{ "mcpServers": { "tsugu": { "command": "/absolute/path/to/tsugu-mcp" } } }
```
## Input JSON (Family Relationship Chart)
Individuals are represented by their affiliation (spouse / children / descendants / ascendants / siblings) and nesting to show relationships. Each children/siblings node can have its own `spouse` and `descendants` (arbitrary generation).
```jsonc
{
"decedent": { // Decedent (required: name, deathDate)
"name": "Yamada Taro",
"registeredDomicile": "1-1-1 Chiyoda-ku, Tokyo", // Registered domicile
"lastAddress": "1-1-1 Chiyoda-ku, Tokyo", // Last address
"birthDate": "1940-01-01", // YYYY-MM-DD
"deathDate": "2024-06-15"
},
"spouse": { "name": "Yamada Hanako", "relationship": "wife" },
"children": [
{ "name": "Yamada Ichiro", "relationship": "eldest son" },
{ "name": "Yamada Jiro", "relationship": "second son", "deathDate": "2020-03-10",
"spouse": { "name": "Yamada Umeko", "relationship": "wife" },
"descendants": [ // Representation (arbitrary generation)
{ "name": "Yamada Saburo", "relationship": "eldest son" },
{ "name": "Sato Yoshiko", "relationship": "second daughter", "applicant": true,
"address": "2-2-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo", "birthDate": "1975-05-05",
"outcome": "inherit" }
] }
],
"ascendants": [ { "name": "Yamada Soichi", "relationship": "father" } ], // Direct ascendants (parents)
"siblings": [ { "name": "Yamada Haruo", "relationship": "younger brother" } ], // Siblings
"preparer": { "address": "2-2-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo", "name": "Sato Yoshiko" },
"preparedAt": "2024-12-10"
}
```
- `outcome` (notation): `inherit` → `(相)` / `renounce` → `(相続放棄)` / `division` → `(分割)` / `by_representation` → `(代襲)`. Japanese text (`相続`, etc.) is also acceptable.
- `applicant: true` adds `(申立人)`.
- `relationship` is a free string for display. Roles are represented by arrangement (children/ascendants/siblings, descendants) and nesting.
- If `ascendants` exists, it roots the decedent and siblings as children.
## Input JSON (Inheritance Registration Application)
The registration purpose is fixed as "所有権移転" (transfer of ownership), so it is not in the JSON. `applicants` can have multiple + shares, and `properties` can have land/building mixed. If there are many properties, the pages are automatically turned.
```jsonc
{
"causes": [ // Causes (multiple entries for multiple inheritances)
{ "date": "2020-03-10", "text": "Yamada Taro's inheritance" }, { "date": "2024-06-15", "text": "Inheritance" }
],
"decedent": { "name": "Yamada Ichiro" },
"applicants": [
{ "name": "Yamada Hanako", "address": "2-2-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo", "share": "1/2",
"nameKana": "Yamada Hanako", "birthDate": "1950-05-05",
"email": "hanako@example.com", "phone": "090-0000-0000", "contact": true },
{ "name": "Yamada Jiro", "address": "3-3-3 Naka-ku, Yokohama-shi, Kanagawa", "share": "1/2" }
],
"attachments": ["Registration cause proof document", "Address proof document"], // Enumerated with line breaks and indentation
"declineIdInfo": false, // Notification column for registration identification information (always displayed): false=□ / true=☑
"applicationDate": "2024-12-10", "registry": "Tokyo Legal Affairs Bureau",
"taxValue": "0", "registrationTax": "0",
"properties": [
{ "kind": "land", "number": "...", "location": "...", "lotNumber": "1", "landCategory": "宅地", "area": "123.45" },// number is sometimes listed as the object number in the (supplementary) taxation ledger (name list)
{ "kind": "building", "number": "...", "location": "...", "houseNumber": "1-1",
"buildingType": "居宅", "structure": "wooden 2-story building", "floorArea": "1st floor 60.00 square meters" }
]
}
```
- `kind`: `land` (land: plot number/land category/area) / `building` (building: house number/type/structure/floor area).
- If `contact: true`, the applicant's name kana, birth date (Western calendar), email, and contact phone are added.
## Design
The data is structured in a one-way flow, and each layer is testable independently without depending on the drawing library. The two documents share an intermediate representation and drawing.
```
Family Relationship Chart: JSON ─[inputjson]→ family.Document ─[layout]───→ scene.Scene ─┐
Inheritance Registration Application: JSON ─[reginput]──→ touki.Application ─[reglayout]→ []scene.Scene ─┤─[render]→ PDF
Shared: ymd / wareki / scene / render
```
| Package | Responsibility |
|------------|------|
| `ymd` | Date and analysis (shared by all documents) |
| `internal/wareki` | Western calendar to Japanese calendar conversion (era table-driven pure function) |
| `internal/scene` | Intermediate representation of drawing instructions (frames, lines, labels, mm coordinates) |
| `internal/render` | Scene → PDF. Isolates gopdf dependency with `Canvas`. `ToPDFMulti` for multiple pages |
| `family` / `internal/inputjson` / `internal/layout` / `relationchart` | Family Relationship Chart: model / JSON boundary / horizontal tree layout / public API |
| `touki` / `internal/reginput` / `internal/reglayout` / `registration` | Inheritance Registration Application: model / JSON boundary / insertion + page turning / public API |
| `bunkatsu` / `internal/bunkatsuinput` / `internal/bunkatsulayout` / `agreement` | Division Agreement and Certificate: model / JSON boundary / insertion / public API |
| `cmd/tsugu-mcp` / `internal/mcpserver` | MCP server (stdio). Provides document generation, knowledge-driven tools, and knowledge resources |
| `docs/knowledge` / `internal/regtax` / `internal/docguide` | Inheritance knowledge base (embedded) / registration tax calculation / required document navigation. Primary information base, verifiable with pure functions |
The layout converts the Document into a single family tree (`tree.go`) and assigns generations to columns from left to right. Individuals are represented by frame-less cards (`card.go`), and relationships are represented by vertical double lines for marriages and bracket lines for parent-child relationships.
## Font
The IPAex Gothic (TrueType) font is embedded with `go:embed` for Japanese display and subset-embedded into PDFs. The license is [IPA Font License v1.0](assets/fonts/IPA_Font_License_Agreement_v1.0.txt) (embedding and redistribution allowed).
## Development
```sh
go test ./... # Unit and integration tests for all layers
go vet ./...
```
MCP Config
Below is the configuration for this MCP Server. You can copy it directly to Cursor or other MCP clients.
mcp.json
Connection Info
You Might Also Like
No recommendations available