Which integrations are available for this server?

Provides tools to query continuous profiling data from Grafana Pyroscope, including flamegraphs, hotspot functions, memory allocations, and label discovery.

How do I use pyroscope-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pyroscope-mcp Show the hottest CPU functions for api-gateway in the last 30 minutes" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

pyroscope-mcp

by mahigadamsetty

Overview Schema Related Servers Score Discussions

TypeScript

Remote

pyroscope-mcp

A read-only Model Context Protocol (MCP) server for Grafana Pyroscope. Lets AI assistants query continuous profiling data — flamegraphs, hotspot functions, memory allocations, label discovery — directly from any MCP-compatible client.

Note: This server is query-only. Profile ingestion is expected to be handled by your application profilers (Pyroscope SDKs, agents, or exporters).

Tools

Tool	Description
`pyroscope_render_profile`	Flamegraph + timeline data from `/pyroscope/render`
`pyroscope_label_names`	List all label names in a time range
`pyroscope_label_values`	List values for a given label (e.g. `service_name`)
`pyroscope_profile_types`	List available profile types (cpu, memory, goroutines…)
`pyroscope_series`	Fetch matching label sets for a selector
`pyroscope_connect_query`	Raw access to any `/querier.v1.QuerierService/*` endpoint

Related MCP server: Grafana MCP Server

Prerequisites

Node.js 20+
A running Pyroscope instance (local, self-hosted, or Grafana Cloud)

Setup

git clone https://github.com/your-org/pyroscope-mcp
cd pyroscope-mcp
npm install
npm run build

Configuration

All settings are provided via environment variables:

Variable	Default	Description
`PYROSCOPE_BASE_URL`	`http://localhost:4040`	Pyroscope server URL
`PYROSCOPE_AUTH_TOKEN`	—	Bearer token (Grafana Cloud or Azure AD)
`PYROSCOPE_TENANT_ID`	—	Multi-tenant org ID (`X-Scope-OrgID` header)
`PYROSCOPE_TIMEOUT_MS`	`30000`	Request timeout in milliseconds

Copy .env.example to .env and fill in your values:

cp .env.example .env

Adding to MCP Clients

VS Code (GitHub Copilot)

Create or edit .vscode/mcp.json in your workspace:

{
  "servers": {
    "pyroscope": {
      "type": "stdio",
      "command": "node",
      "args": ["${workspaceFolder}/dist/index.js"],
      "env": {
        "PYROSCOPE_BASE_URL": "http://localhost:4040"
      }
    }
  }
}

Then open the MCP: List Servers command in VS Code (Cmd+Shift+P) and start the server. Copilot Chat will automatically discover the tools.

For a global (user-level) config instead of per-workspace, add the same block to your VS Code settings.json under "mcp":

{
  "mcp": {
    "servers": {
      "pyroscope": {
        "type": "stdio",
        "command": "node",
        "args": ["/absolute/path/to/pyroscope-mcp/dist/index.js"],
        "env": {
          "PYROSCOPE_BASE_URL": "http://localhost:4040"
        }
      }
    }
  }
}

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "pyroscope": {
      "command": "node",
      "args": ["/absolute/path/to/pyroscope-mcp/dist/index.js"],
      "env": {
        "PYROSCOPE_BASE_URL": "http://localhost:4040",
        "PYROSCOPE_AUTH_TOKEN": ""
      }
    }
  }
}

Restart Claude Desktop. A hammer icon will appear in the chat input when the server is active.

On Windows, wrap the command:

{
  "mcpServers": {
    "pyroscope": {
      "command": "cmd",
      "args": ["/c", "node", "C:\\path\\to\\pyroscope-mcp\\dist\\index.js"],
      "env": {
        "PYROSCOPE_BASE_URL": "http://localhost:4040"
      }
    }
  }
}

Cursor

Open Cursor Settings → MCP and add a new server entry, or edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "pyroscope": {
      "command": "node",
      "args": ["/absolute/path/to/pyroscope-mcp/dist/index.js"],
      "env": {
        "PYROSCOPE_BASE_URL": "http://localhost:4040"
      }
    }
  }
}

Reload Cursor. The tools appear automatically in the Composer agent context.

Zed

Add to your Zed settings.json (open via Zed → Settings):

{
  "context_servers": {
    "pyroscope": {
      "command": {
        "path": "node",
        "args": ["/absolute/path/to/pyroscope-mcp/dist/index.js"],
        "env": {
          "PYROSCOPE_BASE_URL": "http://localhost:4040"
        }
      }
    }
  }
}

Any MCP-compatible client (generic stdio config)

{
  "mcpServers": {
    "pyroscope": {
      "command": "node",
      "args": ["/absolute/path/to/pyroscope-mcp/dist/index.js"],
      "env": {
        "PYROSCOPE_BASE_URL": "http://localhost:4040",
        "PYROSCOPE_AUTH_TOKEN": "your-bearer-token-if-needed",
        "PYROSCOPE_TENANT_ID": "your-org-id-if-needed"
      }
    }
  }
}

Example prompts once connected

"List all services sending profiles in the last hour."
"Show the hottest CPU functions for media-agent in the last 30 minutes."
"What is the memory allocation hotspot in api-gateway?"
"Compare CPU usage between worker-service and data-pipeline."
"What profile types are available for checkout-api?"

Notes

For multi-tenant Pyroscope, set PYROSCOPE_TENANT_ID or pass tenantId per tool call.
pyroscope_connect_query gives raw access to advanced endpoints:
- /querier.v1.QuerierService/SelectMergeStacktraces
- /querier.v1.QuerierService/SelectSeries
- /querier.v1.QuerierService/Diff
For Grafana Cloud Pyroscope, set PYROSCOPE_BASE_URL to your stack URL and PYROSCOPE_AUTH_TOKEN to a service account token.

Query smoke test

Start Pyroscope locally:

docker run -d --name pyroscope -p 4040:4040 grafana/pyroscope:latest

Query label names from the last hour:

NOW_MS=$(($(date +%s)*1000))
START_MS=$((NOW_MS-3600000))
curl -sS -H 'Content-Type: application/json' \
  -d "{\"start\":$START_MS,\"end\":$NOW_MS}" \
  http://localhost:4040/querier.v1.QuerierService/LabelNames

Query service names from the last hour:

NOW_MS=$(($(date +%s)*1000))
START_MS=$((NOW_MS-3600000))
curl -sS -H 'Content-Type: application/json' \
  -d "{\"name\":\"service_name\",\"start\":$START_MS,\"end\":$NOW_MS}" \
  http://localhost:4040/querier.v1.QuerierService/LabelValues

Available Tools

6 tools

pyroscope_connect_queryC

Execute any Pyroscope Connect query endpoint with a raw JSON request body.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Raw JSON body for the selected endpoint.
`baseUrl`	No
`endpoint`	Yes	Connect query endpoint path, e.g. /querier.v1.QuerierService/SelectMergeStacktraces
`tenantId`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only says 'Execute', which could imply read or write. It does not mention authentication, rate limits, side effects, or response behavior. This is minimal for a generic query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but for a generic tool that takes a raw JSON body and endpoint, it could benefit from more structure (e.g., example usage). It is not wasteful but also not optimally informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and the complexity of a generic query tool (nested body, multiple endpoints), the description is incomplete. It fails to explain how to construct the body, what endpoints are valid, or what the response contains. Users would need external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (body and endpoint have descriptions). The description adds no new semantics beyond repeating the schema descriptions for these two parameters, and leaves baseUrl and tenantId completely undocumented. It does not compensate for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Execute' and the resource 'Pyroscope Connect query endpoint'. It implies generic query execution, which distinguishes it from sibling tools focused on specific labels or profiles. However, it does not explicitly differentiate from siblings or explain what 'connect query' means.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs. alternatives. It says 'any' endpoint but does not specify contexts where this is preferred over the specific Pyroscope tools listed as siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pyroscope_label_namesC

List available label names via Connect API.

ParametersJSON Schema

Name	Required	Description
`end`	No	End timestamp in milliseconds since epoch.
`start`	No	Start timestamp in milliseconds since epoch.
`baseUrl`	No
`matchers`	No	Optional label selectors.
`tenantId`	No

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It implies a read operation ('List') but lacks details on authentication needs, rate limits, or whether the operation is safe. The phrase 'via Connect API' is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. However, it could include a bit more context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no annotations, and no output schema, the description is insufficient. It does not explain the return format, how parameters filter results, or how this tool relates to its siblings (e.g., pyroscope_label_values).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 60% (3 out of 5 parameters have descriptions). The tool description adds no extra meaning to the parameters; it does not explain how 'start', 'end', or 'matchers' affect the label names returned. Parameters 'baseUrl' and 'tenantId' lack descriptions both in schema and tool description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List', resource 'label names', and method 'Connect API'. It distinguishes from siblings like 'pyroscope_label_values' (which lists values for a given label) but does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., pyroscope_label_values or pyroscope_series). The agent receives no context about prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pyroscope_label_valuesC

List label values for a given label name via Connect API.

ParametersJSON Schema

Name	Required	Description
`end`	No	End timestamp in milliseconds since epoch.
`name`	Yes	Label name, e.g. service_name
`start`	No	Start timestamp in milliseconds since epoch.
`baseUrl`	No
`matchers`	No	Optional label selectors.
`tenantId`	No

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It only states 'via Connect API' but does not disclose pagination, rate limits, authentication requirements, or behavior for missing labels.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, front-loaded sentence that is efficient and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 6 parameters and lack of output schema or annotations, the description is too brief. It omits return values, error handling, and context for optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema description coverage, the tool description does not add any meaning beyond the schema. Parameters like baseUrl and tenantId remain undescribed, and the description doesn't clarify their usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly specifies verb 'list', resource 'label values', and constraint 'for a given label name'. It distinguishes from sibling tools like pyroscope_label_names but does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as pyroscope_label_names or pyroscope_series. Lacks context about prerequisites or when-not-to-use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pyroscope_profile_typesC

List available profile types via Connect API.

ParametersJSON Schema

Name	Required	Description
`end`	No	End timestamp in milliseconds since epoch.
`start`	No	Start timestamp in milliseconds since epoch.
`baseUrl`	No
`tenantId`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only says 'List', implying read-only behavior, but fails to disclose any additional behavioral traits such as authentication requirements, rate limits, or response format. With no annotations, the burden falls entirely on the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is appropriately front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no annotations, and no output schema, the description is critically incomplete. It lacks any information about response structure, error handling, or usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only 'end' and 'start' have descriptions). The description does not explain any parameters, nor does it provide context for 'baseUrl' or 'tenantId'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'List' and the resource 'available profile types via Connect API'. It provides a specific verb and resource, but does not differentiate from sibling tools like pyroscope_label_names or pyroscope_series.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusion conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pyroscope_render_profileB

Query the legacy /pyroscope/render endpoint for flamegraph and timeline data.

ParametersJSON Schema

Name	Required	Description
`from`	No	Start time (e.g. now-1h or unix ms). Defaults to now-1h.
`query`	Yes	Pyroscope query, e.g. process_cpu:cpu:nanoseconds:cpu:nanoseconds{service_name="api"}
`until`	No	End time (e.g. now). Defaults to now.
`format`	No	Response format.
`baseUrl`	No	Optional per-request Pyroscope base URL override.
`groupBy`	No	Single label to group timeline by.
`maxNodes`	No	Maximum nodes in returned flamegraph.
`tenantId`	No	Optional per-request tenant override.

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries full burden for behavioral disclosure. It only mentions 'legacy' but fails to disclose idempotency, data sensitivity, authentication requirements, or potential side effects. The description does not add meaningful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but at the expense of necessary detail for an 8-parameter tool. It is not overly verbose, but it leaves important information out.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (8 parameters, no output schema, no annotations), the description fails to address return format, pagination, error handling, or how the results relate to sibling tools. It is too brief to be complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 8 parameters. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline expectation but not exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Query', the resource 'legacy /pyroscope/render endpoint', and the data types 'flamegraph and timeline data'. It distinguishes the tool from siblings by focusing on this specific legacy endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the sibling tools (e.g., pyroscope_connect_query). It lacks context about prerequisites, use cases, or scenarios where this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pyroscope_seriesC

Return profile series for given matchers via Connect API.

ParametersJSON Schema

Name	Required	Description
`end`	No	End timestamp in milliseconds since epoch.
`start`	No	Start timestamp in milliseconds since epoch.
`baseUrl`	No
`matchers`	No	Matchers like {service_name="checkout"}.
`tenantId`	No
`labelNames`	No	Optional label names to return.

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden for behavioral disclosure but only states a return action. No information about side effects, permissions, idempotency, or response format is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with one sentence, but it sacrifices useful detail. Front-loading the verb and resource is good, but it could be slightly expanded for clarity without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is insufficient. It does not explain return values, error handling, or provide a complete picture for a tool with six parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'given matchers' but does not add explanatory value beyond the schema for parameters like baseUrl and tenantId (which lack schema descriptions). The 67% schema coverage is not compensated by the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and resource ('profile series') with additional context ('for given matchers via Connect API'), clearly stating the tool's function. However, it does not differentiate from sibling tools like pyroscope_connect_query, which could also return series.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives or any exclusions. The description lacks any contextual cues for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 12, 2026
- First observedpyroscope_connect_query
- First observedpyroscope_label_names
- First observedpyroscope_label_values
- First observedpyroscope_profile_types
- First observedpyroscope_render_profile
- First observedpyroscope_series

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: executing raw queries, listing labels, label values, profile types, rendering profiles, and retrieving series. No two tools have overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent 'pyroscope_{verb_or_noun}' pattern in snake_case, making the set predictable and easy to navigate.

Tool Count4/5

Six tools is a reasonable count for a profiling API client, covering essential operations without being too sparse or bloated. Slight under-coverage is possible but acceptable.

Completeness4/5

The set covers key Pyroscope API operations: querying, metadata (labels, profile types), and data retrieval (render, series). Minor gaps like specific profile operations or CRUD might exist but are not critical for typical usage.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Polar SignalsOAuth
com.polarsignals.api
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
Monitoring Developer Tools Observability
2
Grafbase
com.grafbase.api
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
API Testing Search Developer Tools
2
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
Foam Observability
io.github.foam-ai
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Observability Monitoring Developer Tools
2

Related MCP Servers

Signoz MCP Server
Observability Monitoring
DrDroidLab
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI assistants to interact with Signoz observability platform, providing tools to query dashboards, metrics, traces, logs, and APM data with time range support.
Updated 6 months ago (2026-03-04 19:02 UTC)
14
MIT
Grafana MCP Server
Observability Monitoring
DrDroidLab
A
license
A
quality
D
maintenance
A server that enables AI assistants to access and query Grafana dashboards, metrics, logs, and configurations through an MCP protocol interface.
Updated a year ago (2025-07-24 16:55 UTC)
10
6
MIT
observability-mcp
ThainaJardim
A
license
A
quality
D
maintenance
MCP server that enables AI assistants to query Grafana/Loki logs and Thanos/Prometheus metrics directly from MCP-compatible clients like Cursor or Claude Desktop.
Updated 6 months ago (2026-03-17 22:18 UTC)
8
MIT
langfuse-observability-mcp
Observability Monitoring
Sesame2
A
license
Not graded
quality
B
maintenance
A read-only MCP server that enables agents to query and analyze Langfuse observability data, including traces, sessions, observations, scores, and metrics.
Updated a month ago (2026-08-11 02:13 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mahigadamsetty/pyroscope-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server