# `DDD.MCP.Server`
[🔗](https://github.com/blackuprise/vicander/blob/v0.1.1/lib/ddd/mcp/server.ex#L1)

Declares which commands, queries and aggregates an application offers over MCP.

    defmodule MyApp.Interface.MCP do
      use DDD.MCP.Server,
        instructions: "Manage todo lists.",
        commands: [MyApp.Commands.CreateList, {MyApp.Commands.RenameItem, name: "rename_todo"}],
        queries: [MyApp.Queries.OpenItems],
        repos: [MyApp.TodoList.Repository],
        read_only: false,
        authorize: &MyApp.MCPPolicy.authorize/2
    end

Nothing is exposed unless it is listed here, and the commands and entities themselves know
nothing about MCP. The level of access is what you list: a server with only `queries:` and
`repos:` can only read.

  * `commands:` and `queries:` become tools. A module is listed alone, or as
    `{Module, name: "tool_name"}`. The default name is the last module segment in snake case.
  * `repos:` become read-only resources, one per repository. List the repository port (it says which aggregate
    and which `find_by` lookups exist), or `{Aggregate, repository: Port}`. The port must
    define `impl/0`.
  * `read_only: true` refuses every command tool.
  * `authorize:` is a function `(name, arguments) -> :ok | {:error, reason}` called before
    each tool call (with the tool's name) and resource read (with `"resource:<name>"` and
    `%{"uri" => uri}`).
  * `name:`, `version:` and `instructions:` are reported to the client.

Every exposed module needs a `description`. A missing one, or two tools with the same name,
raises when the server is built (at startup), not when a client calls.

The module gets `handle/1` (one decoded JSON-RPC message), `serve/1` (the stdio loop) and
`registry/0`. Run it with `mix vic.mcp MyApp.Interface.MCP`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*