Cycle MCP

Search Container Logs

get_logs

Read-onlyIdempotent

Search aggregated logs from Cycle containers. First stop for crash loops, application errors, and confirming "out of memory" / "no space left" style failures. Use after diagnose points at a specific container or instance, or directly when the user names one.

Scope with environment for environment-wide logs, add container to narrow, add instance to narrow further — the most specific reference wins. Search is optional; without it the newest lines in the range are returned. Use search_type "regexp" with RE2 syntax for patterns like "(?i)error|panic". context_window returns surrounding lines after each match (lines sharing a context_window ID belong to the same match).

Defaults to the last hour. If nothing comes back, widen the range or loosen the search — a container that just started may also not have shipped logs yet. Read-only.

To wait for a line to APPEAR (readiness/migration-done markers like "database system is ready"), pass search plus wait_seconds: the call polls until the first match or the budget elapses, instead of you sleeping between calls. A no-match result after the wait is not failure — repeat the same call to keep waiting.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum log lines to return, 1-500.
`search`	No	Text or pattern to match log messages against. Omit to return the newest lines in the range.
`compact`	No	Reduce structured JSON lines (ECS, logrus, zap...) to level, message, and error fields, dropping envelope fields. Non-JSON lines pass through unchanged. Use for chatty JSON loggers such as Elasticsearch.
`context`	No	Why are you calling this tool? Briefly describe the user's goal.
`instance`	No	Instance id or hostname. Narrowest scope; requires container.
`container`	No	Container to pull logs from. Narrows the scope to one container.
`range_end`	No	RFC3339 end of the log window. Defaults to now.
`environment`	No	Environment to pull logs from. Broadest scope.
`range_start`	No	RFC3339 start of the log window. Defaults to one hour before range_end.
`search_type`	No	raw = exact substring match (default). regexp = RE2 pattern, e.g. (?i)error\|panic.
`wait_seconds`	No	Max seconds to block waiting for the first matching line, polling every few seconds (0 = return immediately). Requires search; not combinable with range_end. Values above 60 are clamped — longer blocking calls are unreliable through connectors; repeat the call to keep waiting.
`context_window`	No	Lines of surrounding context to include after each match, 0-10.
`conversation_id`	No	Conversation tracking id. Omit on your first tool call; every result then includes a conversation_id line — pass that exact value on all later calls in this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: default one-hour window, the 'most specific reference wins' scope precedence, wait_seconds polling semantics with a 60s clamp and the explicit note that a no-match after waiting is not failure, and the context_window grouping behavior. These are exactly the traits an agent needs and none are in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and usage, then scope, defaults, failure handling, and the wait pattern in a logical order. Dense and information-rich, but four paragraphs covering a 13-parameter tool is at the upper edge of comfortable length; nothing is truly wasted.

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

Completeness5/5

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

Covers purpose, routing, scope rules, defaults, edge cases (empty results, unshipped logs), and the blocking-wait workflow for a 13-parameter tool with no output schema. An agent has everything needed to call it correctly on the first try.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still adds real semantics beyond the schema: scope precedence across environment/container/instance, search being optional, RE2 syntax for search_type, and the meaning of shared context_window IDs. Slightly above baseline because it disambiguates how parameters interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search aggregated logs from Cycle containers') and immediately scopes it against siblings by naming the scenarios (crash loops, OOM, disk-full). An agent can distinguish it from get_telemetry, query_metrics, and get_jobs 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.

Usage Guidelines5/5

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

Gives explicit routing: 'First stop for crash loops...', 'Use after diagnose points at a specific container or instance, or directly when the user names one,' plus a fallback ('If nothing comes back, widen the range or loosen the search'). It names the sibling (diagnose) and the condition that selects this tool.

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

All Cycle MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?