# Adding tools

Household notes are a stand-in. Replace them with tools that talk to the LAN
services and local programs you actually want Kody to use.

## Where to edit

- `src/mcp/tools.ts` — register tools, Zod input schemas, and handlers
- `src/notes.ts` — delete once notes are gone, or keep it if you still want a
  capture file
- `src/mcp/http-mcp.ts` — server name and instructions. Keep instructions short:
  what this process is, where `/mcp` lives, and which tool to call first.

`createHomeMcpToolRegistry` is the list Kody sees after OAuth. `listHttp()`
feeds `@modelcontextprotocol/server` `registerTool`. `call()` is the
implementation.

## Keep tools narrow

One tool, one action. Prefer:

- a read-only inventory or status tool
- a small write tool with explicit ids and enums
- a confirmation field on anything destructive

Do not add an unrestricted shell, a generic HTTP proxy to the whole LAN, or a
tool that takes raw SQL. If a CLI is useful, wrap a fixed argv shape and
validate it with Zod.

## Schema and results

Use `buildToolInputSchema` from `src/mcp/tool-input-schema.ts` so the JSON
Schema Kody sees matches the Zod parser. Mark read-only tools with
`readOnlyHint` and deletes with `destructiveHint`.

Return the CallToolResult shape:

```ts
{
	content: [{ type: 'text', text }],
	structuredContent,
}
```

Put a short sentence in `content` and the typed payload in `structuredContent`.
Validation failures set `isError: true`.

## Instructions

Server instructions belong in `homeMcpHttpInstructions`. Tell the model to start
with `home_get_metadata`, then name the first two tools of your real workflow.
Long policy and field tables belong in tool results, not in the instruction
string.