Skip to main content
Glama
deenesjakoruzh
pydantic

Logfire MCP Server

Official
by pydantic
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Logfire MCP 服务器

该存储库包含一个模型上下文协议 (MCP) 服务器，其中的工具可以访问您发送到 Logfire 的 OpenTelemetry 跟踪和指标。

该 MCP 服务器使 LLM 能够检索应用程序的遥测数据、分析分布式跟踪并利用使用 Logfire API 执行的任意 SQL 查询的结果。

可用工具

  • find_exceptions - 从按文件分组的跟踪中获取异常计数

    • 必需参数：

      • age （int）：回顾的分钟数（例如，过去 30 分钟为 30，最多 7 天）

  • find_exceptions_in_file - 获取特定文件中异常的详细跟踪信息

    • 必需参数：

      • filepath （字符串）：要分析的文件路径

      • age （int）：回顾的分钟数（最多 7 天）

  • arbitrary_query - 在 OpenTelemetry 跟踪和指标上运行自定义 SQL 查询

    • 必需参数：

      • query （字符串）：要执行的 SQL 查询

      • age （int）：回顾的分钟数（最多 7 天）

  • get_logfire_records_schema - 获取 OpenTelemetry 模式以帮助进行自定义查询

    • 无需参数

Related MCP server: Observe MCP Server

设置

安装uv

首先要做的是确保安装了uv ，因为uv用于运行 MCP 服务器。

有关安装说明，请参阅uv安装文档。

如果您已经安装了旧版本的uv ，则可能需要使用uv self update进行更新。

获取 Logfire 读取令牌

为了向 Logfire API 发出请求，Logfire MCP 服务器需要一个“读取令牌”。

您可以在 Logfire 中的项目设置的“读取令牌”部分下创建一个： https://logfire.pydantic.dev/-/redirect/latest-project/settings/read-tokens

[!IMPORTANT] Logfire 读取令牌是特定于项目的，因此您需要为想要向 Logfire MCP 服务器公开的特定项目创建一个令牌。

手动运行服务器

一旦安装了uv并拥有 Logfire 读取令牌，您就可以使用uvx （由uv提供）手动运行 MCP 服务器。

您可以使用LOGFIRE_READ_TOKEN环境变量指定读取令牌：

LOGFIRE_READ_TOKEN=YOUR_READ_TOKEN uvx logfire-mcp

或使用--read-token标志：

uvx logfire-mcp --read-token=YOUR_READ_TOKEN

[！笔记]
如果您使用 Cursor、Claude Desktop、Cline 或其他 MCP 客户端来管理您的 MCP 服务器，则无需手动运行服务器。下一节将向您展示如何配置这些客户端以使用 Logfire MCP 服务器。

使用知名 MCP 客户端进行配置

配置光标

在项目根目录中创建一个.cursor/mcp.json文件：

{
  "mcpServers": {
    "logfire": {
      "command": "uvx",
      "args": ["logfire-mcp", "--read-token=YOUR-TOKEN"]
    }
  }
}

Cursor 不接受env字段，因此您需要使用--read-token标志。

配置 Claude 桌面

添加到您的 Claude 设置：

{
  "command": ["uvx"],
  "args": ["logfire-mcp"],
  "type": "stdio",
  "env": {
    "LOGFIRE_READ_TOKEN": "YOUR_TOKEN"
  }
}

为 Cline 配置

在cline_mcp_settings.json中添加到您的 Cline 设置：

{
  "mcpServers": {
    "logfire": {
      "command": "uvx",
      "args": ["logfire-mcp"],
      "env": {
        "LOGFIRE_READ_TOKEN": "YOUR_TOKEN"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

自定义 - 基本 URL

默认情况下，服务器会连接到 Logfire API，网址为https://logfire-api.pydantic.dev 。你可以使用以下方式覆盖此设置：

  1. 使用--base-url参数：

uvx logfire-mcp --base-url=https://your-logfire-instance.com

  1. 设置环境变量：

LOGFIRE_BASE_URL=https://your-logfire-instance.com uvx logfire-mcp

交互示例

  1. 查找过去一小时的跟踪中的所有异常：

{
  "name": "find_exceptions",
  "arguments": {
    "age": 60
  }
}

回复：

[
  {
    "filepath": "app/api.py",
    "count": 12
  },
  {
    "filepath": "app/models.py",
    "count": 5
  }
]

  1. 从特定文件中的跟踪获取有关异常的详细信息：

{
  "name": "find_exceptions_in_file",
  "arguments": {
    "filepath": "app/api.py",
    "age": 1440
  }
}

回复：

[
  {
    "created_at": "2024-03-20T10:30:00Z",
    "message": "Failed to process request",
    "exception_type": "ValueError",
    "exception_message": "Invalid input format",
    "function_name": "process_request",
    "line_number": "42",
    "attributes": {
      "service.name": "api-service",
      "code.filepath": "app/api.py"
    },
    "trace_id": "1234567890abcdef"
  }
]

  1. 对跟踪运行自定义查询：

{
  "name": "arbitrary_query",
  "arguments": {
    "query": "SELECT trace_id, message, created_at, attributes->>'service.name' as service FROM records WHERE severity_text = 'ERROR' ORDER BY created_at DESC LIMIT 10",
    "age": 1440
  }
}

克劳德的问题示例

  1. “过去一小时所有服务的追踪中出现了哪些异常？”

  2. “显示文件‘app/api.py’中最近的错误及其跟踪上下文”

  3. “过去 24 小时内每个服务有多少个错误？”

  4. “按服务名称分组，我的跟踪中最常见的异常类型是什么？”

  5. “获取跟踪和指标的 OpenTelemetry 模式”

  6. “查找昨天的所有错误并显示其跟踪上下文”

入门

  1. 首先，从以下位置获取 Logfire 读取令牌： https://logfire.pydantic.dev/-/redirect/latest-project/settings/read-tokens

  2. 运行 MCP 服务器：

    uvx logfire-mcp --read-token=YOUR_TOKEN

  3. 使用上面的配置示例配置您的首选客户端（Cursor、Claude Desktop 或 Cline）

  4. 开始使用 MCP 服务器分析您的 OpenTelemetry 跟踪和指标！

贡献

我们欢迎您为改进 Logfire MCP 服务器做出贡献。无论您是想添加新的跟踪分析工具、增强指标查询功能，还是改进文档，您的贡献都弥足珍贵。

有关其他 MCP 服务器和实现模式的示例，请参阅模型上下文协议服务器存储库。

执照

Logfire MCP 采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。

Available Tools

4 tools
arbitrary_queryB

Run an arbitrary query on the Pydantic Logfire database.

The SQL reference is available via the `sql_reference` tool.
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe query to run, as a SQL string.
ageYesNumber of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 30 days.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It fails to disclose behavioral traits such as potential for destructive actions, permissions, rate limits, or what happens on error. Given the power of arbitrary SQL, this is insufficient.

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?

The description is two sentences: the first states the purpose concisely, the second points to a related tool for SQL reference. It is front-loaded and every sentence adds value.

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?

Despite having an output schema, the description lacks important context for an arbitrary query tool, such as safety considerations, read-only vs write capability, or behavior on failure. It is not complete enough for safe usage.

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 input schema already documents both parameters (query string and age integer). The description does not add any extra meaning beyond what the schema provides, hence a baseline score of 3.

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 states 'Run an arbitrary query on the Pydantic Logfire database,' with a specific verb and resource. It distinguishes from siblings like find_exceptions_in_file, logfire_link, and schema_reference.

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

Usage Guidelines3/5

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

The description mentions that SQL reference is available via the sql_reference tool, implying a prerequisite. However, it does not explicitly state when to use this tool vs alternatives or provide exclusions, so guidance is implied but not explicit.

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

find_exceptions_in_fileA

Get the details about the 10 most recent exceptions on the file.

ParametersJSON Schema
NameRequiredDescriptionDefault
filepathYesThe path to the file to find exceptions in.
ageYesNumber of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 30 days.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided; description does not reveal behavioral traits such as read-only nature, side effects, or permissions. Only implies retrieval but lacks explicit assurance.

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 concise sentence with no filler, front-loaded with key action and result. Every word serves purpose.

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

Completeness3/5

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

For a simple tool with schema documentation and output schema, description is adequate but lacks completeness on sorting of 'most recent' or interaction between age and filepath.

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

Parameters4/5

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

Input schema has 100% coverage; description adds nuance '10 most recent' beyond schema, but does not detail age interpretation or other edge cases.

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 states the verb 'get' and resource '10 most recent exceptions on the file', distinguishing it from siblings like 'arbitrary_query' and 'logfire_link'.

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, nor any conditions or exclusions. The description merely states function.

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

schema_referenceA

The database schema for the Logfire DataFusion database.

This includes all tables, columns, and their types as well as descriptions.
For example:

```sql
-- The records table contains spans and logs.
CREATE TABLE records (
    message TEXT, -- The message of the record
    span_name TEXT, -- The name of the span, message is usually templated from this
    trace_id TEXT, -- The trace ID, identifies a group of spans in a trace
    exception_type TEXT, -- The type of the exception
    exception_message TEXT, -- The message of the exception
    -- other columns...
);
```
The SQL syntax is similar to Postgres, although the query engine is actually Apache DataFusion.

To access nested JSON fields e.g. in the `attributes` column use the `->` and `->>` operators.
You may need to cast the result of these operators e.g. `(attributes->'cost')::float + 10`.

You should apply as much filtering as reasonable to reduce the amount of data queried.
Filters on `start_timestamp`, `service_name`, `span_name`, `metric_name`, `trace_id` are efficient.
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the SQL syntax is similar to Postgres but uses Apache DataFusion, explains how to access nested JSON, and advises on efficient filtering. No destructive actions are mentioned, which is appropriate for a read-only schema tool.

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 front-loaded with the purpose and provides detailed examples. While the SQL example takes space, it is relevant and informative. Could be slightly more concise, but overall well-structured.

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

Completeness5/5

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

Given the tool's purpose (providing schema), the description covers all necessary context: database type, SQL dialect, nested JSON access, and filtering advice. The output schema exists, so return values need not be detailed further.

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

Parameters4/5

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

The input schema has 0 parameters and 100% schema_description_coverage, so baseline is 4. The description adds value by explaining SQL syntax and operators for querying nested data, which aids in interpreting the schema output.

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 explicitly states that the tool provides the database schema for the Logfire DataFusion database, including tables, columns, types, and descriptions. This is a specific verb+resource combination that clearly distinguishes its purpose.

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

Usage Guidelines3/5

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

The description implies that this tool is used to understand the schema for crafting queries, but it does not explicitly state when to use it versus alternatives like arbitrary_query. No direct exclusions or alternative tool names are mentioned.

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.

  1. 2 tool updatesv0.8.0
    • Changedarbitrary_query1 field changed
      • changedInput schema / properties / age / description
        Previous value: -"Number of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 7 days."New value: +"Number of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 30 days."
    • Changedfind_exceptions_in_file1 field changed
      • changedInput schema / properties / age / description
        Previous value: -"Number of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 7 days."New value: +"Number of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 30 days."
  2. 6 tool updatesv1.0.0
    • Changedarbitrary_query3 fields changed
      • addedInput schema / properties / age / description
        Added value: +"Number of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 7 days."
      • addedInput schema / properties / query / description
        Added value: +"The query to run, as a SQL string."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {},
+      "title": "Result",
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "arbitrary_queryOutput",
+  "type": "object"
+}
    • Removedfind_exceptions
    • Changedfind_exceptions_in_file3 fields changed
      • addedInput schema / properties / age / description
        Added value: +"Number of minutes to look back, e.g. 30 for last 30 minutes. Maximum allowed value is 7 days."
      • addedInput schema / properties / filepath / description
        Added value: +"The path to the file to find exceptions in."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {},
+      "title": "Result",
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "find_exceptions_in_fileOutput",
+  "type": "object"
+}
    • Removedget_logfire_records_schema
    • Addedlogfire_link
    • Addedschema_reference
  3. 4 tool updates
    • First observedarbitrary_query
    • First observedfind_exceptions
    • First observedfind_exceptions_in_file
    • First observedget_logfire_records_schema
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool serves a unique purpose: querying, exception viewing, link generation, and schema reference. No overlap or ambiguity.

Naming Consistency5/5

All tools use consistent snake_case naming with clear verbs (arbitrary_query, find_exceptions_in_file, logfire_link, schema_reference).

Tool Count5/5

With 4 tools, the set is concise and well-scoped for querying and debugging Logfire databases, covering key workflows without bloat.

Completeness4/5

The set covers querying, schema exploration, exception analysis, and UI linking. Missing explicit write operations, but that may be by design.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Datadog MCP Server

    brukhabtu
    F
    license
    B
    quality
    Not graded
    maintenance
    A Model Context Protocol server that enables AI assistants to interact with Datadog's observability platform through natural language.
    72
    -

  • Observe MCP Server

    rustomax
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    A Model Context Protocol server that provides access to Observe API functionality, enabling LLMs to execute OPAL queries, manage datasets/monitors, and leverage vector search for documentation and troubleshooting runbooks.
    1
    -

  • MLflow MCP Server

    kkruglik
    A
    license
    A
    quality
    A
    maintenance
    A Model Context Protocol server that enables LLMs to interact with MLflow tracking servers, allowing users to query experiments, analyze runs, compare metrics, manage the model registry, and promote models through natural language.
    40
    15
    MIT

Appeared in Searches

Latest Blog Posts

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/pydantic/logfire-mcp'

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