> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Using AppSignal MCP

How AppSignal MCP behaves once it is connected: what it logs, what to do when a tool call fails, and which parts of AppSignal it deliberately leaves alone. To connect an agent in the first place, see [Set up AppSignal MCP](/mcp/setup).

<h2 id="usage-logging-and-data-handling">
  Usage, logging, and data handling
</h2>

<h3 id="rate-limits-and-account-access">
  Rate limits and account access
</h3>

AppSignal applies no rate limit specific to MCP. Tool calls run through the same infrastructure as the rest of `appsignal.com` and share its general protections.

What gates access is your account's plan. A locked account, or a free account past its trial and usage limit, gets an error instead of data — the same restriction the rest of the AppSignal API uses.

<h3 id="what-appsignal-mcp-logs">
  What AppSignal MCP logs
</h3>

AppSignal logs each tool call for reliability and abuse prevention: the tool name, the arguments you pass, and your account and user IDs. `get_more_tools` also logs the capability you asked for. Your email and organization name can appear in a tool's reply, but the log stores IDs, not those.

Because arguments are logged, don't pass secrets in free-text parameters such as log queries. MCP logs follow AppSignal's general [log retention](/logging); there is no separate retention window for MCP.

<h3 id="data-handling-and-compliance">
  Data handling and compliance
</h3>

MCP reads and writes the same data as the rest of AppSignal, so it inherits AppSignal's data handling. AppSignal is GDPR compliant, ISO/IEC 27001 certified, and hosts data in the EU. HIPAA coverage is available through a Business Associate Agreement add-on.

For the details, see [GDPR](/appsignal/gdpr), [Security](/appsignal/security), and [Business add-ons](/support/business-add-ons).

<h2 id="troubleshooting">
  Troubleshooting
</h2>

<h3 id="the-server-won’t-connect-or-oauth-fails">
  The server won't connect, or OAuth fails
</h3>

Fall back to a Bearer token. Generate an [MCP token][appsignal-mcp-token] and use the Bearer token tab for your editor. In Claude Code:

```bash Bash theme={null}
claude mcp add --transport http appsignal https://appsignal.com/api/mcp \
  --header "Authorization: Bearer <YOUR_MCP_TOKEN>"
```

Then run `claude mcp list` to confirm AppSignal shows as connected.

<h3 id="no-applications-show-up">
  No applications show up
</h3>

Your OAuth sign-in authorized a different organization, or your MCP token isn't scoped to the apps you expect. Ask the agent to *"list my AppSignal applications"*. If the list is empty or missing apps, sign in again and pick the right organization, or regenerate the token with those applications selected.

<h3 id="”application-not-found”">
  "Application not found"
</h3>

`app_name` and `app_environment` are matched case-insensitively, but they must otherwise match an app you can access. The error lists those applications — retry with an exact name and environment from the list.

<h3 id="a-tool-call-reports-that-access-is-restricted">
  A tool call reports that access is restricted
</h3>

Your account is locked, or a free account has passed its trial and usage limit. MCP uses the same access rules as the rest of the AppSignal API. Resolve the plan or billing state, then retry.

<h3 id="github-copilot-in-vs-code-shows-no-mcp-servers">
  GitHub Copilot in VS Code shows no MCP servers
</h3>

On Copilot Business or Enterprise, MCP servers are disabled by default and gated by an [organization policy][copilot-policies]. An org owner sets **Settings → Copilot → Policies → Features → MCP servers in Copilot** to **Enabled**, then reconnect.

<h3 id="gemini-cli-lists-appsignal-as-disabled">
  Gemini CLI lists AppSignal as disabled
</h3>

Gemini CLI disables MCP servers in [folders you haven't trusted][gemini-trusted-folders], and reports `MCP servers are configured but disabled because this folder is untrusted`. It suppresses user-level servers in those folders too, so a correct config still yields no AppSignal tools. Run `/permissions` inside the CLI to trust the folder, then run `gemini mcp list` again.

<h3 id="missing-any-tools">
  Missing any tools?
</h3>

An MCP token exposes only the toolsets you selected when you created it. A token created before a tool shipped won't include it unless you set the token to expose new tools automatically. Regenerate the token, or create one with the toolset enabled. OAuth exposes all read and write tools, so switch to OAuth if you want everything.

<h2 id="scope-and-roadmap">
  Scope and roadmap
</h2>

<h3 id="outside-the-toolset’s-scope">
  Outside the toolset's scope
</h3>

A few AppSignal features are intentionally not exposed through dedicated MCP tools. In most cases there's already a better way to access the data, or a natural-language interface isn't the right fit for the job. Every tool exposed also takes up space in your agent's context, so we'd rather keep the toolset focused than mirror every part of the app.

* **Uptime monitor management**: creating or changing uptime monitors is not exposed. You can still list your monitors and their settings through [`get_app_resources`](/mcp/reference#get_app_resources). Uptime results are stored as metrics (`uptime_monitor_error_count` and `uptime_monitor_duration`), so you can compute uptime yourself through the metrics tools (`get_metric_names`, `get_metric_tags`, `get_metrics_timeseries`, and `get_metrics_list`).
* **Notifier, user, and deploy marker management**: creating or modifying these requires owner-level permissions and has real consequences: a misinterpreted prompt could grant the wrong person access or misroute alerts. Admin operations like these are better handled in the AppSignal UI, where they're explicit and easy to audit. You can still read notifiers, users, and deploy markers through `get_app_resources`.
* **Custom metric and signal ingestion**: AppSignal's ingest path runs on dedicated endpoints optimized for high-throughput delivery, and AppSignal MCP is not designed for pushing data. To send [custom metrics](/metrics/custom), use the AppSignal integration in your application.

<h3 id="on-the-roadmap-if-there’s-demand">
  On the roadmap if there's demand
</h3>

* **Process monitor querying**: read access to cron and heartbeat process monitor data. We'd like to gauge interest before adding this.

These are current stances and can change as the way agents work evolves. If you hit a wall with the current toolset, let us know in the [Discord community][discord] so we can weigh it against the list.

<h2 id="getting-help">
  Getting help
</h2>

We encourage you to join our [Discord community][discord] where you can:

* Get help with AppSignal MCP setup
* Share feedback and suggestions
* Connect with other developers using AppSignal MCP
* Stay updated on new features and improvements

Look for the dedicated `#mcp` channel where our team actively monitors and responds to questions.

[appsignal-mcp-token]: https://appsignal.com/users/mcp_tokens

[discord]: https://discord.gg/fT2cbMuQSJ

[copilot-policies]: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-organization/manage-policies

[gemini-trusted-folders]: https://google-gemini.github.io/gemini-cli/docs/cli/trusted-folders.html