For agents · Model Context Protocol

Wire your agent into Glyph's compiler

glyph mcp runs a Model Context Protocol server that gives a coding agent five queries about your project: diagnostics, the type at a cursor, where a name is defined, every reference to a symbol, and symbol search. It runs the same analysis the editor uses, over stdio, so what the agent sees matches what the compiler sees.

Why an agent wants this

An agent editing a codebase usually works blind. It reads files, guesses at types, and finds out whether it broke something only after a build. Glyph already answers those questions for an editor. glyph mcp gives an agent the same answers straight from the compiler, without scraping build output or reading every file to find who calls what. It sits alongside glyph build --json, which is the batch path for coded diagnostics; MCP is the interactive one.

Set it up

Any MCP client can launch it. Point the client at the glyph binary with the mcp subcommand, and pass your project root as an argument or run it from the project directory. It speaks MCP over stdio, so there's no port and no daemon.

mcp client config (generic) 
{
  "mcpServers": {
    "glyph": {
      "command": "glyph",
      "args": ["mcp", "/path/to/your/project"]
    }
  }
}

On first connect the client calls initialize and tools/list; the server reports the five tools below. Positions follow the LSP convention: a 0-based line and a 0-based character (UTF-16 code units).

The five tools

tools exposed by glyph mcp 
// type-check one file → diagnostics with stable codes + ranges
glyph_diagnostics(path)

// the inferred type at a position
glyph_hover(path, line, character)

// where the name is defined, following imports across modules
glyph_definition(path, line, character)

// every reference across the whole project: the declaration, all
// uses, and each importing module's `import` binding
glyph_references(path, line, character)

// search top-level declarations and union variants by name
glyph_symbols(query)

See it

A tools/call for glyph_diagnostics on a file with a field typo returns the compiler's own diagnostic as structured JSON the agent can act on: the stable code, the message, and the exact range.

request 
{
  "method": "tools/call",
  "params": {
    "name": "glyph_diagnostics",
    "arguments": { "path": "src/user.glyph" }
  }
}
result (the tool's JSON content) 
[
  {
    "code": "E0210",
    "message": "type `U` has no field `naem`",
    "range": {
      "start": { "line": 7, "character": 9 },
      "end":   { "line": 7, "character": 15 }
    }
  }
]

glyph_references is workspace-wide: ask about a symbol and you get its declaration, every use, and each importing module's import binding, across every file. It uses the same cross-file identity the editor's rename does, so the answer covers the whole project, not just the file you asked from.

What it doesn't do yet

The tools only read. You can't rename or apply edits through MCP yet; that's next. The server rescans the project on each call rather than keeping a cached index, which is fine for a normal project and something to speed up later, and it skips any file that doesn't currently parse. References to a local variable stay within its file, since a local can't be used from another one. Every tool runs the same analysis code the editor uses, so its answers match the compiler.

Where it stands

Shipping today

A glyph mcp [root] server over stdio with five tools: glyph_diagnostics, glyph_hover, glyph_definition, glyph_references (workspace-wide), and glyph_symbols. Each one runs the same analysis the language server uses.

Not using MCP? An agent can still get the full language and diagnostic surface offline via llms.txt (the spec) and glyph build --json (coded diagnostics). MCP is the interactive layer on top.