MCP Resource + Prompt Template Pack for real estate in custom host via MCP SDK

You are building an MCP server that primarily surfaces **Resources** and **Prompt Templates** (not just tools) to give agents in custom host via MCP SDK deep, navigable context over a real estate dataset.

**Runtime:** TypeScript + Bun
**Validator:** Pydantic v2
**Auth:** API key in header

## Background on the three MCP primitives

- **Tools** → model-initiated actions (side-effectful)
- **Resources** → application-attached read-only context (file-like, addressable by URI)
- **Prompt Templates** → user-initiated canned workflows with typed arguments

This server leans heavily on Resources and Prompts. Only expose Tools where a Resource won't do.

## Part 1 — Resource design for real estate

1. Define the resource URI scheme, e.g. `real estate://<entity>/<id>` and `real estate://search?q=...`
2. List 8 concrete resource examples with URI, MIME type, and a short description
3. Implement `resources/list` — paginated, with cursor
4. Implement `resources/read` — return `text` or `blob` content, set `mimeType` correctly
5. Implement `resources/templates/list` for parameterized URIs
6. If the dataset changes, implement `resources/subscribe` + `notifications/resources/updated`
7. Access control: which resources should require elevated auth?

## Part 2 — Prompt Templates for real estate workflows

Design 6 Prompt Templates that custom host via MCP SDK users would reach for. For each, provide:

- `name` (kebab-case, scoped like `real estate/<verb>`)
- `description` shown in the custom host via MCP SDK UI picker
- `arguments`: name, description, `required`, example value
- The **messages** the template expands to, including how it attaches relevant Resources via `resource_link` or embedded resource contents
- Why this is a Prompt (user-initiated) and not a Tool (model-initiated)

Example workflows to cover: "summarize today's changes in <entity>", "compare two <entities>", "draft a <domain>-specific report from <resource>".

## Part 3 — Tools (only where needed)

List any tools the agent genuinely needs (e.g. write-back actions). Keep the tool surface small; prefer resources for reads.

## Part 4 — custom host via MCP SDK install + UX

- Config JSON block for custom host via MCP SDK's MCP settings
- How Resources appear in the custom host via MCP SDK UI (attach picker, @-mention, autocomplete)
- How Prompt Templates appear (slash menu, command palette)
- Screenshots/descriptions of the expected UX so the user knows what "working" looks like

## Part 5 — Implementation

Write the full server code for:
- The resource handler (list + read + templates + subscribe)
- Two of the prompt templates, fully fleshed out
- API key in header middleware
- A `Dockerfile` that runs under TypeScript + Bun

## Part 6 — Testing

- Unit tests: resource URI parsing, prompt argument validation
- Integration test driving the server via the MCP client SDK
- A manual test plan for custom host via MCP SDK: "open custom host via MCP SDK, attach resource X, run prompt Y, expect Z"

## Part 7 — Versioning and backward compat

When the real estate schema changes, how do you version resource URIs and prompt argument shapes without breaking existing agents? Document the deprecation path.

Output must be concrete and implementation-ready. No vague "you could also...". Pick one stack, ship it.