What kind of logs does this cover?

Different sources, by server. Supabase returns service logs (API, Postgres, edge functions); Argo CD returns pod and deployment logs; SonarQube returns its system logs; GitHub returns CI job logs. Match the server to where the problem you are chasing actually lives.

How is this different from querying metrics?

Logs are text events; metrics are numeric series. An agent reads logs to find the error message or stack trace, and queries metrics to find when something changed. Debugging usually needs both: a metric to spot the moment, logs to explain it.

MCP servers that can get logs

4 verified servers expose a tool that can retrieve logs from a system

When something misbehaves, the logs are where the why lives. Getting logs pulls them from a service, a pod, a CI job, or a system, so an agent debugging a problem reads the actual output rather than guessing from a status code.

These verified servers let an agent retrieve logs from a system.

Top pick

Supabase

Supabase (community)

Community

Connects agents to a Supabase project: run SQL, inspect schema, read logs, and manage edge functions.

databases2,710

Tool:

get_logs

Supabase's get_logs returns a project's logs by service type, API, Postgres, or edge functions, so an agent reads the right stream for the problem.

Pick 2

Argo CD

Argo Project (argoproj-labs)

Official

The Argo CD MCP server lets an agent inspect and manage GitOps applications — list and sync apps, read resource trees and workload logs, and run resource act...

devops-ci475

Tool:

get_application_workload_logs

For a GitOps-managed workload, get_application_workload_logs pulls logs from an Argo CD application's pods and deployments.

Pick 3

SonarQube

Sonar

Official

Sonar's official MCP server brings SonarQube code quality, security, and coverage analysis into your AI agent.

devops-ci563

Tool:

get_system_logs

On SonarQube, get_system_logs returns the server's own system logs in plain text, for diagnosing the analysis server itself.

Pick 4

GitHub

Official

GitHub's official remote MCP server for repos, issues, pull requests, Actions, and code search.

version-control30,334

Tool:

get_job_logs

GitHub's get_job_logs returns the logs for an Actions workflow job, the output an agent reads to see why a CI step failed.

What to know

Logs are the raw record an agent reads to find an error, trace a request, or confirm a deploy worked. Where they come from varies, which is the main thing to match: Supabase returns a project's logs by service type (API, Postgres, edge functions); Argo CD pulls logs from an application's pods and deployments; SonarQube returns its server's system logs; GitHub returns the logs for an Actions workflow job. The shape is the same, a stream of log lines, but the source decides which problem they help with.

Debugging is iterative, and logs are perishable and large, so an agent re-fetches as it narrows down. What is worth carrying across the session is the conclusion, the error it found and ruled in, not the raw dump, so a later pass starts from what it already learned rather than re-reading megabytes of output.

Questions

What kind of logs does this cover?: Different sources, by server. Supabase returns service logs (API, Postgres, edge functions); Argo CD returns pod and deployment logs; SonarQube returns its system logs; GitHub returns CI job logs. Match the server to where the problem you are chasing actually lives.
How is this different from querying metrics?: Logs are text events; metrics are numeric series. An agent reads logs to find the error message or stack trace, and queries metrics to find when something changed. Debugging usually needs both: a metric to spot the moment, logs to explain it.