Linux MCP Server

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

With no annotations provided, the description carries full burden and does well: it discloses the whitelist constraint (critical security/access behavior), explains remote vs. local execution (SSH behavior), and specifies default values. However, it doesn't mention error handling, rate limits, or output format details, leaving some behavioral gaps.

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?

Perfectly structured: one sentence states purpose and constraint, followed by a clear Args section with bullet-like explanations. Every sentence earns its place—no fluff, front-loaded with key info. The formatting enhances readability without wasting space.

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 4 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is nearly complete. It covers purpose, constraints, and all parameters meaningfully. The output schema handles return values, so no need to explain those. Minor gaps include lack of error cases or example paths, but overall sufficient for agent use.

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 fully. It successfully explains all 4 parameters: 'log_path' (path to file), 'lines' (number from end with default), 'host' (remote SSH target, optional), and 'username' (required if host given). It adds crucial context like default values and conditional requirements, though it doesn't specify path format or line range limits.

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 specific action ('Read a specific log file') and resource ('log file'), distinguishing it from siblings like 'get_audit_logs' or 'get_service_logs' by specifying it reads arbitrary log files (with whitelist constraints). The verb 'Read' is precise and the scope is well-defined.

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 explicit guidance on when to use this tool: for reading log files (vs. other tools that fetch system info, processes, or services). It implicitly distinguishes from siblings by focusing on file-based logs rather than system logs or audit logs, though it doesn't name alternatives directly. The whitelist constraint ('whitelist-controlled via LINUX_MCP_ALLOWED_LOG_PATHS') sets clear boundaries.

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