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

With no annotations provided, the description fully carries the burden of safety disclosure. It explicitly states that the log is 'NEVER unlinked' and is 'always renamed to audit.cleared.<ts>.log,' which prevents a user from expecting destructive deletion. It also discloses the required confirmation value.

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, purposeful sentences. The first sentence front-loads the action, the second provides key safety behavior, and the third gives the parameter requirement. Every line earns its place.

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?

This is a simple tool with one parameter and an output schema. The description covers purpose, safety, and the confirm gate. With an output schema present, return values need no explanation. Nothing important is missing for a tool of this 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?

The schema only shows a single optional string parameter with an empty default, offering no guidance. The description compensates by stating the exact required value: 'Pass confirm='YES' to proceed.' This adds meaning beyond the schema, though it does not explain what happens for other values or response details.

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: 'Rotate the audit log to a timestamped archive.' This clearly distinguishes it from sibling tools like sassy_audit_log (which likely retrieves logs) and sassy_audit_search (which searches logs) by emphasizing the rotation/archive behavior.

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 clearly implies when to use this tool: when you need to clear/rotate the audit log while preserving history. It also gives a concrete usage requirement: 'Pass confirm='YES' to proceed.' It does not explicitly exclude alternatives or name sibling tools, so it misses 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?

With no annotations, the description carries the full burden. It discloses the output row format (timestamp | event | pattern | command truncated), the 'newest last' ordering, and the exact semantics of include_bypasses for blocks versus pattern_bypass entries. It doesn't explicitly say 'read-only', but 'Show'/'audit' strongly implies no side effects.

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 the core purpose, then adds a compact use-case sentence, an output-format line, and two focused parameter explanations. Every sentence earns its place; there is no fluff or repetition.

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 2-parameter read-only listing tool with an output schema, this description covers purpose, output fields, ordering, parameter behavior, and the intended audit use case. An agent has everything needed 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 0%, so the description must compensate. It does: count is explained as max rows to return with newest-last ordering, and include_bypasses is described in terms of the real behavioral difference between blocks and bypasses, including why the bypass view 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 opens with a specific verb and resource: 'Show recent shell-interceptor pattern matches (blocks + bypasses).' It also says it surfaces noisy-pattern events you'd otherwise have to grep for, which clearly distinguishes it from the audit_log/audit_search/audit_clear siblings.

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: this tool is for surfacing shell-interceptor false positives and auditing what allow_pattern has let through. It explains when to set include_bypasses, but it does not explicitly name alternative tools or state when not to use this one.

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?

With no annotations, the description carries full burden for behavioral disclosure. It only indicates a read operation and the vague qualifier 'recent', but omits details about ordering, limits, or that it is non-mutating beyond the word 'read'.

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 a single concise sentence that is front-loaded and free of fluff. It successfully states the core purpose without unnecessary words.

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 existence of an output schema, the description still lacks necessary context about the meaning of 'recent' and the count parameter. It also does not position itself among audit-related siblings, leaving the overall behavior under-specified for a tool with a parameter and multiple related tools.

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 has 1 parameter (count) with 0% description coverage, and the description does not mention it at all. Thus the agent receives no explanation of what 'count' controls, failing to compensate for the missing schema 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 reads recent audit log entries with a specific verb ('read') and resource ('recent audit log entries'). It is distinguishable from siblings like audit_search, but does not explicitly contrast 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?

No guidance is provided on when to use this tool versus alternatives such as sassy_audit_search. The description only states what it does, leaving usage context entirely to the agent.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Search audit log for a keyword' and does not mention output structure, pagination, how the 'count' parameter affects results, or any edge cases. This is minimal and under-specified.

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 a single concise sentence with no fluff or repetition. It is front-loaded with the action and target resource. However, it is too sparse to fully support the tool's usage, but for conciseness alone it is well-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?

Although an output schema exists, the description is incomplete for a search tool. It fails to indicate how the 'count' parameter works, what the output entries look like, or how this search differs from other audit-related tools. The presence of many sibling tools increases the need for contextual differentiation, which is absent.

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. It mentions 'keyword' which maps to the required parameter, but does not explain the 'count' parameter, its default value, or its effect on search results. The schema itself provides only a type and default without a 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 uses a specific verb 'Search' and resource 'audit log', clearly indicating the tool's function. It distinguishes from sibling tools like sassy_audit_log, sassy_audit_false_positives, and sassy_audit_clear by emphasizing a keyword-based search operation.

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?

There is no guidance on when to use this tool versus alternatives such as sassy_audit_log or sassy_audit_false_positives. No exclusions, prerequisites, or context are provided; the description only states the basic action.

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?

No annotations are provided, so the description carries the burden. It adds useful context by specifying 'absolute screen coordinates' and 'works across multiple monitors', but does not disclose potential side effects like focus stealing or required accessibility permissions.

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?

Two concise sentences that front-load the action and provide necessary guidance. Every word earns its place with no 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 simple click tool, the description is reasonably complete: it specifies coordinate system, multi-monitor support, and a prerequisite. With an output schema present, return values are not needed, but it could mention coordinate origin or button defaults.

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%, and the description only explains 'x' and 'y' implicitly as coordinates. It does not explain the 'button' or 'clicks' parameters, leaving them ambiguous without schema 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's function: 'Click at absolute screen coordinates' – a specific verb and resource. It also distinguishes itself from sibling tools like sassy_type_text and sassy_hotkey by focusing on clicking at coordinates.

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 to 'Use sassy_screen_info to find monitor positions first', which is a clear prerequisite. It implies usage context for clicking at coordinates but does not mention alternative tools for other input actions.

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?

With no annotations provided, the description carries the full burden. It describes the tool as estimating usage and listing outputs, which implies a read-only, non-destructive operation, but it does not explicitly state that it has no side effects or mention any permissions or reversibility. This is adequate but not rich in behavioral disclosure.

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 front-loaded. The first sentence states the core action, and the following lines list outputs and use case without any fluff or redundancy. Every sentence earns its place.

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 simple with no parameters and has an output schema, so the description doesn't need to detail return values. Given its simplicity, the description sufficiently covers the tool's purpose and outputs, making it complete enough for an agent to select and invoke 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 adds context about what the tool returns (e.g., total tokens, % of window, heaviest tools), which is meaningful even though there are no parameters to explain.

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 with a specific verb ('Estimate') and resource ('current context window usage'). It details what it shows (token estimates, percentage of 200K window, heaviest tools), distinguishing it from sibling tools like sassy_observability_tool_stats.

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: 'Use this to understand why your context is running low.' This gives context for when to employ the tool, though it does not explicitly mention when not to use it or name alternative 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?

With no annotations, the description carries the full burden. It discloses two key behavioral traits: refusal to operate on protected paths and refusal to silently overwrite existing destinations. These are significant behaviors that an agent must know. It does not mention permissions, error formats, or other side effects, but for a copy tool the disclosed behaviors are the most critical.

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 two sentences, front-loaded with the core purpose, and every sentence adds functional value. The first sentence states what the tool does; the second explains limitations and resolution. There is 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?

The tool is simple with only two parameters and an output schema exists, so return values need not be described. The description covers the primary purpose and key constraints. It could mention that replication is recursive for directories (though 'directory tree' implies it) or how errors are surfaced, but for a copy operation this is sufficient. A small gap is not mentioning whether the destination must be a directory or a file path.

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 input schema provides only 'source' and 'destination' as strings with no descriptions, and schema description coverage is 0%. The description adds that the source/destination can be a file or directory tree and that protected paths are refused, which gives some meaning. However, it does not elaborate on path formats, whether the destination must exist, or handling of trailing slashes. The contribution is minimal but existent, so a 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 'Copy a file or directory tree.' uses a specific verb and resource, clearly distinguishing the tool from siblings like sassy_move and sassy_safe_delete. It communicates both the action and the scope (file or directory tree) effectively.

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 guidance by stating that protected src/dst are refused and that overwriting an existing destination is not allowed, with an explicit alternative: 'use sassy_safe_delete on the destination first if you really need to replace it.' This gives an alternative and context, though it does not explicitly contrast with other copy-related tools (e.g., sassy_move).

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?

With no annotations, the description carries the full burden and does well: it discloses that coordinates are absolute across all monitors, names the underlying libraries, and flags the macOS permission need. It does not mention any additional side effects or limitations, but for a read-only state getter, this is reasonably transparent.

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?

Three sentences, each earning its place: first states the core purpose, second describes output style and coordinate system, third covers platform specifics. No fluff or repetition.

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?

Covers the essential functionality, output format, coordinate system, and platform-specific requirements. The only notable gap is not explaining the include_taskbar parameter, but the output schema likely handles return value details. Overall sufficient for an agent to invoke effectively.

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 has 0% description coverage and the description does not mention the include_taskbar parameter at all. The parameter name is somewhat self-explanatory, but the description fails to clarify its effect on output or why an agent would set it. Given the low coverage, the description should have compensated but did not.

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 retrieves desktop state (open windows and positions), which is a specific verb+resource combination. It distinguishes itself from sibling tools like screenshots or screen info by specifying 'open windows and positions' and adds 'lean output' and coordinate system details.

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 clear context on when to use it by explaining platform-specific implementations (pywinauto on Windows, System Events on macOS) and the Accessibility permission requirement. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of full exclusion 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions return values (diff text plus stats) and does not disclose side effects, permissions, error conditions, or any operational constraints.

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 front-loaded with the primary purpose. The parameter note and return-value note add useful detail without being verbose, though the structure could be slightly cleaner.

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 diff tool, the description covers the core behavior and return values. However, it lacks behavioral context like accessibility of files or error handling, and the output schema is not provided to compensate. Adequate but with clear 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?

Schema description coverage is 0%, so the description must compensate. It explains 'context_lines' (number of surrounding lines, default 3), but path_a and path_b are not described beyond their names, which are self-explanatory. Partial compensation for low schema coverage.

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: 'Compare two files and return a unified diff.' This is a specific verb+resource combination that distinguishes it from sibling tools like file readers or writers.

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?

Usage is implied by the purpose (use when you need to see differences between files), but there is no explicit guidance on when to use it over alternatives or any conditions for use. No exclusions are mentioned.

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?

No annotations are provided, so the description carries full behavioral burden. It discloses fuzzy fallback with diff reporting, failure on multiple matches, encoding/line-ending preservation, preview output, protected-path refusal, and snapshot creation. This is unusually comprehensive for a tool description.

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 one-line summary followed by focused bullet points. Each bullet conveys a distinct behavioral detail without unnecessary elaboration, making it compact yet information-dense.

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 lack of annotations and minimal schema descriptions, the description covers the essential aspects of a file editing tool: success criteria, failure modes, side effects (snapshot), output (preview), and safety (protected paths). An output schema exists, so detailed return-value documentation is not required in the description.

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%, so the description must compensate. It explains old_text and new_text semantics via exact match and fuzzy fallback, but path is not described beyond its schema title. The description adds partial value but misses potential path-related details like format or restrictions.

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 performs a surgical file edit by finding old_text and replacing it with new_text. This distinguishes it from siblings like sassy_edit_multi (multiple edits) and sassy_write_file (whole-file write) through the 'surgical' framing and exact-match preference.

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 to use it: exact match preferred, fuzzy fallback, fails on multiple matches, and refuses protected paths. However, it does not explicitly compare with alternatives such as sassy_edit_multi for multi-block edits or sassy_write_file for full rewrites, which would make the guidance complete.

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?

With no annotations, the description carries full burden, and it excellently discloses key behaviors: edits are applied in order, each must have exactly one match, protected paths are refused, and content is snapshotted to _DELETE_/ before changes. This goes well beyond a simple 'apply edits' statement.

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, front-loaded with the main purpose, and every sentence contributes new information: format, ordering, matching constraint, and safety behavior. It is well-structured and free of 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?

The description is complete for the tool's complexity: it covers the edit format, application order, match requirements, safety restrictions, and snapshot behavior. Since an output schema exists, return value details are not required. The description provides enough context for an agent 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?

The schema has 0% description coverage, so the description must compensate. It thoroughly explains the 'edits' parameter with a JSON format example and constraints (each must have exactly one match). The 'path' parameter is not explicitly described but is obvious from the tool name and context. This adds significant meaning beyond the bare schema.

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 with a specific verb ('Apply') and resource ('multiple edits to a file'), and distinguishes it from simpler edit tools by emphasizing the 'in one call' batch capability. The format explanation further clarifies the operation.

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 (applying multiple edits in one call) but does not explicitly mention alternatives or exclusions. It does not reference sibling tools like sassy_edit_block, but the purpose statement inherently guides the user toward batch editing scenarios.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It accurately states the key error condition ('Returns error if not set'), which is valuable. The word 'Get' implicitly indicates a read operation with no side effects, though it does not elaborate on permissions or return format.

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 extremely concise, consisting of two short sentences that immediately convey the purpose and a key behavioral detail. No redundant information is included.

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?

This is a simple single-parameter tool. The description covers the core action and the notable error condition, making it sufficient for an agent to understand what to expect. The presence of an output schema likely covers return value details, so the description need not list everything.

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 has one parameter 'name' with no description, and the description does not explicitly map it to the environment variable name. However, 'environment variable value' strongly implies the parameter is the variable name. The description adds minimal meaning beyond the schema, but enough to understand the parameter's role.

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 action ('Get') and the resource ('environment variable value'), making the tool's purpose unambiguous. It is distinct from sibling tools like sassy_env_set and sassy_env_list, which handle different operations.

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 the tool is for reading a specific environment variable, but it does not explicitly state when to use it over alternatives like sassy_env_list or provide any exclusions. The usage context is clear from the name but lacks explicit 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states an important behavior: sensitive values (tokens, keys, secrets) are masked. This goes beyond a basic 'list' and helps the agent anticipate security masking. It does not mention permissions or pagination, but these are less critical for a simple list tool.

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 two sentences, front-loaded with the primary action in the first sentence. Every word earns its place—it states the operation, the optional filter, and the sensitive-value masking without redundancy. This is a model of conciseness.

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 list tool with one optional parameter and an output schema present, the description is complete. It covers what the tool does, how filtering works, and a critical security behavior. There are no missing pieces that would prevent correct invocation or understanding of results.

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 provides no description for the single parameter filter_str (0% coverage), so the description must compensate. It does so by explaining that the filter is optional and matches by name substring, adding meaningful semantics beyond the parameter name and default value. This is sufficient for the sole parameter.

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 with a specific verb and resource: 'List environment variables.' It also distinguishes itself from sibling tools like sassy_env_get and sassy_env_set by focusing on listing rather than retrieving or setting a single variable. The optional substring filter further clarifies intent.

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: whenever you need to list environment variables, optionally filtered by name substring. It does not explicitly mention alternatives or exclusions (e.g., 'use env_get for a single variable'), but the scope is self-evident and consistent with the tool's name and siblings.

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?

No annotations are provided, so the description carries the full burden. It discloses two key behavioral traits: persistence for the lifetime of the server and no modification to system env. This is valuable context beyond just 'set env var' and covers the main side effects for this simple tool.

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 sentences, front-loaded with the primary action. Every sentence earns its place: purpose, persistence scope, and guidance for permanent changes. No 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 2-parameter tool with an output schema, the description covers purpose, lifetime, and scope, and even points to alternatives. It lacks minor details like overwrite behavior or validation, but these are not critical given the tool's simplicity and the presence of an output 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 0%, so the description must compensate for parameter meaning. It implicitly identifies 'name' as the environment variable and 'value' as its value via the verb 'set an environment variable', but adds no extra semantics (e.g., constraints, format, overwrite behavior). The property names are self-explanatory, so the description adds marginal value beyond the schema.

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 'Set an environment variable for the current SassyMCP process' with a specific verb and resource. It distinguishes from sibling tools like sassy_env_get and sassy_env_list by emphasizing the 'set' action and the process-local scope.

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 clear usage context: persists for the server lifetime and does not modify system env. Explicitly suggests registry or system settings for permanent changes, giving an alternative. Could more explicitly say 'use this for temporary process-scoped env settings' but the intent 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?

With no annotations, the description carries the transparency burden. It clearly states it returns metadata (not content), lists the specific metadata categories, and implies a read-only operation ('Get'). It does not mention error cases or access requirements, but for a simple read-only tool, this is adequate.

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 two short sentences, front-loaded with the core purpose, followed by a list of included metadata. Every word earns its place; no filler or repetition of schema details. The line-break and bullet-like structure improves readability.

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 has a single parameter, an output schema, and simple read-only semantics, this description is sufficient. It covers the tool's scope (file/directory) and key output categories. It doesn't need to explain return values (output schema exists) or provide usage examples for such a straightforward operation.

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 has one parameter `path` with 0% description coverage. The description only refers to 'file/directory' in the purpose, implying path should be a filesystem path, but does not explain required format, whether it must exist, or any constraints. The description does not compensate for the sparse schema information.

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 uses a specific verb ('Get') and resource ('detailed file/directory metadata'), clearly distinguishing it from sibling tools like sassy_read_file (reads contents) and sassy_list_dir (lists directory entries). The inclusion of specific data types (size, timestamps, line count, Excel sheet info) reinforces this clarity.

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 for metadata retrieval (vs. reading content), and the list of included fields suggests what it's good for. However, it does not explicitly state when to use it or provide alternative tool names, leaving the agent to infer from the context. No exclusions or comparisons to sassy_read_file or sassy_list_dir are given.

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?

With no annotations provided, the description carries full responsibility. It transparently discloses the read-only nature ('Get') and details the return payload (config, OS, Python, memory, disk, uptime, modules, usage stats). It does not mention potential side effects, but for a getter this is sufficient. It adds context beyond the name by specifying the exact information returned.

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: two short sentences, with the core action in the first sentence and a bullet-like return list in the second. The 'DC get_config equivalent' is slightly cryptic and adds minor noise, but overall it is well-structured and front-loaded with the most important information.

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 (0 params, no nested objects, and an output schema exists), the description is complete. It covers the tool's purpose and return contents, and the output schema can handle formal return types. The context signal 'Has output schema: true' means the description need not explain return formats, yet it still provides a helpful overview. No important gaps remain for a config getter.

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 0 parameters, so the baseline is 4 per rubric. The description does not need to explain parameters since there are none; it appropriately focuses on the return value, which is more relevant. Schema coverage is 100% by vacancy, so no additional parameter semantics are required.

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 uses a specific verb+resource: 'Get full SassyMCP configuration and system info.' It clearly defines the scope and lists the exact categories of returned data (config settings, OS, Python, memory, disk, uptime, loaded modules, tool usage stats), making it unmistakable what the tool does and distinguishing it from other getters like state_get or env_get.

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: 'Get full SassyMCP configuration and system info' clearly suggests using this when you need configuration and system details. However, it does not explicitly mention alternatives or when not to use it, nor does it contrast with siblings like sassy_observability_metrics or sassy_set_config. The 'DC get_config equivalent' line hints at compatibility but does not provide actionable 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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions the return value (file contents + SHA), implying a read operation, but does not disclose authentication needs, network behavior, failure modes, or effects. It adds limited context beyond the tool name.

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 a single clear sentence with no filler, front-loading the action and result. Every word earns its place, and it is easy to scan.

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?

Although the tool is relatively simple and has an output schema, the description lacks important context: it does not explain the role of each parameter, how to handle errors, or why a user would choose this over sibling read tools. The 0% parameter coverage and missing usage guidance leave the description incomplete for reliable invocation.

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% and the description provides no explanation of the parameters (owner, repo, path, ref). It does not clarify what 'ref' means, whether it is optional, or how path should be formatted. The description fails to compensate for the schema's lack of documentation.

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 'Get file contents + SHA from a repo' clearly states the verb (Get), resource (file contents + SHA), and source (a repo). It is specific enough to distinguish from many sibling tools, though it does not explicitly compare to sassy_read_file or sassy_read_multiple.

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 offers no guidance on when to use this tool versus alternatives, no examples, and no mention of when to choose sassy_ghq_get over sassy_read_file or other repository-related tools. It simply states what it does.

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?

With no annotations, the description carries the full behavioral burden but only states the primary action and label format. It does not disclose authentication needs, side effects, permissions, or response behavior, leaving a significant gap for a mutating tool.

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 extremely brief and front-loaded, with the label format note earning its place. While minimal, it avoids redundancy and is appropriately sized for the tool's apparent simplicity.

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 5-parameter create operation with no annotations, the description lacks important context like required owner/repo semantics, authentication, and relationship to sibling issue tools. Even though an output schema exists, the operation's preconditions and side effects are unexplained.

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 should compensate; it only specifies that labels are comma-separated. Parameters like owner, repo, title, and body have no additional guidance beyond their names, leaving required inputs partially underspecified.

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 uses a specific verb ('Create') and resource ('an issue'), clearly identifying the operation. It doesn't explicitly contrast with sibling tools like sassy_ghq_issues, but the singular/plural naming and action verb make the purpose apparent.

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?

No guidance on when to use this tool versus alternatives such as sassy_ghq_issues for listing. It merely states the action without prerequisites, exclusions, or context.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'List issues' only implies a read operation but does not disclose pagination behavior, default state, or what the response contains. It adds minimal transparency beyond the name.

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 extremely short ('List issues.'), which is under-specification rather than concise. It omits critical details and does not earn its place as sufficient guidance.

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 4 parameters and lack of annotations, this description is severely incomplete. It does not explain return format, default behavior, or how to filter issues, making it inadequate for correct tool invocation.

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%, and the description provides zero meaning for the 4 parameters (owner, repo, state, page). The description does not compensate for the lack of parameter documentation, leaving the agent to infer meaning solely from parameter names.

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 'List issues' states a specific verb and resource, but it is vague and does not distinguish itself from sibling tools like 'sassy_ghq_issue' (singular) or clarify the scope (e.g., which repository). It lacks context about being GitHub issues or any filtering parameters.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of whether this is for queried issues, specific states, or how it relates to other issue/PR 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly indicates a mutating action ('Create') but does not disclose potential side effects, required permissions, branch handling, or what happens on duplicate PRs. The description is not misleading, but it is minimal.

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 a single, front-loaded sentence with no filler, which is structurally efficient. However, its brevity sacrifices essential operational detail, so it is concise but not as useful as it could be.

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?

Although an output schema exists (so return values don't need explaining), the description omits all contextual guidance: branch semantics, when to use the tool vs siblings, and parameter meaning. Given the six-parameter schema and absence of annotations, this is insufficient for reliable tool selection and invocation.

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 input schema has six parameters with 0% schema description coverage, and the tool description mentions none of them. While names like 'owner', 'repo', and 'title' are self-explanatory, 'head' and 'base' are Git-specific and remain unexplained, leaving the agent to infer their roles.

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 states 'Create a pull request.', which is a specific verb+resource pairing. It clearly identifies the core action and differentiates from sibling tools like sassy_ghq_issue, sassy_ghq_push, and sassy_ghq_protect by naming the PR operation, though it offers no additional nuance about the scope or type of pull request.

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?

No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as sassy_ghq_issue, sassy_ghq_get, or sassy_ghq_push, and it lacks any prerequisites, exclusions, or context about the PR creation workflow.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the core protective actions ('no force push, no delete, enforce on admins') but omits important behavioral context such as required permissions, whether it modifies existing protections, idempotency, or side effects. The description is too brief to fully inform the agent of the tool's impact.

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 a single, compact sentence that immediately conveys the core action and its key constraints. There is no redundant phrasing or unnecessary detail; every word contributes to understanding the tool's function.

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 and the presence of an output schema, the description is adequate for basic identification but lacks essential contextual details. It fails to mention that owner and repo are required, branch defaults to main, or any prerequisites like admin access. Though complexity is low, the description leaves the agent without enough guidance for correct invocation.

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, but it provides no parameter explanations. The parameter names (owner, repo, branch) are self-explanatory, and the branch default is in the schema, but the description adds no semantic value beyond what the schema already shows.

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 with a specific verb ('Protect') and resource ('a branch'), and the parenthetical details (no force push, no delete, enforce on admins) concretely define the protection rules. This distinguishes it from sibling tools like sassy_ghq_push or sassy_ghq_pr, which handle different GitHub operations.

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 no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. While the purpose implies usage for protecting branches, there is no mention of when not to use it or how it relates to other repository management 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?

With no annotations, the description carries the burden of transparency. It discloses atomicity ('atomically') and the create/update semantics, and it mentions using the Git Data API to avoid SHA and ETag issues. However, it does not mention potential failure modes, prerequisites, or response behavior, leaving some gaps for a mutation tool.

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 brief and front-loaded with the core purpose. The 'THE daily-driver tool' and 'no SHA bugs, no ETag nonsense' add personality and context but flirt with business jargon. Overall, every sentence contributes to understanding, and the structure is easy to scan.

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 and the presence of an output schema, the description covers the essential behavior and parameter format. It lacks explicit caveats about error handling or branch conflicts, but for a straightforward atomic push, it is largely complete. The absence of annotation details is offset by the description's explicit focus.

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%, so the description must compensate. It provides crucial detail for the 'files' parameter, specifying the exact JSON array format with path and content objects. While other parameters (owner, repo, branch, message) are not explicitly described, their names are self-explanatory, and the description addresses the one non-obvious parameter.

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 states the action with a specific verb and resource: 'Push files atomically (create or update).' The scope is clear (files to a repository), and the tool name 'ghq_push' reinforces its function. It distinguishes itself from sibling tools like sassy_ghq_pr and sassy_ghq_get by clearly indicating a file push operation.

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 phrase 'THE daily-driver tool' implies this is the primary tool for pushing files, providing some usage context. However, it does not explicitly state when to avoid it or mention alternatives (e.g., 'for pull requests, use sassy_ghq_pr instead'). The guidance is more implied than explicit.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the primary behavior—'Returns the full expert playbook'—and describes the playbook's content. However, it does not mention potential side effects of activation (e.g., whether the hook remains active, if changes are persistent, or if there are permissions required). This is a moderate gap.

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 front-loaded. The first sentence immediately states the action and return value. Subsequent sentences add necessary context about the playbook and the list tool without redundancy. Every sentence contributes to understanding, making it highly efficient.

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 tool with one parameter and an output schema present, the description covers the essential information: what it does, what it returns, and how to determine valid input values. It is largely complete, though a brief mention of the effect of 'activation' on hook state would make it fully comprehensive.

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% for the single 'hook_name' parameter, so the description must compensate. It adds value by instructing 'Use sassy_hooks_list to see available hooks', which informs how to populate the parameter. However, it does not provide examples, formats, or constraints beyond this, leaving the parameter's semantics partially underspecified.

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: 'Activate an operational hook. Returns the full expert playbook.' This uses a specific verb ('activate') and resource ('operational hook'), and it distinguishes the tool from its sibling by referencing 'sassy_hooks_list', implying activation is the complementary operation to listing.

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 use: 'Use sassy_hooks_list to see available hooks' indicates a prerequisite step and indirectly suggests using this tool after listing. It also explains the playbook's utility in guiding tasks. However, it does not explicitly state when not to use this tool or mention alternatives like deactivate or suggest.

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?

Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It states the action but does not mention side effects, reversibility, required permissions, or the impact on currently active hooks. 'Deactivate' implies mutation, but without safety context the agent cannot judge the consequences of invoking this tool, especially when clearing all hooks.

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 extremely concise and front-loaded. The first sentence states the purpose, and the second sentence defines the parameter. There is no redundant wording or filler, making it easy for an agent to parse quickly.

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 tool with a single optional parameter and an output schema, the description covers the essential purpose and parameter usage. The main gaps are the lack of behavioral safety information and explicit usage comparisons with siblings, but the description is sufficient for basic invocation and understanding of the core operation.

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 description fully explains the only parameter hook_name with concrete semantics: a specific hook name to disable, or an empty string to disable all hooks. This directly compensates for the 0% schema coverage and leaves no ambiguity about 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 states a specific action ('Deactivate') on a specific resource ('hook') with clear scope ('a hook or all hooks'). It immediately distinguishes itself from sibling tools like sassy_hooks_activate and sassy_hooks_list, leaving no ambiguity about the operation.

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 clear operational context: the parameter hook_name can be a specific hook or empty to clear all. This tells the agent when to supply a value and the effect of omitting it. However, it does not explicitly contrast with alternative tools (e.g., activate, list) or state conditions to avoid using this tool, so it falls just shy of full 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation and explains the purpose of hooks, but it does not mention permissions, auth, or output size. The non-destructive nature is implied by 'list,' but not explicitly stated.

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 exactly three sentences, front-loading the core purpose and then adding context about hooks and the next step. Every sentence earns its place, with no fluff or repetition.

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 list tool with an output schema, the description is complete: it defines the domain (hooks as playbooks), states that all available hooks are listed, and points to the activation tool. The output schema covers return format, so no additional description is needed.

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 takes zero parameters, so the description adds value by explaining what is listed (operational hooks) and the meaning of hooks. With 100% schema coverage on an empty schema, the baseline for zero parameters is 4; there is no parameter-specific information to add.

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: 'List all available operational hooks.' This clearly states the tool's function and scope, and it is distinct from sibling tools like sassy_hooks_activate, which loads a hook, and sassy_hooks_suggest, which presumably suggests hooks.

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 what hooks are and tells the agent to use sassy_hooks_activate to load one after listing, giving clear context for when listing is useful. However, it does not explicitly contrast with sassy_hooks_suggest or state exclusions, so it stops short of a full when-to-use guide.

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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It states that the tool 'Returns matching hooks ranked by relevance', which implies read-only behavior and gives insight into the output format. It does not mention edge cases or permissions, but for a non-mutating suggestion tool, the key behavioral trait (returning ranked results) is disclosed.

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 sentences, front-loaded with the main action, and every sentence adds value: purpose, input/output, and usage guidance. There is no redundancy or unnecessary detail.

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 single-parameter tool with an output schema, the description covers the essential aspects: what it does, what input to provide, what output to expect (ranked suggestions), and when to invoke it. The existence of an output schema covers return-value details, so the description is sufficiently complete for an agent to use 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?

The input schema provides only a parameter name ('user_text') with no description (0% schema coverage). The description compensates by explaining 'Pass the user's request text', giving clear semantic meaning. It does not provide format details or examples, but the single simple string parameter is adequately explained.

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 with a specific verb ('Suggest') and resource ('hooks'), and adds the scope 'based on what the user is trying to do'. It distinguishes itself from sibling hook tools like list/activate/deactivate by emphasizing ranked matching, making its unique purpose unambiguous.

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 specifies when to use this tool: 'when it's unsure which hook to use' and proactively when the request matches a known domain. However, it does not name alternative tools (e.g., sassy_hooks_list, sassy_hooks_activate) or state when not to use it, so it falls short of a full 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?

With no annotations provided, the description must disclose behavioral traits. It only states the basic action and key format, without disclosing whether the shortcut is sent to the foreground application, whether it requires special permissions, or any side effects. This is a significant gap for a tool that simulates input.

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 two short sentences with no wasted words. The first sentence states the purpose, and the second provides the parameter format. Excellent front-loading and structure.

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 simple (one parameter, output schema exists), but the description lacks context such as whether it works globally, requires a focused window, or any limitations. While the example and format are useful, the missing behavioral context makes it incomplete for fully informed 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?

The input schema provides only a 'keys' string with zero description coverage. The description adds crucial format guidance: 'Keys separated by +, e.g. ctrl+c.' This clarifies the required syntax and provides a concrete example. It does not enumerate valid keys, but the format is sufficient for basic usage.

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 action ('Press keyboard shortcut') and the resource ('keyboard shortcut') with an example. It distinguishes from siblings like sassy_click (mouse) and sassy_type_text (typing text) by focusing on key combinations using '+'. However, it doesn't explicitly mention 'simulate' or 'send to active window', which could add precision.

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 no guidance on when to use this tool versus alternatives. There is no mention of context (e.g., 'use for global hotkeys' or 'for typing text use sassy_type_text'). The example implies usage for shortcuts, but no explicit when-to-use or exclusions are given.

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?

With no annotations provided, the description carries the full burden. It transparently explains the safety gating for mutating verbs, including the adversarial LLM rationale and the protection against accidental destructive requests. It also gives concrete format examples for headers and body. It does not detail timeout behavior or error handling, but the key behavioral trait (mutating gate) is well disclosed.

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 the core action, then immediately contrasts with web_inspector. The parameter list is concise and scannable. The allow_mutating explanation is slightly long but directly serves safety and usage understanding. No redundant filler exists.

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 tool with an output schema and no annotations, the description covers purpose, usage guidance, parameter semantics for the key fields, and an important safety behavior. The only omissions are timeout_seconds and explicit return format guidance, but the output schema handles return values and timeout has a default. The description is sufficiently complete for an agent 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 description coverage is 0%, so the description compensates by adding meaning to method (listing allowed values), headers (JSON example), body (string or JSON), and allow_mutating (required for state-changing verbs). It omits timeout_seconds and url, but url is self-explanatory and timeout_seconds has a default. Overall, it adds substantial semantic value beyond the schema.

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 'Make an HTTP request' as the core verb-resource pair and differentiates itself as a 'lightweight alternative to web_inspector for quick API calls.' This distinguishes it from sibling tools like web_inspector and sassy_http_ping, making the tool's purpose immediately obvious.

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?

'Lightweight alternative to web_inspector for quick API calls' provides clear usage context. Additionally, the explicit requirement that allow_mutating must be true for state-changing verbs guides when to use the tool (and what flag to set). It lacks explicit exclusions or alternative references beyond web_inspector, but context is strong.

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?

With no annotations, the description carries full responsibility for behavioral disclosure. It accurately states the return values, but it does not explicitly confirm the operation is read-only, does not mention network side effects or timeouts, and does not describe error handling. It implies a safe health check but leaves important behavioral details undocumented.

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 two sentences, front-loaded with purpose and including a concise parameter explanation. Every word earns its place with 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?

The tool is simple with one parameter and an output schema present, so the description covers the core purpose and parameter semantics. While it lacks explicit behavioral details and usage guidance, it is adequate for a straightforward health-check tool, especially given the output schema provides return structure.

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 input schema only defines 'urls' as a string with no description. The tool description compensates by explaining that 'urls' is a comma-separated list of URLs to check, which provides the essential format and meaning beyond the schema. This is valuable given 0% schema description coverage.

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 performs a quick health check on multiple URLs and returns status code and response time for each. This is a specific verb (check) with a resource (URLs) and clear outputs, making it distinct from a generic HTTP tool like sassy_http.

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 for health-checking multiple URLs but does not explicitly mention when to use this tool versus alternatives such as sassy_http or sassy_observability_health. There are no exclusions or alternative names provided, so guidance is only implicit.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful details: the output includes [FILE]/[DIR] prefixes and depth controls recursion. However, it does not explicitly state that it's a read-only operation, nor does it mention behavior for hidden files, permissions, or error handling. For a simple listing tool, this is adequate but not comprehensive.

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 two sentences with no unnecessary words. The primary action is front-loaded, and the secondary sentence adds pertinent parameter behavior. This is highly concise and appropriate for the tool's simplicity.

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 simple and has an output schema, so return values don't need elaboration. However, the description could be more complete by clarifying the depth semantics (e.g., what depth=0 or depth=2 means) and by stating whether the path must point to a directory. These gaps are not covered by the schema descriptions (which are absent), leaving some ambiguity in usage.

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. It explains 'depth' as controlling recursion, but the explanation is vague (e.g., how depth values translate to recursion levels). It does not provide any additional meaning for the 'path' parameter, which is left as an implicit directory path. The description offers minimal help to an agent trying to correctly set 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 lists directory contents, which is a specific verb+resource. It distinguishes itself from siblings like sassy_read_file (reads files) and sassy_search_files (searches for files) by explicitly targeting directory listing. The [FILE]/[DIR] prefixes add further clarity about the expected output.

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 purpose implies when to use it (need to see what's in a directory), but there is no explicit guidance on when not to use it or which alternative to pick. The mention of depth controlling recursion gives some usage context but doesn't clarify edge cases or compare to other file-related 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?

With no annotations, the description carries the burden. It discloses what it returns and the optional filter, and implies a read-only load. It doesn't mention potential size/cost or whether state is modified, but the provided information is sufficient for a startup context loader.

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?

Three short, front-loaded paragraphs: purpose and contents, explicit usage directive, and parameter clarification. Every sentence earns its place, no 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 low-complexity load tool with an output schema present and one optional parameter, the description is complete. It covers what is returned, when to use it, and the optional filter, leaving no critical 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?

Schema coverage is 0%, and the description adds meaning by describing 'project' as an optional filter to focus on a specific project. It could be more specific about value format, but the core semantic is clear for a single optional parameter.

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 loads full context for session startup and enumerates the exact contents (critical memories, active tasks, blockers, recent milestones, learned patterns). It distinguishes from memory siblings by focusing on startup context rather than individual recall/search.

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 instructs to call at the START of every session, with a rationale. However, it doesn't mention when not to use it or contrast with alternatives like sassy_memory_recall or sassy_session_start, leaving a small gap.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Delete a memory' without mentioning whether the deletion is permanent, reversible, or if there are any side effects. For a destructive tool, this is a significant transparency gap.

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 exceptionally concise and front-loaded: 'Delete a memory.' followed by a single usage guideline. Both sentences earn their place, and there is no redundant or filler content.

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?

Even though the tool is simple and an output schema exists, the description lacks essential context: the meaning of the 'key' parameter, the permanence of deletion, and any prerequisites or side effects. Given that there are no annotations, the description alone is not sufficient for an agent to safely and correctly invoke this destructive 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 schema has 0% description coverage for the single required parameter 'key', and the description does not explain how to specify which memory to delete or where to obtain a valid key. The parameter name is self-explanatory to some degree, but the description adds no semantic value beyond the schema.

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 uses a specific verb ('Delete') and resource ('a memory'), clearly distinguishing it from sibling memory tools like sassy_memory_remember, recall, and search. The purpose is immediately obvious and unambiguous.

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: 'Use when information is no longer relevant.' This is a useful when-to-use guideline. However, it does not explicitly mention when not to use it or suggest alternative 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool writes state to both memory and crosslink, which is a helpful mutation disclosure. However, it does not explain whether a previous handoff is overwritten or merged, whether any permissions are needed, or what the response contains, leaving some behavioral ambiguity.

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 the core purpose, then gives the continuation flow in one line, followed by a compact parameter list. Every sentence earns its place; there is no filler or redundant repetition of schema information.

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 write-tool with 8 parameters and no annotations, the description covers the essential context: what the handoff contains, how fields are formatted, and how the next session will consume it. It lacks a concrete example and does not discuss overwrite behavior, but the provided info is sufficient for an agent to invoke the tool correctly in most session-handoff scenarios.

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 fully compensate. It does exactly that: every one of the 8 parameters is explained with clear semantics, including the allowed values for status ('in-progress | blocked | needs-review | paused | completed') and the expected comma-separated format for list fields. This adds substantial meaning beyond the bare schema property names.

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 with a specific verb and resource: 'Write a session handoff — saves state to BOTH memory and crosslink.' It also distinguishes itself from related memory tools by explaining that the next session calls sassy_memory_context and sassy_crosslink_recv to resume work, which clearly differentiates its role from siblings like sassy_memory_remember or sassy_memory_log.

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 when to use the tool: at the end of a session to hand off context to the next session, and it names the exact retrieval tools for the next session. It does not explicitly say when not to use it or mention alternatives, but the use case is clearly scoped as a session handoff, which is enough to guide 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?

With no annotations, the description carries full burden. It states the action ('Log a milestone event') which implies a write/append operation, but gives no details on persistence, permissions, or side effects. The examples are helpful but behavioral nuance is not explored.

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 brief and front-loaded with the purpose, followed by a clear parameter list. Every line adds value, with no wasted words.

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 low complexity, an output schema exists, and the description covers the intended usage and parameters. It does not mention retrieval or related tools, but given the sibling context and schema presence, this is not a significant gap.

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?

Although schema description coverage is formally 0%, the description includes inline parameter explanations (event, project, tags) with concrete examples for event and tags. This adds meaning beyond the bare schema property titles and helps the agent understand expected values.

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 logs milestone events and gives examples of significant completions, decisions, or changes. It is specific about the resource and action, though it does not explicitly differentiate from sibling tools like sassy_memory_milestones or sassy_memory_remember.

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 for significant completions, decisions, or changes,' providing clear context for when to use the tool. However, it does not mention alternatives or scenarios where it should not be used, which would make it more complete.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states a read-like action ('View') and an optional filter, but does not explain ordering, pagination, what 'recent' means, or whether it has side effects. Minimal behavioral context is given beyond the function name.

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 a single, concise sentence with no filler words. It front-loads the primary action and resource, making it instantly understandable.

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 return values need not be described. However, the description is minimal: it does not clarify what 'milestones' are in this context, nor does it define the limit parameter. For a simple view tool, it is adequate but leaves gaps in understanding.

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 for missing parameter documentation. It explains 'project' as a filter but does not mention 'limit' at all, leaving one parameter semantically undocumented. The description adds partial value but is incomplete.

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 with a specific verb ('View') and resource ('recent milestones'), and notes an optional filter ('by project'). This distinguishes it from sibling tools like sassy_memory_search or sassy_memory_recall, which focus on other memory operations.

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 when one needs to view recent milestones, but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. There is no reference to sibling tools that might serve similar purposes.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Recall a specific memory by key' and does not mention what happens if the key is missing, whether the memory is returned, or any side effects. This is minimal behavior information.

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 a single, efficient sentence with no wasted words. It is appropriately sized for a simple tool, though it could have included more context without becoming verbose.

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 one-parameter tool with an output schema, the description is adequate but has gaps. It does not place the tool within the brotherhood of memory tools nor explain error behavior or key sources. Given the many memory-related siblings, more context would be valuable.

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. It adds the meaning that the 'key' identifies a specific memory, but gives no details on key format, how to obtain keys, or relationship to other memory tools. This is barely more than the parameter name itself.

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 'Recall a specific memory by key' clearly states the verb (Recall), resource (memory), and method (by key). It distinguishes from siblings like sassy_memory_search by emphasizing direct key-based access, though it doesn't explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus similar memory tools such as sassy_memory_search or sassy_memory_log. The description only states what it does, with no context for selection or exclusions.

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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It mentions persistence across sessions, which is useful, but omits important behavioral traits such as what happens when an existing key is reused (overwrite vs. error), whether the operation is reversible, or any side effects. This is a significant gap for a write operation.

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 single opening sentence followed by a clear parameter breakdown. Every line provides necessary information, with no filler or repetition.

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 gives a complete picture for a simple memory-store tool: purpose, parameter semantics, and the key behavioral fact of persistence. An output schema is present, so return values need no explanation. It loses a point for not addressing the overwrite/update semantics, which is a common usage concern for persistent stores.

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 fully compensates by explaining all five parameters: the key naming convention (task_<concept>_..., pattern_..., etc.), value content, comma-separated tags, priority levels (critical|high|normal|low), and project examples. This goes far beyond what the raw schema provides.

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 'Store a memory that persists across sessions,' using a specific verb ('store') and resource ('memory'). This clearly differentiates from sibling tools like sassy_memory_recall (retrieval) and sassy_memory_forget (deletion).

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 by stating the tool stores persistent memories and then details parameter conventions. However, it does not explicitly state when to use this tool versus alternatives (e.g., recall/search) or mention exclusions, so the guidance is more implicit than explicit.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It explains parameter behavior but does not state whether the operation is read-only, whether there are side effects, how filters combine, or what happens with the 'limit' parameter. The name 'search' hints at safety but this is not explicit.

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: one clear summary sentence followed by a parameter list. Every line adds value, with no fluff or repetition of schema information.

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 there is an output schema and the tool is a simple search, the description is mostly complete: it covers the main filter parameters and their semantics. Missing details like limit behavior and filter interaction are the only gaps. No annotations increase the burden, but the description handles it reasonably well.

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. It documents four of five parameters (query, tags, project, priority) with meaningful detail, such as 'free text search across keys and values' and 'comma-separated tag filter.' However, the 'limit' parameter is not described, and filter combination semantics are omitted.

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 'Search memories by text, tags, project, or priority,' which specifies the verb (search), resource (memories), and scope. It distinguishes from sibling memory tools like remember/recall/forget, though it doesn't explicitly name alternatives.

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 ('Search memories') but provides no explicit when-to-use guidance or exclusions. It doesn't compare with other memory retrieval tools like sassy_memory_recall or sassy_memory_context, leaving the agent to infer when search is the appropriate choice.

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?

With no annotations provided, the description must fully disclose behavioral traits. It implies a read-only stats operation but does not explicitly state side-effect freeness, data source, or any limitations. The description only lists content, not 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 a single concise sentence, front-loaded with the purpose. Every word earns its place, with 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 simplicity (no parameters) and the existence of an output schema, the description is reasonably complete. It lists the primary stats fields, and the output schema presumably provides further detail. However, it lacks explicit usage context and does not mention its read-only nature, which would be more 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?

The tool has zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description adds no parameter-specific meaning because no parameters exist, but it does clarify the tool's output focus, which is sufficient in this 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 identifies the tool as providing 'Memory system stats' and enumerates specific data points (total memories, priorities, projects, milestones). It distinguishes from sibling tools like sassy_memory_log or sassy_memory_recall by focusing on statistics rather than operations, though it lacks an explicit verb like 'get' or 'show'.

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?

No guidance is given on when to use this tool versus alternatives. It does not mention exclusions, alternatives, or contexts where this tool is preferred, leaving the agent to infer usage from the name and description alone.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It does state that the tool shows before/after token estimates, which is a key behavioral detail. However, it doesn't explicitly mention that the tool is non-destructive, has no side effects, or any limitations (e.g., payload size). This is a moderate gap given there are no annotations to fall back on.

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 very brief, using three short sentences to convey purpose, usage, and output. It is front-loaded with the main purpose and every sentence adds necessary information without redundancy. This is an exemplary concise description.

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 low complexity (one parameter, no nested objects) and the presence of an output schema, the description is complete. It explains what input to provide and what output to expect (before/after token estimates). Since the output schema exists, the description doesn't need to detail return values. This is a complete description for a simple test utility.

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 only defines sample_json as a string with no description, so the description adds meaningful semantics. It tells the user that the parameter should contain a GitHub API response in JSON format, which goes beyond the bare type information. While it doesn't specify exact formatting (e.g., raw JSON string), it provides enough context for correct usage.

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+resource: 'Test the GitHub response minifier on sample JSON.' This clearly states the tool's purpose and distinguishes it from siblings, none of which are minify-related. The additional context about pasting a GitHub API response and seeing shrinkage reinforces the exact scope.

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: use this tool when you have a GitHub API response to test how much the minifier shrinks it. It does not name alternatives or exclusions, but given the tool's unique purpose among siblings, this is sufficient. The phrase 'Paste a GitHub API response' implies a straightforward testing workflow.

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 'missing parents' behavior is disclosed, but there is no mention of error handling, idempotency, or side effects. With no annotations, the description carries the full burden but remains thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.