Cloud

Create an IAM user with CloudWatchReadOnlyAccess (and CloudWatchLogsReadOnlyAccess if you want log queries), then generate an access key.

Or use a named profile instead, if long-lived keys are not what you want.

Choosing Named profile reads the credential out of the ~/.aws/config of the machine running Triagic: that machine's file, not the portal host's. It is the only route to assume-role, IAM Identity Center (SSO), credential_process and MFA, because none of these servers exposes a role ARN or an SSO setting of its own.

A profile that assumes a role looks like this:

[profile triagic-readonly]
role_arn = arn:aws:iam::123456789012:role/triagic-readonly
source_profile = default
region = us-east-1

and an IAM Identity Center profile like this, after aws sso login --profile triagic-sso:

[profile triagic-sso]
sso_session = corp
sso_account_id = 123456789012
sso_role_name = ReadOnly
region = us-east-1

With a profile selected, no access key is sent at all. That matters: the AWS SDK treats an empty access key as a real credential, finds it first, and never reads the profile, which is why the key fields disappear rather than being left blank.

Fill the form. All AWS integrations share this credential shape.

Verify. Start-checked only, no health check runs. The first tool call is what proves the credential.

Create an IAM user with AmazonSQSReadOnlyAccess and AmazonSNSReadOnlyAccess, or a ~/.aws/config profile as described under AWS CloudWatch above.

Fill the form: authentication method, then either the access key pair or a profile name, plus the region and an optional CA path, exactly as above. The region must be the one the queues and topics live in.

Verify. Start-checked only.

Register an app in Entra ID → App registrations → New registration. Note its Directory (tenant) ID and Application (client) ID. Skip this step if you are using the Azure CLI method.

Create a credential for it: a secret or a certificate.

Under Certificates & secrets, either New client secret or upload a certificate. A secret is quicker; a certificate lasts far longer. Client secrets cap out at two years and expire silently, and the resulting failure looks like a bad credential rather than an expiry, so a certificate is the better choice for an integration nobody is watching.

For a certificate, save the file on the machine running Triagic and give the absolute path. PEM and PFX both work. A PEM must contain the private key as well as the certificate, and only a password-protected PFX needs the password field.

For a local machine you already sign in on, Azure CLI sign-in stores no credential at all and uses whatever az login left behind. That sign-in has to belong to the user Triagic runs as, and the integration stops when it lapses.

Grant the service principal two roles: Monitoring Reader on the subscription, and Log Analytics Reader on the workspaces you want to query. Without these the sign-in succeeds and every query fails.

Fill the form.

Verify. Health check lists Log Analytics workspaces, which fails on a bad credential and on a subscription the principal was never granted.

Enable the APIs on the project: Cloud Logging API and Cloud Monitoring API. Enablement takes a minute to propagate.

Create a service account with exactly Logs Viewer (roles/logging.viewer) and Monitoring Viewer (roles/monitoring.viewer), and download its JSON key.

Place the key on the machine running Triagic, at an absolute path the desktop app can read, e.g. /opt/triagic/gcp-sa.json.

That field is not limited to service-account keys. It reads any credentials JSON Google accepts: an impersonated-service-account config or a workload-identity federation config work equally well, and are the better answer if your organization avoids long-lived keys. Point the field at that file instead.

Fill the form.

Verify. Start-checked only: every tool requires a project-scoped argument, so there is no fixed call that could serve as a health check.

Create an API token at dash.cloudflare.com → My Profile → API Tokens (or Account → API Tokens for an account-scoped one), with two permissions: Account → Workers Observability → Read, and Account → Workers Scripts → Read — the second covers the worker-listing tools above and is easy to miss because only the Observability permission is mentioned in Cloudflare's own MCP docs.

An account-scoped token needs a third permission: Account → Account Settings → Read. The server has to look up which account the token belongs to before it can query anything, and that lookup is what this permission allows. Without it, setup fails with a 403 that looks like the Observability permission is missing when it is not.

A Global API Key is not accepted; it must be an API token. The key's headers are never read, so there is nothing about the key that can be corrected.

Fill the form.

Verify. Start-checked only. Both of the server's cheap tools require a structured query argument with its own time range, and a guessed shape would report a working integration as broken.

Create an access token at vercel.com/account/tokens → Create Token. Set its Scope to the team that owns the projects you want readable. A token scoped to your personal account can't see a team's projects. Set an expiry you are willing to rotate on.

Optionally find the project scope. The team-and-project pair from the dashboard URL, e.g. acme-inc/storefront. Setting it scopes the session to that one project; leaving it blank reaches everything the token can see.

Fill the form.

Verify. Health check lists teams, an authenticated call. It is deliberately not the documentation search, which Vercel serves publicly and would pass for a token that reaches nothing.

Create an IAM user with a read-only policy scoped to what you want visible. For broad access across services, attach the AWS managed policy ReadOnlyAccess (read access to nearly everything) or SecurityAudit (narrower, security-and-config focused). For a smaller footprint, write a policy naming just the Describe*/List*/Get* actions on the services you actually want the agent to see. Generate an access key for the user.

Or point at a named profile instead. Choosing Named profile reads the credential from the ~/.aws/config of the machine running Triagic, which is the only way to reach assume-role, IAM Identity Center (SSO), credential_process or MFA. See AWS CloudWatch for the profile shapes.

This server also injects --profile <name> into every CLI command it generates, so the profile is what the command itself runs as, not only what the SDK signs with.

Fill the form.

Verify. No health check runs for this one: the underlying tool returns AWS errors as successful results with an error field, so a check could not tell a working credential from a denied one. It is start-checked only; the first real tool call is what proves the policy actually covers what you asked for.

Register an app in Entra ID → App registrations → New registration, unless you're using the Azure CLI method below. Note its Directory (tenant) ID and Application (client) ID.

Create a credential for it: a secret or a certificate. A client secret (Certificates & secrets → New client secret) is quicker to set up but expires and takes the integration down silently when it does. A certificate (Certificates & secrets → Certificates, uploading a PEM or PFX you generated) outlives that problem. Or skip both and pick Azure CLI sign-in on this machine, which borrows whoever last ran az login there — nothing is stored, but it stops working when that sign-in lapses.

Grant the service principal Reader on the subscription. This is the one material difference from Azure Monitor's setup: that entry only needs Monitoring Reader and Log Analytics Reader, because it only reads logs and metrics. This entry's router tools reach every other service too, so the principal needs the subscription-wide Reader role, not a service-specific one.

Fill the form.

Verify. Health check is subscription_list, a direct tool with no arguments that fails on a bad credential or a principal with no role anywhere.

Create the app. Admin Console → Applications → Create App Integration → API Services. Copy the Client ID.

Set client authentication. On the General tab, edit Client Credentials: choose Public key / Private key and turn off Require Demonstrating Proof of Possession (DPoP) header in token requests. The server doesn't send DPoP.

Add a key. In Public keys, Add key → Generate new key. Save the private key as PEM and copy the KID shown next to it.

Grant scopes. On Okta API Scopes, grant okta.users.read, okta.groups.read, okta.apps.read and okta.logs.read. All four are requested, so a missing one fails the sign-in.

Assign a role. On Admin roles, assign Read-Only Administrator. API service apps can't read anything without an admin role, and this one can't write either.

Fill the form.

Verify. Health check lists groups. A wrong key fails earlier, when the server starts.