Get Memory Info

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

With no annotations, the description carries the full disclosure burden, and it does at least pin down that the payload is read-only metric data broken into specific counters. It does not state units, whether values are bytes, or whether swap is a nested section, leaving gaps for a mutation-free getter whose main risk is misinterpretation of returned numbers.

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?

A single front-loaded sentence with the resource first and the returned fields in parentheses — no filler, nothing to trim.

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?

An output schema exists, so the description is not obliged to document return values, and with zero parameters the calling surface is trivial. For such a simple tool this is nearly sufficient; only the missing disambiguation from overlapping system/hardware info siblings keeps it from a 5.

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?

The schema is empty with additionalProperties false, so there are no parameters to explain; the baseline for a zero-parameter tool applies. The description correctly adds no parameter noise.

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?

Names a specific resource (memory and swap) and enumerates the exact figures returned (total/available/used/cached/buffers), which clearly separates it from siblings like get_cpu_usage or get_disk_usage. It never explicitly distinguishes itself from get_system_info or get_hardware_info, which could plausibly also report memory, so it stops short of a 5.

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 says nothing about when to call this versus get_system_info, get_hardware_info, or get_cpu_usage. There is no context, prerequisite, or exclusion — an agent must infer the choice entirely from sibling names.

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