Is your feature request related to a problem? Please describe.
This repo exposes 16 MCP tools (@mcp.tool() in src/real_estate/mcp_server/) that wrap MOLIT (Korea's Ministry of Land, Infrastructure and Transport) real estate APIs — apartment/officetel/villa/single-house trade and rent lookups, APT subscription info, region code resolution, and a few finance calculators. There is currently no single public document that lets someone land on this repo and understand, without reading every source file, what tools exist, what each one does, how it maps to the underlying government API, and how well it's tested. That's a barrier for:
Describe the solution you'd like
Publish a human-readable MCP tool inventory document under docs/ (so it's visible on GitHub, not just local notes), on a dedicated branch. Before writing it, settle a few scoping questions so the result is actually useful rather than another list only its author can parse:
- Who is this document for — a future contributor, someone writing an OpenAPI spec from it, or an external integrator evaluating the tools? The answer affects how much explanation each entry needs.
- How should the 16 tools be grouped — by real-estate domain (trade/rent/subscription/finance), by source government API, or by request/response shape?
- What does each tool entry need at minimum to be understandable on its own: signature, example request/response, known error cases, test coverage status, and its mapping to the source government API endpoint.
- If a separate document already describes the raw government API contracts, how should this inventory reference it instead of duplicating it.
Once these are settled, write up a short plan for the document's structure and get it reviewed before the actual rewrite, since it's a public-facing artifact. The rewrite itself happens as a follow-up once the plan is agreed, on its own branch.
Describe alternatives you've considered
- Writing the inventory ad hoc without agreeing on audience/structure first — risks producing something only the author can parse, which defeats the purpose of a document meant for future visitors to this repo.
- Keeping the inventory as private/local notes only — doesn't help anyone who isn't the person who wrote it, and doesn't serve the stated goal of letting repo visitors reconstruct history and context.
Additional context
This is a prerequisite for the OpenAPI spec work needed to redeploy these MCP tools as a REST API / CLI / Claude Skill (tracked in #22). The inventory doc should land in docs/ so it's part of the public repo, not a gitignored working note.
Is your feature request related to a problem? Please describe.
This repo exposes 16 MCP tools (
@mcp.tool()insrc/real_estate/mcp_server/) that wrap MOLIT (Korea's Ministry of Land, Infrastructure and Transport) real estate APIs — apartment/officetel/villa/single-house trade and rent lookups, APT subscription info, region code resolution, and a few finance calculators. There is currently no single public document that lets someone land on this repo and understand, without reading every source file, what tools exist, what each one does, how it maps to the underlying government API, and how well it's tested. That's a barrier for:Describe the solution you'd like
Publish a human-readable MCP tool inventory document under
docs/(so it's visible on GitHub, not just local notes), on a dedicated branch. Before writing it, settle a few scoping questions so the result is actually useful rather than another list only its author can parse:Once these are settled, write up a short plan for the document's structure and get it reviewed before the actual rewrite, since it's a public-facing artifact. The rewrite itself happens as a follow-up once the plan is agreed, on its own branch.
Describe alternatives you've considered
Additional context
This is a prerequisite for the OpenAPI spec work needed to redeploy these MCP tools as a REST API / CLI / Claude Skill (tracked in #22). The inventory doc should land in
docs/so it's part of the public repo, not a gitignored working note.