get_logsReturn recent container log lines. tail = line count (plan default 200; plan max 2000), since = time window in seconds (plan window: free 24 h, plus 7 d — logs are live-pod streams, not stored history). When both are given, since wins.
| Name | Required | Description | Default |
|---|---|---|---|
| tail | No | ||
| since | No | ||
| project | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the readOnlyHint annotation: it explains that logs are live-pod streams rather than stored history, and that when both tail and since are provided, since takes precedence. This is useful for an agent to predict the tool's behavior. It doesn't contradict the annotation.
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 concise and front-loaded. The first sentence states the core purpose, and the rest adds essential parameter semantics and behavioral notes. Every sentence earns its place, and the precedence rule is clearly stated.
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 tool's simplicity (3 optional params, no output schema), the description is quite complete. It explains the key parameters, the log retention model, and the precedence rule. The only minor gap is the project parameter, which is not described, but the overall context is sufficient for an agent to call the tool 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 description coverage is 0%, so the description must compensate. It does: it explains the meaning of tail (line count) and since (time window in seconds), and even provides plan-specific limits (default 200, max 2000, free 24h, plus 7d). The project parameter is not explained, but the description covers the two most important parameters well.
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's purpose: returning recent container log lines. It specifies the resource (container logs) and the action (return), and the parameter semantics for tail and since distinguish it from other tools. It is not a tautology and provides concrete detail about what the tool does.
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 explains when to use the tool (to get recent logs) and provides context about the log retention model (live-pod streams, not stored history), which helps an agent understand the tool's limitations. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.