Supports executing SQL queries against ClickHouse via the Logflare Management API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@logflare-mcp list all sources"
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.
MCP server for the Logflare Management API. Exposes sources, endpoints, and ad-hoc SQL query tools to MCP clients (Claude Code, Claude Desktop, Cursor, …) over stdio.
Built on the official @modelcontextprotocol/sdk and talks directly to the public
Logflare REST API — no third-party auth proxy.
Tool | Description |
| List all sources available to the API key |
| Fetch a single source by token |
| Inferred field types for a source |
| Most recent events from a source |
| Saved query endpoints |
| Run a saved endpoint by UUID or name, with parameters |
| Run ad-hoc 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 buildGet your Logflare API key from https://logflare.app/access-tokens.
cp .env.example .env
# edit .env and paste your keyVariable | Required | Default | Notes |
| yes | — | Access token |
| no |
| For self-hosted Logflare |
| no |
| Use |
| no | — | Default source when the tool arg is omitted |
claude mcp add logflare -- node /absolute/path/to/logflare-mcp/dist/index.jsOr add manually to ~/.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"
}
}
}
}Edit ~/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 typecheckSmoke test from the 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.jsAuth defaults to Authorization: Bearer <key> (per Logflare's OpenAPI spec). Set
LOGFLARE_AUTH_STYLE=x-api-key to fall back to the legacy X-API-KEY header.
execute_query accepts exactly one of bq_sql, pg_sql, ch_sql.
Prefer query_endpoint with saved endpoints over execute_query; saved endpoints
give you parameter validation and caching on Logflare's side.
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. Dates show when Glama detected each change.
v0.1.0execute_queryget_recent_eventsget_sourceget_source_schemalist_endpointslist_sourcesquery_endpointEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Access New Relic observability data through MCP - query metrics, logs, traces, entities, and more
MCP server for interacting with the Supabase platform
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Query metrics, targets, entities, and team data in your Steep workspace via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fasterv410/logflare-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
