Skip to content

Agentic operations

AI access tokens can carry write scopes. With one, the AI tooling in your editor doesn’t just read production — it can operate the demand model: create and update demands, dashboards, alert rules, custom rules, and notification channels, acting as you, under your role, with every change in the audit log.

That turns the MCP connection from a window into a workbench.

Instrumentation is written in the development environment. Observability has traditionally been configured somewhere else — a dashboard “once it’s deployed”, an alert after the first incident. The two halves of the same change live in different tools, done by different motions, often days apart. The second half is the one that slips.

With a write-scoped token, both halves happen in the same agent session:

  1. Your coding agent adds the instrumentation — a new counter, a structured log line, a span.
  2. It checks the edge: available_metrics_names confirms the gateway agent is already seeing the new metric locally.
  3. It declares the demand: a custom_rule_create (or a dashboard) makes the signal part of the demand set. Collection turns on at the edge automatically — no deploy, no config file, no ticket.
  4. It verifies the loop: metrics_query_range shows data landing in central storage.
  5. It wires the guardrail: alert_rule_create attaches an alert to the same demand, and alert_rule_test evaluates the threshold against live data before anyone relies on it.

The pull request that adds the instrumentation and the demand that stores it ship as one reviewed change. Observability stops being a follow-up task.

Production feeds back into development through the same session. An agent investigating an incident with the read tools — stored and available_* queries, the demand set, the docs playbooks — can finish the job instead of filing it:

  • fix the code, and raise the alert threshold that paged too early;
  • add the missing log stream to the demand so the next investigation has the evidence this one lacked;
  • save the exploration as a dashboard panel for the on-call rotation;
  • import a ready-made demand from the registry (demand_import_by_name) when a whole capability is missing — always as a dry run first, so you see the report before anything is written.

Diagnosis and remediation stop being separate tools with a copy-paste gap between them.

AreaTools
Demandscreate, update, import (body or registry, with dry-run), delete
Dashboardscreate, update (a new version, like saving in the app), delete
Alert rulescreate, update, pause/resume, live test, delete
Custom rulescreate, update, enable/disable, delete
Notification channelscreate, update, delete

Deliberately not writable over MCP: gateway agents, users and roles, tenant settings, access tokens themselves, and the garbage-collection sweep. Those stay in the LeanSignal app.

Write access is engineered as a scoped extension of your access, not a service account with keys to the tenant:

  • Opt-in per token. Tokens are read-only unless you enable writes when creating one, and only editors and admins can mint write scopes. Your existing tokens are unaffected.
  • Deletes are a separate scope. Under the demand model, deleting a demand object purges the stored telemetry only it covered — so delete tools sit behind their own switch, and the tools themselves ask the agent to confirm with you first.
  • Your role, exactly. Every write goes through the same validation, permission checks, and invariants as the app itself — a viewer-role token cannot write no matter what scopes it holds, and an agent cannot create a broken alert rule any more than you could.
  • Attributed and audited. Changes land in the audit log and in each object’s ownership as you (MCP) — AI-driven changes are always distinguishable from interactive ones, and reviewable after the fact.
  • Approval where you work. MCP clients like Claude Code and Cursor ask before each tool call by default; keep that on for write tools.
  • Revocable in one click. Revoking the token on the Preferences page cuts off the client immediately.

And because writes flow through the demand model, they are self-limiting: an agent can only turn collection on by declaring a demand — visible, reviewable, and priced — never by quietly widening a firehose.

Token creation, client configuration snippets, and scope details are on the AI access page. In short: Preferences → AI access (MCP) → enable Allow writes (and optionally deletes) when creating the token, then add the endpoint and token to your client as usual.

Was this page helpful?