Get logs from a pod in a Kubernetes cluster. This tool retrieves logs from a specified pod in an EKS cluster, with options to filter by container, time range, and size. It's useful for debugging application issues, monitoring behavior, investigating crashes, and verifying startup configuration. ...
Part of the Amazon EKS MCP Server MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.
AI agents call get_pod_logs to retrieve information from Amazon EKS MCP Server without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though get_pod_logs only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
tools:
get_pod_logs:
rules:
- action: allowSee the full Amazon EKS MCP Server policy for all 16 tools.
Agents calling read-class tools like get_pod_logs have been implicated in these attack patterns. Read the full case and prevention policy for each:
Other tools in the Read risk category across the catalogue. The same policy patterns (rate-limit, allow) apply to each.
Get logs from a pod in a Kubernetes cluster. This tool retrieves logs from a specified pod in an EKS cluster, with options to filter by container, time range, and size. It's useful for debugging application issues, monitoring behavior, investigating crashes, and verifying startup configuration. IMPORTANT: Use this tool instead of 'kubectl logs' commands. ## Requirements - The server must be run with the `--allow-sensitive-data-access` flag - The pod must exist and be accessible in the specified namespace - The EKS cluster must exist and be accessible ## Response Information The response includes pod name, namespace, container name (if specified), and log lines as an array of strings. Args: ctx: MCP context cluster_name: Name of the EKS cluster namespace: Namespace of the pod pod_name: Name of the pod container_name: Container name (optional, if pod contains more than one container) since_seconds: Only return logs newer than this many seconds (optional) tail_lines: Number of lines to return from the end of the logs (defaults to 100) limit_bytes: Maximum number of bytes to return (defaults to 10KB) previous: Return previous terminated container logs (defaults to false) Returns: PodLogsResponse with pod logs. It is categorised as a Read tool in the Amazon EKS MCP Server MCP Server, which means it retrieves data without modifying state.
Add a rule in your Intercept YAML policy under the tools section for get_pod_logs. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the Amazon EKS MCP Server MCP server.
get_pod_logs is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the get_pod_logs rule in your Intercept policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the Intercept policy for get_pod_logs. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
get_pod_logs is provided by the Amazon EKS MCP Server MCP server (awslabs.eks-mcp-server). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic policy on every MCP tool call. Per-identity grants. Full audit log.