Observability

Create an auth token. Sentry → Settings → Auth Tokens → Create New Token, with issue and project read scopes (project:read, event:read, org:read). No write scopes.

Note the organization slug: the segment in sentry.io/organizations/<slug>/.

Fill the form.

Verify. Health check is find_projects, not whoami: the pinned server version serves only 8 top-level tools and whoami isn't one of them.

Confirm the server URL is reachable from members' machines. Prometheus itself has no user model, so if it is exposed at all it is behind something else: a reverse proxy, an ingress, or a managed service. That front door's URL is what goes in the form, and its authentication is what Authentication method describes.

Get the credential that front door wants.

For a proxy doing HTTP basic auth, that is a username and password. For Grafana Cloud, Amazon Managed Prometheus behind a proxy, or an ingress checking a header, it is a bearer token, created wherever that service issues API tokens, and given read access to the metrics endpoint only.

Pick one. A token, once set, is the only credential sent; a username and password filled in beside it would be dropped without a word, which is why this is a choice on the form rather than two optional pairs.

For Cortex, Mimir or Thanos, find the tenant ID. Multi-tenant deployments key every query on an X-Scope-OrgID header. Without it a query returns nothing, or is rejected outright, with no hint that a tenant was expected. It is the same value your Grafana data source sends.

Fill the form.

Verify. Health check is the server's own health_check.

Pick the authentication method the cluster actually offers. It is the first choice on the form and it decides which other fields appear:

• None: a self-managed cluster with the security plugin disabled.
• Username and password: a self-managed cluster with the security plugin on.
• AWS SigV4 (access keys): Amazon OpenSearch Service, signing with a key pair, or with whatever credentials the machine running Triagic already has.
• AWS SigV4 (assume an IAM role): the same, but assuming a role first. This is the only route to a role, because the server has no other role setting.

Create a read-only user if the security plugin is enabled: a user mapped to a role with indices:data/read/* on the log indices, and nothing else.

For Amazon OpenSearch Service, create an IAM identity that can only read. Attach a policy granting es:ESHttpGet and es:ESHttpHead on the domain, and add that identity to the domain's fine-grained access control mapping if it has one.

To assume a role instead of using long-lived keys, leave AWS access key ID and AWS secret access key blank and fill in IAM role ARN. The credentials that assume it are then whatever the machine running Triagic already has (an EC2 instance profile, an ECS task role, or ~/.aws/credentials), and that identity needs sts:AssumeRole on the role. Filling the key fields in as well makes those keys the ones that assume the role.

Fill the form.

Verify. Health check is the cluster-health call.

Create an API key in Kibana → Stack Management → API keys, restricted to read privileges on the indices you need. "Restricted" means a role descriptor on the key: read and view_index_metadata on those indices is the whole requirement, plus the cluster's monitor privilege for the shard and health tools:

{
  "triagic-read": {
    "cluster": ["monitor"],
    "indices": [{ "names": ["logs-*"], "privileges": ["read", "view_index_metadata"] }]
  }
}

Copy the encoded value, the base64 id:key form. A username and password also work (give that user the same role); the API key wins if both are filled in.

Fill the form.

Verify. Health check lists indices matching *.

Create an API key. Datadog → Organization Settings → API Keys.

Create an application key. Organization Settings → Application Keys, in the same organization.

An unscoped application key inherits every permission of the user who created it, so create it from a least-privilege user, not an admin. If your plan supports scoped application keys, scope it instead, with read scopes covering what this integration queries: monitors_read, dashboards_read, metrics_read, timeseries_query, logs_read_data, events_read, incident_read, slos_read, hosts_read, apm_read, usage_read, rum_apps_read, synthetics_read, security_monitoring_rules_read, security_monitoring_signals_read, teams_read, notebooks_read, logs_read_pipelines, logs_read_index_data, and logs_read_archives. Leave every write scope off; the server's --read-only flag refuses writes anyway, and the scopes make that hold even if the flag ever breaks.

Note your site. It is the domain in the URL when you log in to Datadog. Keys are per-region, so a mismatch is rejected outright. Pick from the list rather than typing, because a site the server does not recognise still routes API calls correctly while quietly building every link in a tool result against the US1 app.

Fill the form.

Verify. Health check lists monitors, chosen because Datadog's own key-validation tool reports bad keys as a successful result and would pass for a broken config.

Choose an authentication method.

A service account token is the modern path and needs Grafana 9.1 or later. Go to Administration → Users and access → Service accounts, create one with the Viewer role, then Add service account token and copy it. The deprecated API keys are not used.

Older on-prem instances have no service accounts. Pick Username + password there and use a dedicated read-only Grafana login. Basic auth sends those credentials on every request, so a person's own login is the wrong thing to put here. An SSO-only account cannot authenticate this way at all.

Pick one. Grafana resolves a token ahead of a username and password and does it silently, so leaving both filled in would mean the password is ignored with nothing to say so, which is why this is a choice rather than two optional boxes.

Work out the URL as the container sees it. This server runs inside Docker, so localhost is the container itself. A Grafana on the same machine must be addressed as http://host.docker.internal:3000.

Find the organization ID, if the instance has more than one. Open Administration → General → Organizations and read the number out of the URL. On a single-organization instance leave this blank.

Fill the form.

Verify. Health check searches dashboards, deliberately not the datasource list, which stock RBAC hides from Viewers.

Create a user API token. PagerDuty → User Settings → API Access → Create API User Token. Mint it from an account with at least Responder-level visibility of the services you care about.

It has to be a user token, and that is a requirement rather than a preference. The server calls /users/me when it starts, to work out whose name to act under for the REST API's From: header. An account-level REST API key authenticates perfectly well but has no user behind it, so that lookup comes back empty, and the failure is swallowed rather than reported. The server then runs with no identity, and get_user_data, which is this integration's own health check, cannot answer.

An Events API v2 integration key does not work here either.

Fill the form.

Verify. Health check reads the token's own user record.

Install app 7931 on the Splunk instance and enable it.

Create an authentication token. Splunk → Settings → Tokens → New Token, with its audience set to mcp. Searches run under the token's own Splunk role, so a read-only role is what keeps this read-only, and that role needs the mcp_tool_execute capability.

Fill the form.

Verify. Health check reads instance info.

Create a User key from a read-only user. New Relic → Administration → API keys → Create a key → User key. Licence keys and browser keys do not work.

A User key carries the permissions of the user it belongs to, so the user is the scope: create the key from an account given the standard Read only user type (or a custom group whose roles grant only read capabilities), not from an admin. That user's limits are what stand behind the missing write block called out above.

Find the account ID: the numeric id under Administration → Access management.

Fill the form.

Verify. Health check fetches account metadata, so it fails on both a bad key and an account the key cannot see.

Create a personal API key. PostHog → Settings → Personal API keys → Create key, with the MCP Server preset. A project API key (phc_…) is write-only ingestion and is not accepted here.

The key also decides the region. The hosted endpoint routes to US or EU Cloud from the key itself, which is why there is no host field on the form.

Fill the form.

Verify. Health check is organizations-get. It takes no arguments, is annotated read-only, and fails on a bad key where merely listing tools would not.

Create a platform token under Dynatrace's identity and access management settings. Give it app-engine:apps:run and the storage:*:read scopes for the data you want reachable: logs, spans, metrics, events, entities, bizevents, security.events, system, buckets, smartscape, files. Add davis-copilot:*:execute and davis:analyzers:read / :execute for the CoPilot and analyzer tools. Leave out every write scope (storage:events:write, email:emails:send, document:documents:write). This is a requirement, not advice: a platform token is used for every call as is, so its scopes are the outer boundary. Triagic also refuses any Davis analyzer name that isn't a plain dotted id, so that tool can't be pointed at another platform API.

A classic API token (dt0c01.…) doesn't work here. An OAuth client with the same scopes does: pick OAuth client as the method and paste both the ID and the secret.

Fill the form.

Verify. The server tests the token as it starts, then the health check reads the environment's own record.

Create a Management API key. Only team owners can. Give it the Model Context Protocol and Environments scopes with Read, and leave Write off. Honeycomb's write tools (boards, triggers, SLOs, recipients, Canvas) need the write scope, so a Read-only key can't run them whatever the agent asks.

Ingest and configuration keys are a different credential and don't work here.

Fill the form.

Verify. Health check reads your team name and environments, which fails on a bad key.