Logflare 관리 API를 위한 MCP 서버입니다. MCP 클라이언트(Claude Code, Claude Desktop, Cursor 등)에 stdio를 통해 소스, 엔드포인트 및 임시 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 buildhttps://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셸에서 스모크 테스트:
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 사양에 따름). 레거시 X-API-KEY 헤더로 돌아가려면 LOGFLARE_AUTH_STYLE=x-api-key를 설정하세요.
execute_query는 bq_sql, pg_sql, ch_sql 중 정확히 하나만 허용합니다.
execute_query보다는 저장된 엔드포인트를 사용하는 query_endpoint를 선호하십시오. 저장된 엔드포인트는 Logflare 측에서 매개변수 유효성 검사 및 캐싱을 제공합니다.
MIT
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.
