This document tracks feature parity between appsignal-cli and the AppSignal MCP server.
Status legend:
- Not started
- [~] Partial parity
- Complete
- [n/a] Not a CLI parity target
Key implementation difference:
- The MCP server has access to internal APIs and direct application data.
- The CLI currently uses the public GraphQL API, and may need REST endpoints for metrics and other missing features.
REST migration tracking:
- See
rest-todo.mdfor the current GraphQL-to-REST migration inventory and implementation order.
Implemented in the CLI today:
- Applications and org discovery
- App resources: users, notifiers, namespaces, dashboards
- Incident listing, incident detail, incident update, incident notes
- Log search, log tail, log views, log sources
- Trigger listing, creation, update, and archiving
Still missing or incomplete:
- Metrics discovery and querying
- Dashboard visual management
- Trace inspection
- Log line action management
- Deploy marker access
- Full performance overview parity
- Some incident filter parity
-
apps list -
apps find --name <name> [--environment <env>] -
apps info --app-id <id>
Notes:
- The CLI requires org resolution because it works through the public API.
- The org slug is persisted after
apps listorapps set-org --org ....
- [~]
apps resources <resource> -
apps resources users -
apps resources notifiers -
apps resources namespaces -
apps resources dashboards -
apps resources deploy-markerscoversdeploy_markers -
apps resources allprovides the combined view -
logs sourcescoverslog_sources -
logs viewscoverslog_views - [n/a] Do not expose
log_line_actionsdirectly; uselogs metricsandlogs triggers
Notes:
- The MCP tool returns more resource sections than the current CLI does.
- The CLI now prefers one resource per call, with
allas the explicit batch mode. - The remaining work is extending coverage.
- [~]
incidents list-exceptions
Covered today:
--app/--environmentor--app-id--namespaces--action--state(single state)--query--limit/--offset
Still missing:
-
start -
end -
revision - multiple states in a single request
Notes:
- The current GraphQL query only supports a single incident state enum.
- Time-range and deploy-scoped filters may require different API support.
- [~]
incidents list-anomalies
Covered today:
- app selection
- pagination via
--limit/--offset --state
Still missing:
-
trigger_id - anomaly-specific states such as
warmup,cooldown, andarchived
-
incidents show --number <N>
Notes:
- The CLI incident detail query already handles multiple incident union types.
- [~]
incidents update --number <N>
Covered today:
--state--severity--assign--assign-me--unassign--description- bulk state updates by explicit incident number
Still missing:
- bulk severity, assignee, or description updates
Notes:
- The CLI resolves assignee names case-insensitively and merges them with the current incident assignee list.
-
incidents add-note --number <N> --content "..."
- [~]
incidents list-performance
Covered today:
- app selection
--namespaces--action--state--query- pagination via
--limit/--offset
Still missing:
-
start -
end -
revision - OTel action ranking output
- richer performance overview beyond incident listing
- [~]
samples/traces
Covered today:
- list samples/traces for a performance action with
samples list - fetch samples/traces from a performance incident with
samples incident - fetch error traces from an exception incident with
samples incident - list error traces for an exception digest with
samples errors - inspect a trace tree by trace ID with
samples show - inspect a span by span ID with
samples show --span-id - inspect an error trace tree or span with
samples show-error - inspect performance or exception traces from an incident number with
samples show-incident - cursor pagination with
--page-all
-
logs search
Covered today:
querysource_idsstart/endlimitorder- JSON output for machine-readable use
CLI extras:
logs tail--viewsupport that resolves saved log views by name or ID--page-allto auto-paginate beyond the 100-line API limit
-
triggers list
-
triggers create -
triggers update
-
triggers archive
- Not implemented
- Not implemented
- Not implemented
- Not implemented
- Not implemented
Likely implementation work:
- Add
metrics discover - Add
metrics names - Add
metrics tags - Add
metrics list - Add
metrics timeseries
Notes:
- Metrics parity likely requires REST endpoints under
/api/v2/metrics/.... - The MCP server also has category-level discovery behavior that may rely on server-side config unavailable to the CLI.
-
dashboards create -
dashboards update
- Not implemented
- Not implemented
Likely implementation work:
- Add
dashboards create - Add
dashboards update - Add
dashboards add-visual - Add
dashboards update-visual
- [~] Public CLI UX is split by product concept instead of exposing raw actions
Implemented today:
-
logs metrics list -
logs metrics create -
logs metrics update -
logs metrics delete -
logs triggers list -
logs triggers create -
logs triggers update -
logs triggers delete
Still missing / undecided:
- Decide whether log filters need a public CLI surface
- [~] Covered indirectly by
logs metrics deleteandlogs triggers delete
- [n/a] Internal ingestion-order concept, not part of the public CLI UX for now
Likely implementation work:
- Add
logs metrics list - Add
logs metrics create - Add
logs metrics update - Add
logs metrics delete - Add
logs triggers list - Add
logs triggers create - Add
logs triggers update - Add
logs triggers delete - Decide whether to add public
logs filters ...commands
- [n/a] Internal MCP capability-discovery tool, not a CLI feature target
- Add bulk incident updates
- Add missing incident filters where the public API allows them
- Add
triggers list - Add metrics name and tag discovery
- Add metrics timeseries and aggregated list queries
- Add broader metrics discovery if the underlying API supports it cleanly
- Evaluate whether log filters need a public CLI surface
- Add dashboard create/update
- Add dashboard visual create/update
- Add log filter CLI support if product requirements justify it
- Add richer performance overview behavior
- Add exception/performance timeframe and deploy filters if an API path exists
- The public GraphQL API already covers more than the previous TODO suggested; this file was stale.
- Metrics likely require REST support in the CLI in addition to the existing GraphQL client.
- Trigger, dashboard, and log rule parity depends on whether the public API exposes the needed queries and mutations.
- Anomaly state handling may differ from exception/performance incident state enums, so state support should be verified before designing CLI flags.