Create a token in Settings → Access Tokens, grant it the scopes the agent needs, and send it as a bearer token. A token is tied to you and one organization and never grants more than your own access.

Authorization: Bearer lpat_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4

Interactive clients can connect with OAuth 2.1 (PKCE, dynamic client registration, and browser consent on the LogPulse scopes), so a user authorizes the agent without handling a token by hand. The agent registers itself, the user signs in and consents, and LogPulse issues a scoped access token bound to the agent and organization. Connected agents are listed, and can be revoked, under Settings → Connections.

One token or connection can reach several organizations. Pick them when you create the token (Profile → Access Tokens) or on the OAuth consent screen; only organizations you belong to can be chosen, and membership is checked again on every request.

Such a connection has no current organization. list_organizations shows the choices, and every other tool takes a required organization argument (id, slug or exact name). The agent is instructed to ask you when it is not sure which organization you mean. A call without one, or with a name that matches more than one organization, runs nothing and returns the list. Plan, role, data access and the audit trail are those of the organization the call names.

Add LogPulse as an app in ChatGPT: from the app directory when it is listed for your account, or as a custom app in developer mode (Settings → Apps → Advanced settings) with this URL and OAuth authentication:

https://api.logpulse.io/mcp

ChatGPT sends you to LogPulse to sign in. On the consent screen you pick the organizations ChatGPT may use and, under Change access, trim the permissions. Results from searches, notables, service health, dashboards and proposals render as interactive widgets in the chat.

Add LogPulse from the Claude connectors directory when it is listed there (Settings → Connectors → Browse), or as a custom connector with this URL:

https://api.logpulse.io/mcp

Claude opens LogPulse to sign in and shows the same consent screen. Once connected, LogPulse works in every conversation where the connector is enabled, on the web, in the desktop app and on mobile, with the same interactive widgets.

Add LogPulse with the Claude CLI. Without a header, Claude Code signs in with OAuth the first time you use it (run /mcp to authenticate); with a token it connects directly:

claude mcp add logpulse --transport http \
  https://api.logpulse.io/mcp \
  --header "Authorization: Bearer lpat_your_token_here"

The LogPulse tools appear immediately in any Claude Code session. Verify with /mcp or by asking Claude to list its LogPulse tools.

Add LogPulse as an HTTP MCP server in Cursor's MCP settings, or edit ~/.cursor/mcp.json directly:

{
  "mcpServers": {
    "logpulse": {
      "url": "https://api.logpulse.io/mcp",
      "headers": {
        "Authorization": "Bearer lpat_your_token_here"
      }
    }
  }
}

Codex, Continue, and custom agents all connect with the same three values. Point your client at the endpoint over Streamable HTTP with a bearer token:

Endpoint:  https://api.logpulse.io/mcp
Transport: Streamable HTTP
Auth:      Authorization: Bearer lpat_your_token_here

Agents never write configuration directly. Each propose_* tool queues a change in LogPulse for a human to review and approve; approved items are created disabled/inactive for a person to activate. Destructive SOAR actions (block_ip, disable_user) require owner approval plus the org's destructive-actions flag, and agent-side HTTP nodes are rejected.

Service Intelligence proposals are checked against your data before they are queued: the membership rules must match entities or sources, every KPI search runs once inside the service scope, and a dependency must point at an existing service. What the check found travels with the proposal, so the reviewer sees the same evidence. An update or delete that was overtaken by a manual edit fails instead of overwriting it.

Changes without a review. By default every proposal waits for a person. An owner or admin can let the agent apply a category by itself under AI → Settings (services, KPIs, dependencies, SLOs, notification routes, dashboards, health checks, parser rules, detections, alert rules, pipelines), each off until switched on. An applied change is still recorded as a proposal with its diff, runs under the rights of the token's owner, and lands in the audit log. Destructive changes always wait for the owner.

Parser rules. check_parsing shows how a source is parsed today, list_grok_templates the building blocks, and test_parser_rule runs a candidate over real events in the same engine ingest uses (all under logs:read). A proposed rule is tested again on the events its source pattern selects and refused when fewer than 80% parse, when the pattern is unsafe or too slow, or when another rule would win for the same events. A rule applies to events that arrive after it is live; for regex and grok rules the result carries a backfillSearch, an LPQL search with | rex that extracts the same fields from events already stored. find_unparsed_sources shows where a rule would help most.

Scheduled searches show their cost. A detection, alert rule or KPI runs forever, so before it is queued the server estimates the rows it reads per day (the store's own estimate, or the hourly counts) and shows that number to the reviewer, with advice on how to narrow it. Nothing is refused on cost.

SLOs, notification routes, dashboards and health checks. A proposed SLO is measured over the last 7 days with the computation the SLO editor's preview uses, and the reviewer sees its SLI, error budget and burn rate. A notification route names a channel that already exists by its id: an agent cannot add a recipient, an email address or a webhook URL, and it only ever sees masked targets. Every panel search of a proposed dashboard runs once and must be narrowed. A proposed health check is run once from LogPulse behind the same protection against private and internal addresses as the Test button; a check that runs on an agent needs an online agent.

Searches must be narrowed. The log store is sorted by index, so a proposed detection or alert rule without index=, sourcetype=, source= or host= before its first pipe is refused; a KPI runs inside its service scope and is advised to add index=. platform_help teaches the agent how to build an efficient search and what can and cannot be done over MCP, and get_agent_permissions tells it, per kind of change, whether a proposal is applied at once or waits for a person. Both need no scope.