API Reference¶

One MCP server, two CLIs¶

Graphify is the only remaining MCP server. The semantic-analysis and constraint-monitor tools still exist and do the same work — they are reached by running a command instead:

Retiring those two as MCP servers removed roughly 14 KB of tool schema from every context window.

The endpoints you will actually use¶

curl -s localhost:3034/health/state | jq .    # live health, the source of truth
curl -s localhost:12435/health | jq .         # LLM proxy
curl -s localhost:3033/health | jq .          # health API (backs the dashboard)

The port pairs that get confused¶

12435 is the LLM proxy, 12436 is observations. 3848 runs workflows, 3033 does not. Both mistakes fail as a bare 404 that names nothing.

Generic tool access¶

semantic tools                            # everything available
semantic tool <name> '{"key":"value"}'    # invoke one directly

Why the MCP servers became CLIs¶

Every MCP tool a server exposes costs tool-schema tokens in every context window, whether or not it is used. Nineteen semantic-analysis tools and four constraint-monitor tools came to roughly 14 KB per window, permanently, for capabilities used occasionally.

Both are now CLIs and neither lost functionality. The semantic CLI posts to the running workflow server, so it drives the same state machine that feeds the dashboard's live view. The constraints CLI evaluates in-process, which makes it strictly more available than the MCP server was — it works when the container is down.

Graphify stays on MCP because structural code queries are genuinely per-turn work, where the schema cost buys something on most turns.

HTTP surfaces¶

Two pairs cause nearly all the confusion here, and both fail as a bare 404 rather than anything diagnostic: 12435 versus 12436, and 3848 versus 3033.

The LLM proxy's endpoint¶

curl -s localhost:12435/api/complete \
  -H 'content-type: application/json' \
  -d '{"process":"my-service","messages":[{"role":"user","content":"hi"}],"complexity":"small"}'

Not the OpenAI-shaped path. process is what makes token accounting attributable, and complexity is the band that decides cost — a taskType field is read by nothing.

Health as an API¶

GET localhost:3034/health/state returns the whole document: container state, per-service status, per-project session logging, database sub-checks, network location and proxy state. Everything else — the dashboards, the status line, the prompt hooks — renders that one document, which is why they agree, and why a disagreement means something is reading a stale copy rather than that two things are broken.

MCP tools and REST API endpoints.

Tools¶

Only Graphify is still an MCP server. The semantic-analysis and constraint-monitor tools were retired as MCP servers in favour of CLIs — the tools themselves still exist and do the same work, but the agent reaches them by running a command rather than over MCP. That change removed roughly 14 KB of tool schema from every context window.

Semantic analysis — via the semantic CLI¶

Any tool without a dedicated subcommand is reachable generically:

semantic tools                              # names + descriptions of all of them
semantic tool <name> '{"key":"value"}'      # invoke one directly

Constraint monitor — via the constraints CLI¶

Graphify — the one remaining MCP server¶

HTTP MCP endpoint at http://localhost:3851/mcp (served from inside coding-services), backed by the static graph.json.

REST APIs¶

Constraint Monitor API (Port 3031)¶

List Violations¶

GET /api/violations?project=coding

Response:

{
  "violations": [
    {
      "id": "uuid",
      "constraintId": "no-logging-statements",
      "severity": "warning",
      "message": "Avoid logging statements",
      "timestamp": "2025-01-15T10:30:00Z"
    }
  ],
  "total": 1
}

Log Violation¶

POST /api/violations
Content-Type: application/json

{
  "constraintId": "no-logging-statements",
  "severity": "warning",
  "message": "Logging statement found in file.js",
  "project": "coding"
}

Get Compliance¶

GET /api/compliance/coding

Response:

{
  "score": 9.5,
  "violations": 1,
  "trend": "improving"
}

List Constraints¶

GET /api/constraints

Health Check¶

GET /api/health

Health Dashboard API (Port 3033)¶

Overall Health¶

GET /api/health

Response:

{
  "status": "healthy",
  "services": {
    "lsl": "healthy",
    "ukb": "healthy",
    "constraints": "healthy"
  },
  "uptime": 3600
}

Service Status¶

GET /api/services

Metrics History¶

GET /api/metrics?range=24h

Alerts¶

GET /api/alerts?limit=10

VKB Server API (Port 8080)¶

List Entities¶

GET /api/entities?team=coding

Get Entity¶

GET /api/entities/:id

Search¶

GET /api/search?q=authentication&type=ImplementationPattern

Graph Data¶

GET /api/graph?team=coding

Agent Integration¶

AgentAdapter Interface¶

interface AgentAdapter {
  // Identification
  getName(): string;
  getVersion(): string;

  // Capabilities
  supportsMemory(): boolean;
  supportsBrowser(): boolean;
  supportsHooks(): boolean;

  // Operations
  initialize(config: AgentConfig): Promise<void>;
  createMemory(key: string, value: any): Promise<void>;
  searchMemory(query: string): Promise<Memory[]>;
  readMemory(key: string): Promise<any>;
}

Required APIs for New Agents¶

Integration Steps¶

1. Implement AgentAdapter interface
2. Register in agent-registry.js
3. Add detection in agent-detector.js
4. Create launcher script launch-{agent}.sh
5. Update bin/coding routing
6. Test with validation commands

Webhook Events¶

Constraint Violations¶

{
  "event": "constraint.violation",
  "data": {
    "constraintId": "no-hardcoded-secrets",
    "severity": "critical",
    "project": "coding",
    "blocked": true
  }
}

Health Alerts¶

{
  "event": "health.alert",
  "data": {
    "service": "lsl",
    "status": "degraded",
    "message": "High memory usage"
  }
}