用于 Logflare 管理 API 的 MCP 服务器。通过 stdio 向 MCP 客户端（如 Claude Code、Claude Desktop、Cursor 等）公开源、端点和即席 SQL 查询工具。
基于官方 @modelcontextprotocol/sdk 构建，并直接与公共 Logflare REST API 通信 — 无需第三方身份验证代理。
工具 | 描述 |
| 列出 API 密钥可访问的所有源 |
| 通过令牌获取单个源 |
| 推断源的字段类型 |
| 获取源中最近的事件 |
| 已保存的查询端点 |
| 通过 UUID 或名称运行已保存的端点，并带有参数 |
| 运行即席 BigQuery / Postgres / ClickHouse SQL |
Related MCP server: Sumo Logic MCP Server
git clone git@github.com:fasterv410/logflare-mcp.git
cd logflare-mcp
pnpm install
pnpm build从 https://logflare.app/access-tokens 获取您的 Logflare API 密钥。
cp .env.example .env
# edit .env and paste your key变量 | 必需 | 默认值 | 说明 |
| 是 | — | 访问令牌 |
| 否 |
| 用于自托管 Logflare |
| 否 |
| 旧版密钥请使用 |
| 否 | — | 省略工具参数时的默认源 |
claude mcp add logflare -- node /absolute/path/to/logflare-mcp/dist/index.js或手动添加到 ~/.claude.json：
{
"mcpServers": {
"logflare": {
"command": "node",
"args": ["/absolute/path/to/logflare-mcp/dist/index.js"],
"env": {
"LOGFLARE_API_KEY": "lf-xxxxxxxx",
"LOGFLARE_DEFAULT_SOURCE_TOKEN": "optional-uuid"
}
}
}
}编辑 ~/Library/Application Support/Claude/claude_desktop_config.json：
{
"mcpServers": {
"logflare": {
"command": "node",
"args": ["/absolute/path/to/logflare-mcp/dist/index.js"],
"env": { "LOGFLARE_API_KEY": "lf-xxxxxxxx" }
}
}
}pnpm dev # tsx watch mode
pnpm build # emit dist/
pnpm typecheck从 shell 进行冒烟测试：
LOGFLARE_API_KEY=xxx printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
| node dist/index.js身份验证默认为 Authorization: Bearer <key>（根据 Logflare 的 OpenAPI 规范）。设置 LOGFLARE_AUTH_STYLE=x-api-key 以回退到旧版 X-API-KEY 请求头。
execute_query 仅接受 bq_sql、pg_sql、ch_sql 中的一个。
优先使用 query_endpoint 和已保存的端点，而不是 execute_query；已保存的端点在 Logflare 端提供参数验证和缓存。
Run an ad-hoc SQL query. Provide exactly one dialect: BigQuery, Postgres, or ClickHouse. Prefer query_endpoint when a saved endpoint exists.
| Name | Required | Description | Default |
|---|---|---|---|
| bq_sql | No | BigQuery SQL. | |
| pg_sql | No | Postgres SQL. | |
| ch_sql | No | ClickHouse SQL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on side effects, permissions, or return format. For an execution tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the action and key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes input constraints but omits output/return information. With no output schema, more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, and the description adds the constraint that exactly one dialect should be provided, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an ad-hoc SQL query and specifies the dialects (BigQuery, Postgres, ClickHouse), distinguishing it from sibling tools like query_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to provide exactly one dialect and prefers query_endpoint when a saved endpoint exists, offering clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the most recent log events for a source. Useful for tailing and incident triage.
| Name | Required | Description | Default |
|---|---|---|---|
| source_token | No | Source token. Falls back to LOGFLARE_DEFAULT_SOURCE_TOKEN if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only indicates a read operation ('Fetch') but lacks details on return limits, pagination, error handling, or consequences of missing tokens, which an agent needs for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose and usage context without redundancy, earning every word its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While simple, the description omits crucial operational details like number of events returned, ordering, or any output format, leaving an agent to guess behavior beyond the basic fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the only parameter (source_token with fallback), and the tool description adds no additional semantic value beyond confirming the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the most recent log events for a source, using a specific verb and resource, and distinguishes it from sibling tools like execute_query by focusing on recent events for tailing and triage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usefulness for tailing and incident triage, but does not explicitly contrast with alternatives like execute_query for filtering or aggregating, leaving when-not-to-use unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single source by its token.
| Name | Required | Description | Default |
|---|---|---|---|
| source_token | Yes | Source token (UUID). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action without mentioning side effects, idempotency, authorization needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, efficiently conveying the core purpose. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description is adequate but sparse. It lacks context about the meaning of a 'source', the return value, or any usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already describes the parameter. The description adds minimal value beyond the schema, only restating that the token is a UUID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'a single source', and the method 'by its token'. It effectively distinguishes from sibling tools like 'list_sources' which handles multiple sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, when not to use it, or how it differs from alternatives such as 'list_sources' or 'execute_query'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the inferred schema (field names and types) for a source.
| Name | Required | Description | Default |
|---|---|---|---|
| source_token | No | Source token. Falls back to LOGFLARE_DEFAULT_SOURCE_TOKEN if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation by stating 'Return', but does not disclose potential issues like schema unavailability or required permissions. It is adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the purpose. However, it could benefit from a bit more context about what 'inferred' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is minimally complete. It lacks mention of return format or conditions like source not existing, but is sufficient for an agent to understand the basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with a clear description for source_token explaining fallback behavior. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the inferred schema (field names and types) for a source, using a specific verb and resource. It distinguishes well from siblings like execute_query or list_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as before executing a query with execute_query. No when-not-to-use or prerequisite conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved query endpoints for the account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether reading is safe, authentication needs, or side effects. It implicitly suggests a read operation but does not confirm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters, the description is largely complete. It could mention return format or confirm read-only behavior, but it covers the core purpose adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%, so baseline is 3. The description does not add parameter insight, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'saved query endpoints' with scope 'for the account'. It clearly differentiates from sibling tools like list_sources (lists sources) and execute_query (query execution), so it stands out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like query_endpoint or list_sources. No exclusions or alternative recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sources (log streams) accessible to the configured API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral info: it lists only sources accessible to the API key. It does not disclose side effects, rate limits, or data volume, which is acceptable for a simple read-only list operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the purpose without unnecessary words, front-loading the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description adequately covers what the tool does and its scope, making it complete enough for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description adds value by clarifying the scope of the list (accessible to the API key). Baseline for no parameters is 4; the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all sources (log streams) accessible to the configured API key, using a specific verb and resource, and implicitly distinguishes from sibling tools like get_source or get_recent_events which target specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to list all available sources) but does not explicitly state when not to use it or provide alternatives. Usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a Logflare endpoint by UUID or name. Pass endpoint parameters as a flat key/value object.
| Name | Required | Description | Default |
|---|---|---|---|
| token_or_name | Yes | Endpoint UUID or name. | |
| params | No | Query parameters forwarded to the endpoint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions parameter format, but nothing about side effects, idempotency, error behavior, or required permissions. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the core action. No unnecessary words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations, the description should explain what the tool returns or any notable behaviors. It only covers input parameters, leaving users unaware of the output format or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions (100% coverage). The description adds the nuance that params should be a 'flat key/value object', which reinforces schema constraints but does not add entirely new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a Logflare endpoint') and the input methods (UUID or name), which is specific and matches the tool name. However, it does not differentiate from the sibling tool 'execute_query', which might have similar behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'execute_query' or 'list_endpoints'. The description only states what the tool does, without any context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0execute_queryget_recent_eventsget_sourceget_source_schemalist_endpointslist_sourcesquery_endpointScored across 7 tools
Each tool targets a distinct operation: ad-hoc queries, saved endpoint execution, source retrieval, schema inspection, recent events, and listing. No two tools have overlapping purposes; descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., execute_query, list_sources). The prefixes 'get', 'list', 'execute', and 'query' are uniformly used for similar actions.
With 7 tools, the server is well-scoped for a logging/query domain. Each tool serves a clear purpose without redundancy, and the count is neither too sparse nor overwhelming.
The tool set covers core operations: listing and inspecting sources, querying via ad-hoc SQL or saved endpoints, and fetching recent events. Missing create/update/delete for sources and endpoints, but these may be out of scope for a read-focused MCP server.
Access New Relic observability data through MCP - query metrics, logs, traces, entities, and more
MCP server for interacting with the Supabase platform
Managed Postgres MCP: projects, SQL, docs search, and storage buckets via OAuth.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
