This MCP server enables an agent to read, discover, query, count, and export logs from Grafana Loki.
List configured Loki connections with hints and effective tool limits.
Discover label names, label values, full stream label sets, and values among matched streams.
Query bounded pages of logs using LogQL, with compact or raw preview, newest or oldest order.
Count matching log lines, optionally grouped by label, time buckets, or both.
Export matching logs to a local file as raw lines or rendered with a template.
Supports Loki 2.6.1 and 3.x via stdio MCP, with configurable connections, time windows, limits, and authentication.
Allows reading Grafana Loki logs via LogQL, including discovering label names and stream combinations, querying bounded log pages, counting matching lines by labels and time buckets, and exporting logs to local files.
A local stdio MCP server for reading Grafana Loki with an agent. It exposes five text tools and supports Loki 2.6.1 and 3.x. Loki itself is read only; the only write is a local exportLogs file.
Tool | Purpose |
listConnections | Show configured stands, operator hints and effective tool limits |
discoverLogs | List label names, values of one label, matching stream label sets, or values among those sets |
queryLogs | Read newest or oldest bounded pages of a LogQL log query as compact text; raw=true previews returned lines and stream labels |
countLogs | Count matching lines on Loki, optionally by label, clock aligned time bucket or both |
exportLogs | Save matching lines to a local file, raw or rendered with a template |
Every data tool requires an explicit connection. queryLogs, countLogs and exportLogs require a LogQL log query, such as {app="backend"} |= "ERROR". Use discoverLogs to find label names, values and real combinations in stream label sets. The server builds only the count_over_time expression for countLogs; it does not infer filters or interpret causes. Tool responses are readable text without an output schema.
JDK 21 or newer is required; the project uses a Java 21 toolchain and the Gradle wrapper.
.\gradlew.bat bootJar
java -jar build/libs/loki-mcp-server.jarOn Linux/macOS use ./gradlew. The process waits for MCP JSON-RPC on stdin. stdout is reserved for JSON-RPC; diagnostics go to stderr and ~/.loki-mcp-server/logs/loki-mcp-server.log.
A prebuilt loki-mcp-server.jar is attached to every release, so building is optional.
For Claude Code, registering the jar is one command:
claude mcp add --scope user loki -- java -jar /path/to/loki-mcp-server.jarThe image is published to GHCR with every release. Mount the directory holding connections.json at /data; the server also writes its logs and default exports there:
docker run -i --rm -v ~/.loki-mcp-server:/data ghcr.io/igorolv/loki-mcp-server:latestThe same command is what an MCP client should launch; -i keeps stdin open for the stdio transport. Loki URLs in connections.json must be reachable from inside the container: use the Loki host name rather than localhost, or add --network host on Linux. An exportLogs directory outside /data is a path inside the container, so mount it as well. To build the image locally: docker build -t loki-mcp-server .
Related MCP server: Loki MCP Server
The server reads ~/.loki-mcp-server/connections.json, or the path in LOKI_MCP_CONNECTIONS_FILE. A minimal file:
{
"connections": {
"dev": {
"description": "Development",
"hint": "Start with {app=\"backend\"}; inspect app values with discoverLogs.",
"url": "http://localhost:3100",
"timezone": "Europe/Moscow",
"serviceLabels": ["app", "container"]
}
}
}The complete example uses environment variables for nonlocal URLs. hint gives the model stand specific selectors and field advice. serviceLabels names the labels used to display a service in compact lines. Optional formatFile names one JSON file with JSON profiles, plain-line patterns and an optional framePattern; see log-formats.json. Optional exportFormat sets the default template for exportLogs when the tool call omits format. The connection file may set exportRoots to restrict export destinations, and per connection limits. Authentication and tenant headers are configured per connection; URLs and credentials never appear in tool responses or diagnostics. The full format is in docs/connections.md.
The server loads configuration strictly at startup without probing Loki. An unknown field, duplicate key, missing environment variable or invalid format file stops startup with a safe configuration error. Changes require a restart.
Call listConnections, choose a stand and use its displayed time windows, queryLogs line cap and request timeout to plan calls.
Call discoverLogs(connection="dev") for label names, then discoverLogs(connection="dev", label="app") for values. When combinations matter, use discoverLogs(connection="dev", match="{app="backend"}") for full stream label sets or add label="namespace" for namespace values among those sets. Keep match and its window narrow; these are stream labels, not log-line counts. Widen the window on a quiet stand when appropriate.
Use a LogQL log query with countLogs to check volume and queryLogs to read lines. For example, {app="backend"} |= "ERROR"; groupBy="time", step="1d" gives UTC-aligned 24-hour buckets, and groupBy="app,time" gives counts by app and time. A named | regexp capture can supply a groupBy label. Date markers distinguish buckets across midnight.
Narrow the query when a page is crowded. queryLogs defaults to the newest page; order="oldest" starts at the beginning of the window. Its footer gives an end for older lines or a start for newer ones. Boundary lines can repeat, and a timestamp containing more lines than a page needs a narrower query.
Call exportLogs when the user asks for a file. Pass the user's destination as directory, such as C:\tmp\logs, or omit it for the default export directory. Omitting format uses the connection's configured exportFormat template, if the operator set one, and raw otherwise. format="raw" writes the lines returned by Loki, including any | line_format transformation in the query; format="{time} {level} {service} {message}" renders locally. The response gives the path, counts and effective format, not the log contents.
queryLogs prints either end of the window in chronological order. Its default view shortens messages and stack traces to save model tokens. An optional framePattern in the connection's formatFile folds adjacent standalone frame lines in the compact view. raw=true shows every returned line with stream labels and up to 4000 code points; it is a preview. For complete lines use exportLogs. Export reads forward in pages and never overwrites an existing file. If more lines share one nanosecond than Loki will return in one page, export reports that some may be missing.
The default time window is now-1h to now. Accepted times include now-15m, RFC3339 with an offset, local time in the connection's timezone and epoch nanoseconds. queryLogs and exportLogs allow one day by default. countLogs allows one day for totals, label grouping or combined label/time grouping, and seven days for time-only buckets; discoverLogs allows seven days without match and one day with match. A Loki request has a 30-second timeout by default, and queryLogs allows at most 1000 lines per page by default. listConnections shows the effective values for each stand. Export stops after 25 seconds by default and reports a partial file with a continuation if it has written lines. After a count timeout, retry a one-day subwindow or narrower query. Limits can be set per connection; see docs/queries.md and docs/discovery.md.
Claude Code:
claude mcp add --scope user loki -e LOKI_MCP_CONNECTIONS_FILE=C:/path/connections.json -- java -jar C:/path/loki-mcp-server.jarCodex (~/.codex/config.toml):
[mcp_servers.loki]
command = "java"
args = ["-jar", "C:/path/loki-mcp-server.jar"]
env = { LOKI_MCP_CONNECTIONS_FILE = "C:/path/connections.json" }Other clients can launch the jar over stdio. Keep stderr separate from stdout.
Tool failures are text Error : with isError=true; Spring AI currently repeats the text on a second line. Missing or mistyped arguments are answered by the MCP SDK input validation. A Loki HTTP 400 LogQL parse error is returned so the model can correct its query. Other upstream response bodies, URLs, credentials, tenant and full log lines are kept out of responses and diagnostics. A 404 applies to the called endpoint, not the entire connection. Transport details are in docs/http-client.md.
The server log records connection names and auth type at startup, then one bounded line per tool call and Loki request with status, bytes and time. Log contents remain data, including text resembling instructions.
.\gradlew.bat build
.\gradlew.bat integrationTest --console=plain
python scripts/live_smoke/run_smoke.py --connection devbuild runs unit tests and a separate process stdio smoke against loopback mock Loki. integrationTest needs Docker and pinned Loki 2.6.1/3.6.0 images; it writes test data only to its containers. The live smoke uses the example profile and a configured read only stand URL. Contributor rules are in AGENTS.md; design history and open items are in docs/decisions.md. Users moving from mcp-loki can read the migration guide.
Apache License 2.0; see LICENSE. Third-party notices are in THIRD-PARTY-NOTICES.md.
Count log lines matching a LogQL log query without returning those lines. Example: query={app="backend"} |= "ERROR", groupBy="time". Omit groupBy for one total, use a label for values, time for buckets, or app,time for both; step="1d" sets the bucket width. For a multi-day label count, query one-day windows separately; only time-only buckets allow seven days by default. A named LogQL regexp capture can supply a groupBy label; inspect matching lines with queryLogs.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Window end, default now. Use the end in a queryLogs footer to read older lines. | |
| step | No | Bucket width for time grouping, 1s through 1d; default automatic | |
| query | Yes | LogQL log query, e.g. {app="backend"} |= "ERROR". Take label names and values from discoverLogs. | |
| start | No | Window start, default now-1h. Examples: now-15m, now-2d, 2026-09-13T10:00:00+03:00. | |
| groupBy | No | Label name, time, or <label>,time | |
| connection | Yes | Connection name from listConnections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds non-obvious behavior: lines are not returned, only time-only buckets permit seven days by default, multi-day label counts need separate one-day queries, and a named regexp capture can supply a groupBy label. It stops short of noting limits like max series or result caps.
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?
Front-loaded with the core purpose and an example before the parameter guidance, and every sentence carries information. It is slightly dense and run-on in the middle (the semicolon-chained groupBy rules), which costs a point on readability.
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?
With no output schema, the description compensates by describing what the result is (one total, label values, or time buckets) and the windowing constraints that affect correctness. The remaining gap is return format details such as ordering or series limits, but an agent has enough to invoke it correctly.
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 coverage is 100%, so the baseline is 3, but the description genuinely extends it — the groupBy value grammar (label vs time vs <label>,time), the effect of step on bucket width, and the default window behavior are explained in prose beyond the terse schema text. Still, it doesn't clarify the exact accepted time/label format combinations beyond examples.
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?
States a specific verb+resource: counting log lines matching a LogQL query. It explicitly distinguishes from the sibling that returns lines ('without returning those lines') and later routes to queryLogs, so an agent can tell countLogs apart from queryLogs/exportLogs without opening a schema.
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?
Gives concrete when-to-use guidance ('Omit groupBy for one total, use a label for values, time for buckets, or app,time for both') and an explicit alternative with its condition ('inspect matching lines with queryLogs'). It also flags when this tool does not work well (multi-day label counts must be split into one-day windows).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover labels before writing LogQL. Without label or match, list label names; label="app" lists its values. match="{app=\"api\"}" lists complete stream label sets; add label="namespace" to list namespace values among those sets. Use a narrow match and time window, then countLogs or queryLogs to check log lines.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Window end, default now. Use the end in a queryLogs footer to read older lines. | |
| label | No | Optional label name, e.g. "app": list its values | |
| match | No | Optional LogQL stream selector, e.g. {app="api"}; no line filters | |
| start | No | Window start, default now-1h. Examples: now-15m, now-2d, 2026-09-13T10:00:00+03:00. | |
| connection | Yes | Connection name from listConnections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: output depends on inputs (no args = label names, label only = its values, match = full stream label sets), which is not derivable from annotations alone.
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?
Three dense sentences, each carrying distinct information: purpose, the three input-dependent behaviors, and the recommended workflow. The purpose is front-loaded and there is no filler.
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?
There is no output schema, and the description compensates by describing the three possible return shapes based on inputs, plus time-window guidance. For a 5-parameter read-only discovery tool, an agent has everything needed to call it and interpret the result.
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 description coverage is 100%, so the baseline is 3. The description goes further by explaining the combined semantics of label and match (e.g. 'add label="namespace" to list namespace values among those sets') and the window-scoping intent, which the parameter descriptions only partially convey.
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?
States a specific verb and resource ('Discover labels') and immediately scopes it to the LogQL workflow, which clearly separates it from countLogs and queryLogs. An agent can tell this is a metadata/label exploration tool rather than a log-reading tool without opening any schema.
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 says to run this 'before writing LogQL', recommends a narrow match and time window, and routes the agent onward ('then countLogs or queryLogs to check log lines'). It names the sibling tools and the condition for using each, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save matching log lines of a window to a local file, oldest first, when the user asks to save logs. Pass the same LogQL query as queryLogs, e.g. {app="backend"} |= "ERROR". Omit format to use the connection's default export format, which is raw unless the operator set a template; format="raw" keeps the lines returned by Loki, including any LogQL line_format stage; a template like "{time} {level:5} [{thread}] {logger} : {message}{stack}" rewrites them locally. Pass a user-specified directory directly; omit it for the default export directory. The answer gives the file path, the line count, and a start value to continue with when a limit stopped it.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Window end. Default "now". Same formats as start. | |
| query | Yes | LogQL log query, e.g. {app="backend"} |= "ERROR". Take label names and values from discoverLogs. | |
| start | No | Window start, default now-1h. Examples: now-15m, now-2d, 2026-09-13T10:00:00+03:00. | |
| format | No | Omit it for the connection's default export format (raw unless configured). "raw" forces the lines returned by Loki; a template with {time}, {level}, {service}, {logger}, {message}, {stack} and line fields like {thread} renders locally. | |
| directory | No | Local directory for the new file, e.g. C:\tmp\logs or incident-42. Omit it for the default export directory; a relative path is resolved under that directory. Configured exportRoots, if present, restrict destinations. | |
| connection | Yes | Connection name from listConnections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark this as a non-readonly, non-idempotent, open-world write, so the description carries most of the burden and does well: it discloses the output artifact (file path, line count, start value), the default-format behavior, and that exportRoots restrict destinations. It does not say whether an existing file is overwritten or how the file is named, which is a residual gap.
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?
Front-loads the purpose and proceeds efficiently through query, format, directory, and return value with no filler. It is dense and slightly long, but each sentence contributes distinct information; only the format explanation runs a bit long.
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?
Covers the full calling contract despite having no output schema: it describes the return payload (path, line count, continuation start), the default behaviors for format and directory, and the security constraint (exportRoots). Nothing essential to calling it correctly is missing.
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 coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: the format default ('raw unless the operator set a template'), the semantics of raw vs template rewriting, and how a relative directory resolves under the export directory. Parameter interpretation is materially improved.
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?
Opens with a specific verb and resource ('Save matching log lines of a window to a local file') and adds the ordering guarantee ('oldest first'). It explicitly references the sibling queryLogs, so an agent can distinguish exporting from querying without opening either schema.
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?
Gives the explicit trigger ('when the user asks to save logs') and routes the agent to the correct query source by naming queryLogs ('Pass the same LogQL query as queryLogs'). It also names the continuation condition (limit stopped the export), which is actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured Loki stands with each name, description, operator hint and effective tool limits. Call this first, use the shown windows and page limit, and pass the chosen name as 'connection' to every other tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral value by framing the tool as a bootstrap/discovery step that governs how other tools are invoked, though it does not discuss caching or refresh behavior.
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 dense sentence: the action and return shape come first, followed by the workflow instruction. No filler, and the sequencing guidance is front-loaded with 'Call this first'.
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?
There is no output schema, but the description enumerates the returned fields and explains how the result feeds downstream calls. For a zero-parameter discovery tool with full annotation coverage, nothing an agent needs to invoke it correctly is missing.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. The description correctly implies no arguments are needed before the discovery call.
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?
States a specific verb (List) plus resource (configured Loki stands) and even enumerates the returned fields (name, description, operator hint, effective tool limits). This is clearly distinguishable from siblings like queryLogs/countLogs/exportLogs, which operate on log data rather than connection configuration.
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 says 'Call this first', explains how to consume the output (use the shown windows and page limit), and instructs the agent to pass the chosen name as 'connection' to every other tool. This is a complete when/when-not/alternatives directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a bounded page of log lines matching a LogQL query in a window. The response is chronological, with a compact level, service and message view. Example: {app="backend"} |= "ERROR". Use raw=true to preview the line returned by Loki with its stream labels; long lines are shortened. Use order="oldest" to read forward, repeat with the start or end value in the footer, and use exportLogs for complete files.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Window end, default now. Use the end in a queryLogs footer to read older lines. | |
| raw | No | Preview the line returned by Loki with stream labels, default false | |
| limit | No | Maximum lines to show, default 50 | |
| order | No | newest (default) or oldest; oldest reads forward | |
| query | Yes | LogQL log query, e.g. {app="backend"} |= "ERROR". Take label names and values from discoverLogs. | |
| start | No | Window start, default now-1h. Examples: now-15m, now-2d, 2026-09-13T10:00:00+03:00. | |
| connection | Yes | Connection name from listConnections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: response is chronological, uses a compact level/service/message view, and long lines are shortened. It stops short of describing pagination limits or line-count defaults.
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?
Three tight sentences, front-loaded with the core purpose before the example and the usage tips. Every clause carries actionable information with no filler.
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?
No output schema exists, yet the description compensates by describing the return shape (chronological, compact level/service/message view) and how to continue paging. Combined with the fully documented schema, an agent has everything needed to call it correctly.
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 coverage is 100%, so the baseline is 3, but the description adds semantic value: it explains raw's preview purpose and the pagination idiom of reusing footer start/end values, plus the forward-reading meaning of order="oldest". That goes beyond the schema's terse parameter descriptions.
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?
States a specific verb and resource ('Read a bounded page of log lines matching a LogQL query in a window') and immediately contrasts itself with exportLogs for complete files. An agent can distinguish it from countLogs, discoverLogs, and exportLogs without opening any schema.
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?
Gives explicit branch conditions: raw=true to preview raw Loki lines, order="oldest" to read forward with start/end footer values for continuation, and exportLogs when complete files are needed. This is a genuine when/when-not/alternative routing.
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.0countLogsdiscoverLogsexportLogslistConnectionsqueryLogsScored across 5 tools
Each tool targets a distinct phase of the Loki log workflow: connection listing, label discovery, log querying, counting, and file export. No two tools overlap in purpose, and the descriptions make the boundaries between queryLogs, countLogs, and exportLogs explicit.
All tool names follow a consistent camelCase verb+noun pattern (listConnections, discoverLogs, exportLogs, countLogs, queryLogs). There are no deviations in style or verb form.
Five tools is well-scoped for a Loki log access server, covering the essential read and export operations without redundancy. Each tool earns its place and the set avoids both bloat and sparseness.
The set covers core log retrieval, counting, discovery, and export, but lacks support for arbitrary LogQL metric queries (e.g., rates) and live tailing. These are minor gaps that most log-querying workflows can work around, so coverage is strong but not exhaustive.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
