infomaniak_nodejs_app_logs

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

The description discloses key behavioral traits beyond the annotations: the JWT is one-shot and valid ~1h, the endpoint hostname is fixed, the stream uses SSE, and the tool is 'Manager-private.' Since annotations already mark readOnly and non-destructive, the added context about credential lifecycle and streaming behavior is valuable. No contradictions with annotations.

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 well-structured: it leads with the primary purpose, then details the return value, transport mechanism, usage example, and a practical tip. Each sentence adds meaningful information without redundancy or fluff.

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?

The description covers the tool's main purpose, output, and consumption method, which is sufficient for a credential-fetching tool. An output schema exists to formalize return values, and annotations cover safety. The only gap is lack of parameter detail, but that is a separate dimension. Overall, the context is complete for the tool's complexity.

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 0% and the description does not explain the meaning or role of hosting_id or vhost_route_id. It only mentions 'of a Node.js application' generically, which fails to map the parameters to those identifiers. With no schema descriptions and no param explanations, the agent must infer their purpose from context, which is insufficient.

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 function: 'Get credentials to consume the LIVE stdout/stderr stream of a Node.js application.' This specifies a unique verb-resource combination (get credentials for logs) and distinguishes it from sibling tools like status, aliases, and jobs. The mention of the returned JWT and endpoint URL further clarifies the purpose.

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 clear usage context by explaining how to consume the stream (curl with Authorization header) and how to fetch a snapshot (kill curl after a few lines). It implies when to use this tool (for live logs) without explicitly contrasting with alternatives or stating exclusions, which is acceptable given the tool's distinct name.

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