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

Beyond the readOnlyHint and idempotentHint annotations, the description reveals concrete behaviors: it runs specific commands (`codesign -dv --verbose=4`, `codesign --verify --deep --strict`, `spctl --assess --verbose=4`), returns a structured dict, and handles missing paths by embedding error text in fields rather than throwing an exception. This is rich, annotational over-delivery.

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 well-structured with a one-line summary, an explicit use-case, a safety note, and clearly separated Args/Returns sections. Every sentence contributes value, and the markdown formatting enhances readability without being padded.

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 tool is contextually complete: it covers purpose, usage, parameter semantics, return structure, behavior (including error handling), and safety. Despite having an output schema, the description redundantly documents the return keys, which is helpful and makes the tool self-contained.

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 100%, so the baseline is 3. The description's 'Args' section repeats the path parameter but adds no new semantic meaning beyond what the schema already provides (absolute path, .app or Mach-O, examples).

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 opens with a specific verb and resource: 'Inspect the code signature, signature validity, and Gatekeeper assessment of a bundle or binary on this Mac.' It also states the concrete question it answers ('is this app properly signed and notarized, and by whom?'), which clearly distinguishes it from the sibling signalgrid_* tools.

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 explicitly says 'Use to answer...' which gives a clear when-to-use context. It also notes 'Reads only; never executes the target,' implying safe read-only usage. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying exact return keys and the error behavior when system_profiler fails, which is behavioral context beyond what the annotations provide.

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 structured with a short title line, a sentence about usage context, and a clear return specification. It is concise and every sentence contributes either to purpose, usage, or return behavior, though the 'Returns' section duplicates what an output schema would typically provide.

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?

For a no-parameter tool with an output schema and rich annotations, the description covers the tool's purpose, the semantic meaning of the identity, and error handling. It does not address explicit alternatives, but that's a usage guideline matter, and overall this is sufficient for a simple read-only tool.

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 tool has zero parameters, so the baseline is 4. The description correctly omits parameter details, and the schema has 100% coverage with no parameters to document.

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 identifies the tool's function: providing hardware identity details (serial number, model, hardware UUID, chip, activation lock). The phrase 'stable anchor for a device trust record' adds context and distinguishes it from sibling system-info tools, though it lacks an explicit action verb like 'get' or 'list'.

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 implies usage context by positioning the data as a stable anchor across OS reinstalls, but it does not explicitly state when to use this tool over alternative siblings, nor does it mention any exclusions or alternatives. It provides a rationale for why to use it but no explicit comparison.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: potential ~30s latency on first call, the fact that system_profiler is the data source, and the error return format ('Error: ...' if system_profiler failed). This goes beyond safety traits to performance and failure behavior.

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 well-structured with clear sections for purpose, usage, args, and returns. It's fairly dense but every sentence contributes meaning, such as the latency warning and the sideloaded-app signal. Slightly verbose but not wasteful.

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 is thorough: it covers when to use, what it returns, how to interpret results, error conditions, performance characteristics, and relationship to sibling tools. Combined with full schema coverage and annotations, this is nearly complete for a list-style inventory tool.

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 100%, so baseline is 3. The description adds marginal context for limit/offset by noting 'inventories often have hundreds of entries', which justifies pagination. However, for name_contains and unsigned_only, the description largely restates what the schema already says.

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 as an inventory of installed applications with version, source, and signer. It distinguishes itself from sibling tools by explicitly mentioning software-inventory questions and contrasting with signalgrid_codesign_inspect for deep one-app verdicts.

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 usage guidance: use for software-inventory questions and to shortlist risky installs, with a concrete signal (obtained_from='Unknown' plus no signer). It also recommends signalgrid_codesign_inspect for deep verdicts, offering a clear alternative.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), and the description adds valuable behavioral context: pagination defaults, response envelope structure (total, count, offset, items, has_more, next_offset), and error handling for system_profiler failures. It also clarifies that results are ordered newest first.

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 well-structured: a concise purpose statement, a practical use-case sentence, then an Args/Returns breakdown. It includes all necessary details without redundancy, making it easy to scan and understand.

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 tool has moderate complexity (4 optional params, no output schema provided), but the description fully covers input filtering, pagination, response formats, and error behavior. It even specifies the exact structure of the JSON response, so an agent knows what to expect. Combined with the annotations, this is a complete package.

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 100%, so the parameters are already well-documented. The description adds meaning by explaining the JSON envelope fields and item attributes (name, version, source, install_date), which are not present in the schema. It also ties name_contains to the XProtect use case, providing extra context beyond the schema's description.

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 provides 'Software install history (OS updates, security content, packages), newest first' and frames it as 'the audit trail of what changed on this Mac and when.' This specific verb-resource pairing distinguishes it from siblings like signalgrid_installed_apps or signalgrid_software_updates.

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?

It gives explicit use cases: 'Use to verify security updates actually landed (e.g. filter name_contains='XProtect') or to spot unexpected installs.' This provides clear context for when to use the tool, but it doesn't explicitly mention when not to use it or name alternative sibling tools, so it stops short of a 5.

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

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

Beyond the read-only/idempotent annotations, the description discloses fallback behavior (tries kmutil, falls back to kextstat) and defines the exact return structure including error cases. This adds meaningful transparency about how the tool behaves in practice.

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: a clear first sentence, relevant security context, fallback detail, and a formatted Returns section. Every sentence serves a distinct purpose without unnecessary 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?

Given the tool's simplicity (no parameters) and the presence of an output schema, the description fully covers the behavior, return format, and error handling. It provides all necessary context for an agent to invoke the tool and interpret results confidently.

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 tool has zero parameters, so the description cannot add parameter-level meaning. The baseline for 0 params is 4; the description appropriately focuses on the output contract instead, even though it's not explicitly about parameters.

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: retrieving loaded kernel extensions and singling out third-party kexts. It uses a specific verb ('Loaded') and resource ('kernel extensions'), and the emphasis on third-party kexts distinguishes it from siblings like signalgrid_system_extensions.

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 strong context for when this tool is relevant: checking for third-party kexts as a trust signal in macOS security assessments. It does not explicitly name alternatives or state when not to use it, but the context is clear and actionable.

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

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

Annotations already declare read-only and idempotent behavior. The description adds value by explaining that Apple's sealed /System items are excluded, that items run at boot/login, and that a recently-modified oddly-named plist is suspicious. 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 compact, front-loaded with the core purpose, and organized with a brief context explanation followed by parameter and return details. Every sentence contributes useful context without rambling.

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?

For a list tool with no explicit output schema, the description covers the return format (markdown or JSON), item fields (label, scope, path, modified), scope enum values, and filter semantics. Combined with annotations, this gives the agent enough to understand behavior and output.

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 100% and each parameter is well-described in the schema. The description largely restates the same parameter details (e.g., name_contains as substring filter, pagination defaults) without adding significant new meaning.

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 it lists third-party launchd plists in standard persistence directories, excluding Apple's sealed items. It distinguishes this from sibling tools by focusing on launchd persistence and malware signals.

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 gives strong contextual guidance (standard persistence, malware signal) but does not explicitly mention when to avoid using it or name alternative tools. This falls short of a 5 but is clear enough for typical use.

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

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

Beyond the annotations (read-only, idempotent), the description reveals that lsof may miss system daemons without elevation and that errors return 'Error: ...' strings. This gives the agent important context about false negatives and failure modes.

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 compact, front-loaded with the main verb, and contains only relevant details. Each sentence adds information—purpose, caveat, parameter summary, and return format—without redundancy.

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?

For a read-only info tool with 4 parameters and an output schema, the description covers the tool's scope, limitations, parameter behavior, and return envelope. It is complete enough for an agent to select and invoke it 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 coverage is 100%, so the baseline is 3. The description adds value by providing example address formats ('*:22', '127.0.0.1:8021') and clarifying that JSON items include command, pid, user, and address, which enriches the schema's terse descriptions.

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 processes TCP listening ports via lsof, and frames it as a 'live map of this Mac's inbound network exposure.' This specific verb-resource combination distinguishes it from sibling signals like installed_apps or process_snapshot.

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 the tool is useful (inspecting inbound network exposure) and provides a key caveat about elevation and missing system daemons. It doesn't explicitly compare to alternatives, but the context is clear enough that the agent can decide when to use this tool.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the exact return structure including the error case when directory services fail, and the meaning of the include_system flag. This adds behavioral context not present in 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?

Structured with purpose, rationale, args, and returns. Every sentence adds value; no 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?

For a simple read-only tool with one parameter, the description covers purpose, return format, error behavior, and usage context. The output schema is also described inline, making it complete.

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 100% for the single parameter. The description repeats the schema's explanation of include_system but doesn't add new semantic details beyond what the schema already provides, so baseline 3 is appropriate.

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 output: local user accounts, admin-group membership, and current console user. This distinguishes it from sibling tools like signalgrid_installed_apps or signalgrid_os_info, which focus on other device aspects.

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?

Provides a clear use case for device trust: unexpected accounts/admins as a trust signal, and advises cross-checking admin_group against expected owner list. However, it doesn't explicitly contrast with alternatives or state when not to use it, though the sibling tools are clearly different.

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

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

The description adds important behavioral details beyond the annotations: it discloses that profile listing may require elevation but raw output is returned either way, and explains that null booleans mean the state could not be determined. This transparency complements the readOnly and idempotent hints without contradicting them.

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 starts with the primary purpose, adds a brief relevance note, then presents the return format in a clear bullet-like list. Each sentence earns its place with no 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?

Given the output schema is included, the description goes beyond by explaining the semantic meaning of the booleans and the elevation note. It provides enough context for the agent to interpret results and understand the tool's role in trust assessment, making it complete for a read-only inspection tool.

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?

There are no parameters, so the description appropriately does not need to explain parameter semantics. The baseline of 4 applies because with zero parameters, the description cannot add more than the schema, and it already includes the return format which is the main needed semantic.

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 identifies the tool's function: reporting MDM enrollment state (including DEP) and installed configuration profiles. It distinguishes itself from sibling tools by focusing specifically on MDM status, contrasting with other signalgrid tools like installed_apps or network_posture.

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 context by labeling this as a 'key managed-device signal' and explicitly noting that an unenrolled corporate Mac is a trust gap, implying it should be consulted for security assessments. However, it does not explicitly mention alternatives or when not to use this tool, which would earn a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate safety. It adds valuable behavioral context by detailing the exact return structure ('dict with keys: hardware_ports, active_state, dns_nameservers, proxies, vpn_configurations, _note') and indicates the data source (e.g., 'scutil --nwi'). This goes beyond the schema.

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 compact and well-organized: a one-sentence summary, a one-sentence use-case statement, and a structured return block. Every sentence adds value—no fluff. The use of a 'Returns' block is clean and informative.

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 simple no-parameter tool, the description is complete: it states what the tool does, when to use it, and what it returns. The output schema is present but the description still explains the meaning of the return values (_note, active_state from 'scutil --nwi'). It fully stands alone for an agent to select and use 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?

The tool has zero parameters, so the baseline is 4. The description focuses on the output content rather than parameters, but since there are no params to explain, no additional parameter semantics are needed. It does describe the return structure clearly, which is relevant for output interpretation.

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 it provides a 'Network configuration snapshot' and enumerates specific contents (hardware ports, active interface state, DNS nameservers, proxy settings, VPNs). This is a specific verb+resource that distinguishes it from sibling tools like 'signalgrid_security_posture' or 'signalgrid_trust_verdict' by focusing on network configuration.

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?

It gives explicit when-to-use guidance: 'Use to spot rogue DNS, unexpected proxies, or missing corporate VPN -- all classic device-trust red flags.' It does not mention alternatives or explicit when-not-to-use, but the use case is clear and distinct from other device-trust tools like 'signalgrid_security_posture' or 'signalgrid_trust_verdict'.

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

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

Annotations already declare the tool as read-only and idempotent. The description adds valuable details beyond those annotations: it returns a structured dict and that individual values read 'unavailable'/error text when a probe fails, which is important for handling failures gracefully.

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 three short paragraphs, front-loaded with the core information (what data is returned), followed by a concise use case and return/failure semantics. Every sentence adds value with no waste.

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?

For a zero-parameter read-only tool with an output schema, the description covers all necessary context: the exact output keys, failure behavior, and a primary use case. It is sufficiently complete for an agent to invoke and interpret results 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?

There are zero parameters, so the baseline is 4. The schema is empty, and the description does not need to explain parameters. It adds no parameter-specific meaning, but with no parameters, no further clarification is needed.

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 provides macOS product/build version, kernel, hostnames, uptime, and current users. It lists the exact dictionary keys, making the scope unambiguous and distinguishing it from siblings like signalgrid_software_updates or signalgrid_device_identity.

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 gives explicit use cases: establishing OS patch level and determining the console user. It does not mention alternatives or when not to use it, but the context is clear and specific enough for an agent to select it appropriately.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds valuable behavioral context: failed sections return an error dict without sinking the whole snapshot, the verdict is a derived summary (absent unless requested), and include_verdict auto-collects required sections. No contradiction 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 well-structured with a strong opening summary, usage guidance, and an Args/Returns section. It is a bit longer than strictly necessary, but every part serves a purpose—no filler or repetition of annotations.

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 moderate complexity (two optional params, many section choices), the description fully explains return shapes, error behavior, and verdict derivation. Combined with rich schema and annotations, the agent has all needed context to invoke 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 already covers both parameters at 100%. The description adds meaning by explaining the fail-safe verdict semantics and the 'unknown is never allow' policy, which is beyond the schema's field descriptions. Slightly redundant Args block but still adds context.

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 what the tool does: it returns a full device trust snapshot combining identity, OS, security, MDM, and patch state in one call. It distinguishes itself from siblings by positioning as the 'use this first' aggregate tool, with focused tools as follow-ups.

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?

Explicitly advises 'Use this first' and explains the advantage of a single call versus six. It also directs users to drill into focused tools afterward and describes when to set include_verdict, giving clear contextual guidance for tool selection.

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

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

While annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description adds valuable behavioral context: includes full executable paths, returns either a markdown table or JSON envelope, and outputs 'Error: ...' if ps fails. This goes beyond the annotations and helps set expectations.

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 front-loaded with a purpose summary, followed by usage guidance and an Args block. Every sentence earns its place; there is no redundancies or fluff. It is long enough to be useful but tightly structured.

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?

For a read-only, non-destructive tool with full schema coverage and an output schema (Has output schema: true), the description covers purpose, usage, behavior, and return format. It even handles error cases and suggests integration with a sibling tool. The description is complete for an agent to select and invoke it 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 100%, and each parameter already has a clear description (e.g., name_contains is a 'Case-insensitive substring filter'). The tool description repeats the parameter meanings but adds no new semantic depth beyond the schema. Baseline 3 is appropriate given the schema's completeness.

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 begins with 'Point-in-time snapshot of running processes' and lists the exact fields (pid, parent, user, %CPU, %MEM, command path). This specific verb+resource clearly distinguishes it from sibling tools like signalgrid_installed_apps or signalgrid_listening_services.

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?

Explicit usage guidance is provided: 'Use to confirm an agent/daemon is actually running' and 'spot suspicious processes.' It even suggests pairing with signalgrid_codesign_inspect for suspicious paths, giving a clear when-to-use and complementary alternative.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds value by stating 'needs no elevation', explaining that 'available: false' means the USB tree could not be read (never 'nothing connected'), and emphasizing that SignalGrid does not block the device. These nuances go beyond annotation defaults.

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 well-structured and concise: a one-sentence purpose, key behavioral flags, and a return format. Every sentence contributes value, using code formatting for clarity without redundancy.

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 no output schema, the description includes a detailed return dictionary, covering edge cases like available: false and mass_storage_connected: true. It lacks nothing critical for a simple read-only listing tool; pagination and filters are self-explanatory from the schema.

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 75% with all parameters (limit, offset, name_contains, response_format) having descriptions. The tool description does not add extra parameter semantics beyond the schema, but it does specify the return shape, which helps compensate. Baseline 3 is appropriate since schema covers most parameter meaning.

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 reports connected USB/removable-media devices with a focus on MASS-STORAGE as a data-egress channel. The verb 'flagging' and the explicit resource (removable media) distinguish it from other signalgrid sibling tools focused on apps, processes, or network posture.

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 gives context for when to use the tool: it is relevant for shared or plant-floor device managers concerned about data egress. It also clarifies that the tool only reports and does not block devices. It does not explicitly contrast with alternatives, but the uniqueness of the resource makes the use case clear.

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

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

Annotations already declare read-only and non-destructive safety, but the description adds significant behavioral context: it composes three facts, uses a fail-safe logic, returns `null` when confirmation is impossible, and explicitly states 'unknown is never graded as locking.' This goes beyond what annotations provide and gives the agent a deep understanding of the tool's behavior.

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 compact and well-structured, front-loading the core purpose and then elaborating on the verdict logic and return fields. It uses several short sentences that each add value, but it is longer than strictly necessary for a one-parameter tool. The structure is clear, with section labels like 'Returns:'.

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?

There is no output schema, so the description correctly takes on the burden of explaining return values. It lists all dict keys (`locks_when_idle`, `password_on_wake`, etc.), explains the `null` edge case, and provides enough context about the composed facts to make the tool's behavior fully understandable without ambiguity.

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 single parameter `response_format` is fully documented in the input schema with enum and default, but the description does not mention it at all. With 0% coverage, the description fails to compensate or add any semantic meaning beyond the schema. However, the parameter is trivial and the schema suffices, so the minimum viable score is appropriate.

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 opens with 'Screen-lock / auto-lock hygiene: does this Mac lock itself when left idle?' which clearly identifies the tool's purpose and resource. It also explains the fail-safe `locks_when_idle` verdict, distinguishing it from sibling info-gathering tools like `signalgrid_installed_apps` and `signalgrid_os_info`.

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 context for when to use the tool: 'The walk-up risk on a shared or plant-floor device.' It also mentions 'Read-only; no elevation,' which helps the agent understand it's safe for assessment. However, it does not explicitly name alternative tools or when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so no restatement is needed. The description adds crucial behavior: null enabled means UNKNOWN, never 'off'; null indicates a check that often requires elevation; and the response includes _unknown and _note fields.

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 tightly structured: one line for scope, a focused paragraph on null semantics, and a terse return-type spec. Every sentence earns its place with no repetition of the schema or annotations.

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?

For a no-argument read-only tool, this description is comprehensive. It defines the domain, the return mapping, the subtle null semantics, and the auxiliary _unknown and _note fields, making the tool usable without further investigation.

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 tool has zero parameters, so there is no parameter semantics to clarify. The description adds value by documenting the return structure, and the baseline for zero-parameter tools is 4.

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 opens with 'Core security posture' and names exactly four controls: SIP, FileVault, Gatekeeper, and application firewall. This clearly identifies the resource and scope and distinguishes it from sibling tools like signalgrid_network_posture and signalgrid_xprotect_status.

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 scope statement tells the agent when this tool is relevant: when checking these specific core security controls. It does not explicitly name alternatives or provide exclusions, but the control list is a clear context for use.

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

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses important behavioral details: null-means-unknown semantics, and that systemsetup checks often require elevation and will return null without it. These nuances are not inferable from annotations alone and are critical for interpreting results correctly.

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 compact and front-loaded with the purpose. It includes a security rationale, a reference to a sibling tool, and a precise return specification. While each sentence adds value, the text could arguably be trimmed slightly without loss, hence not a perfect 5.

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?

For a parameterless read-only tool with an output schema, the description is complete: it states what the tool reports, how to interpret nulls, potential elevation issues, and the exact return structure. Since the output schema already exists, the description does not need to re-explain return values but goes further by providing context and semantics.

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 tool has zero parameters, so there is nothing to document. Per the baseline for 0-param tools, a score of 4 is appropriate; the description adds no parameter-specific meaning because there are none, but the schema is fully covered by the absence of any parameters.

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 defines the tool's purpose: it checks remote-access exposure via SSH, remote Apple events, Screen Sharing, SMB file sharing, and Apple Remote Desktop. The explicit return format (dict mapping service names to enabled states) leaves no doubt about what the tool does, and the focus on sharing services distinguishes it from sibling tools like network_posture or listening_services.

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 context for when this tool is relevant, noting that on managed endpoints most sharing services should be off. It also references signalgrid_security_posture for null semantics, which helps an agent understand the tool's role in a broader security assessment. However, it does not explicitly compare against alternative tools or state when NOT to use it, so it stops short of full usage guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: values are null when unreadable, the difference between cached and live state, and the performance implication of the live check. This goes beyond the annotation flags.

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 well-structured with a summary, a usage note, args, and returns. While somewhat verbose, every sentence carries useful information, including the return keys and the red-flag interpretation. It is front-loaded with the core purpose.

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 one parameter, a rich output schema, and read-only annotations, the description is complete. It covers return values, null semantics, performance, and decision-making context (patch-hygiene red flag). No significant gaps remain.

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 description for check_online is thorough, covering default behavior and timing (30-120s). The description's Args section only repeats this information without adding additional meaning, so the baseline of 3 applies since schema coverage is 100%.

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 identifies the tool's resource: software update posture, including auto-update settings, last check, and available updates. It distinguishes from sibling posture tools by focusing specifically on software updates, though it lacks an explicit verb like 'get' or 'query'.

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 context for when to use the tool, such as checking for patch-hygiene red flags (LastUpdatesAvailable > 0 or stale LastSuccessfulDate). It also explains the trade-off between cached (instant) and live (slow) checks, guiding parameter selection. It does not explicitly name alternative tools, but the context is clear.

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

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

Description adds substantial context beyond annotations: it explains fail-safe flags (available, reliable), how to interpret edge cases (unknown states), and the meaning of statuses. It also explicitly confirms read-only behavior consistent with annotations, without contradiction.

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 longer but well-structured with clear sections ('Fail-safe', 'Returns'). Every sentence adds value, covering purpose, edge cases, and output format. It is slightly verbose but not wasteful, earning a 4.

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 no output schema, the description thoroughly documents the return dictionary fields and their semantics, along with failure modes and status categories. This makes it complete enough for an agent to understand the tool's behavior and outputs without additional context.

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 75%, with descriptions for limit, offset, name_contains, and response_format. The description does not add extra parameter semantics; it only explains outputs. The schema descriptions are sufficiently clear, so the baseline 3 applies.

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 precisely states the tool reports installed system extensions (endpoint-security/network) and highlights stranded extensions, a specific resource and condition. It differentiates from siblings like signalgrid_kernel_extensions by focusing on system extensions, and the return structure clarifies it lists them.

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 mentions it is read-only and needs no elevation, providing some operational guidance. However, it does not explicitly compare with alternatives (e.g., signalgrid_kernel_extensions) or state when not to use this tool. Usage timing is implied by the resource type rather than explicitly stated.

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

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

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses edge cases: auto_backup can be null if unreadable, and latest_backup may be a snapshot path or error text. It also explains the meaning of a stale backup, adding behavioral context that helps the agent interpret results. 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: a one-sentence purpose, a brief motivational context, and a clear list of return keys. Every sentence earns its place 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?

For a simple zero-parameter read-only tool, the description is complete. It explains the return keys, the meaning of null/error values, and the practical significance of the data. The existence of an output schema supplements the return structure, and the description covers the rest.

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 tool has zero parameters, so schema coverage is trivially 100%. The baseline for zero parameters is 4. The description does not need to explain parameters but instead explains the output structure, which is useful.

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: reporting Time Machine posture including backup on/off state, destinations, and latest backup. It uses specific terminology and distinguishes itself from sibling tools by focusing on Time Machine specifically. The return structure is outlined, leaving no ambiguity 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 provides context for when this tool is useful: identifying data-loss risk and drift signals from stale backups. It does not explicitly name alternative tools or exclusion criteria, but the specific domain and the drift signal context make usage scenarios clear. For a zero-parameter read-only tool, this level of guidance is adequate.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only.' More importantly, it adds rich behavioral detail about fail-safe logic: 'Unknown is never allow,' the bar rises to step_up on unreadable controls, and restrictions/denials occur under specific conditions. This goes well beyond the structured metadata.

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 yet information-dense, with a clear two-paragraph structure plus a return list. The first sentence immediately states the core purpose; the second explains fail-safe behavior; the third lists return fields. No fluff or redundancy.

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 complexity (composing multiple security signals into a verdict) and the presence of an output schema, the description adequately covers the verdict values, the fail-safe policy, and the return structure. It also clarifies the scope ('single-device verdict') and the fusion with other signals, leaving no major gaps.

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 tool has zero parameters, so the input schema is trivially complete. According to the scoring rule, 0 params earns a baseline of 4. No parameter explanation is needed, and the description instead focuses on the output semantics.

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 what the tool does: computes a fail-safe trust verdict (allow/step_up/restrict/deny) for the current Mac. It distinguishes itself from sibling tools that collect individual data (e.g., signalgrid_mdm_status, signalgrid_xprotect_status) by producing a composed verdict with reasons.

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 gives useful context: it 'composes security posture, MDM enrollment, update settings, XProtect currency, and stranded system extensions,' implying it is the aggregation tool rather than a per-signal data source. It also cautions that the verdict is single-device and the final decision is fused elsewhere. However, it doesn't explicitly name alternatives or state when to prefer this over individual sibling tools.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying the exact return structure (dict with three keys), the format of version strings, and the 'unavailable: <reason>' fallback. This goes beyond what annotations provide.

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 reasonably concise and well-structured: purpose first, then diagnostic context, then return format. The return section is slightly verbose but informative. No filler sentences.

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?

For a zero-parameter read-only tool, the description is complete: it states what is returned, the meaning of stale definitions, and potential root cause. The output schema further supports completeness, and the description aligns with sibling tool scope.

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 tool has zero parameters, so the input schema already fully defines usage. Baseline for 0 params is 4; no further parameter explanation is necessary.

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 identifies the tool's purpose: reporting versions of Apple's anti-malware components (XProtect definitions, Remediator, MRT). It names specific resources and is distinct from sibling tools like signalgrid_installed_apps or signalgrid_software_updates.

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 context on when this tool is relevant, noting that stale definitions indicate missing security updates and points to a likely cause (ConfigDataInstall disabled). It does not explicitly exclude alternatives, but the resource-specificity makes the intended use obvious among siblings.

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