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

With no annotations, the description carries the full burden. 'List all agents' communicates a non-mutating, read-only enumeration with network-wide scope, but it does not disclose return format, pagination, permissions, or potential limitations.

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 short sentence containing only the action, the resource, and the scope. There is no filler, 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 zero-parameter list-all tool, the description is nearly complete: an agent can infer the intended operation and scope. However, no output schema exists, and the description does not clarify what fields or shape the returned agent list will have.

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 no properties, so there are no parameters to document. Per the zero-parameter baseline, a score of 4 is appropriate; the description does not need to compensate for missing parameter 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 uses a specific verb ('List') and names a concrete resource ('all agents in the GoldHold network'). It clearly distinguishes this tool from sibling task, channel, memory, and profile tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the usage context clear: use this when you need the complete set of agents in the GoldHold network. It does not explicitly name alternatives or state when not to use it, 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 bears full responsibility for behavioral disclosure, but it only states that operations are sent in one request. It does not cover execution order, atomicity, partial failure behavior, side effects, or response format, all of which are critical for a batching 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 compact and front-loads the core concept of batching. Both sentences are purposeful, but the structure is minimal and leaves out useful context such as execution semantics or limits, which prevents a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, and the tool has moderate complexity as a batch processor. The description does not explain what the response looks like, whether operations run sequentially, whether a failed operation aborts the batch, or any maximum batch size, so it is 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 100%, so the baseline applies. The description repeats the method-and-params structure already present in the schema without adding new detail about valid methods, parameter formats, or per-operation constraints, so it adds no real 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 states that this tool bundles multiple operations into a single request, which clearly identifies it as a batch wrapper rather than a specific action tool. It names the structure of each operation (method and params), though it does not enumerate which operations or contrast itself with the sibling single-operation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'multiple operations in one request' implies the tool is for combining several calls, which is a reasonable usage signal. However, it does not explicitly say when to use batch versus the individual goldhold_search, goldhold_store, goldhold_send, goldhold_inbox, or goldhold_status tools, nor does it mention 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, the description carries the behavioral disclosure burden. 'List' implies a read-only enumeration, which is useful, but the description does not clarify what the returned channels look like, whether any access restrictions apply, or what 'communication channels' includes. This is minimally transparent for a zero-parameter 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 a single, grammatically complete sentence with no filler or repetition. Every word is meaningful and the core action and object are stated directly.

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 adequate for a trivial zero-parameter listing tool, but it does not explain the expected return format or how the channels relate to sibling operations like sending messages. There is no output schema to fill that gap, so the agent must infer the response shape.

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 schema fully covers parameter semantics by having none. The description does not need to describe parameters, meeting the baseline for parameterless tools.

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 clear verb ('List') and a specific resource ('communication channels available in the GoldHold network'). It is unambiguous and distinct from the sibling tool names, though it does not explicitly contrast itself with any sibling.

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 about when to use this tool versus related tools such as goldhold_send or goldhold_inbox. The description states only what the tool does, leaving the agent to infer appropriate usage from the tool 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?

With no annotations available, the description must carry the behavioral burden. It does state the side effect (saving state) and the benefit (seamless resume), but it doesn't disclose overwrite/versioning behavior, what data is included, or how the checkpoint is later retrieved.

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 sentences, front-loaded with the action, and every clause adds value. There is no filler or redundant metadata.

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 the schema is self-documenting, but there is no output schema and the description omits the lifecycle context: how the checkpoint is stored/overwritten and which sibling tool should be used to resume. This is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no parameter-level detail, landing at the baseline for high-coverage schemas.

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 operation ('Save a checkpoint') and the target resource ('current working state'), and adds a use-case ('enable seamless resume'). It doesn't explicitly name sibling alternatives like goldhold_resume or goldhold_plan_checkpoint, so it falls just short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete guidance on when to call the tool ('at natural breakpoints'). However, it doesn't mention when not to use it or how it relates to similar persistence tools like goldhold_plan_checkpoint, goldhold_store, or goldhold_restore.

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 does disclose that state is saved for the next session, which is useful, but it does not say whether closing is irreversible, whether the session can later be resumed/restored, what happens to existing session data, or what 'graceful' actually means. These are material unknowns for a side-effecting close 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?

Two short sentences with no filler. 'Graceful session end with summary' and 'Saves state for next session' are front-loaded and each sentence contributes meaningful information about the tool's effect.

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 session-closing tool with side effects and no annotations or output schema, the description is incomplete. An agent still needs to know whether closing is reversible, how compact changes behavior, whether the summary is mandatory, and how this relates to sibling tools like goldhold_resume, goldhold_restore, and goldhold_checkpoint. The description lacks these details.

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 only 50%: session_summary is described in the schema, but compact has no description. The tool description adds no extra meaning beyond saying 'with summary', and it never explains what compact does or how the summary is used. For an under-covered schema, the description fails to compensate for the undocumented compact 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 identifies the resource and action: ending a session gracefully with a summary and saving state for the next session. It is more specific than a bare 'Close session' and conveys the outcome, though the word 'graceful' is vague and it does not differentiate from siblings like goldhold_checkpoint or goldhold_plan_close.

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 'session end' implies when the tool should be used, but no explicit guidance is given about alternatives such as goldhold_checkpoint for mid-session saves or goldhold_resume for restoring later. There is no when-not-to-use or sibling routing, so the usage context 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. 'List' suggests a read-only operation, but the description does not state whether the operation is side-effect-free, whether it returns aggregated data, or what network or permission-related behavior may occur.

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 sentence with no filler. It front-loads the action and resource scope immediately and is appropriately sized for the simplicity of the tool.

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 discovery tool, the description names the core resource types and the network scope, which is mostly sufficient. However, the term 'capabilities' is somewhat vague, and with no output schema or annotations, the expected result shape is left unstated.

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 schema description coverage is 100%, so there are no parameter semantics the description needs to clarify. The baseline score of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb, 'List,' and names three concrete resource categories: agents, channels, and capabilities. It is semantically specific and scoped to the GoldHold network, though it does not explicitly explain how it differs from resource-specific siblings like goldhold_channels and goldhold_agents.

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 discover versus goldhold_channels, goldhold_agents, or other sibling tools. The description implies an exploratory listing use case but does not state conditions, exclusions, or alternatives.

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 it does disclose a significant behavioral trait beyond the schema: 'Also creates ASSET_REF records for each ref.' This is valuable and non-obvious. It does not, however, state whether the call overwrites the existing focus manifest, what happens to previous refs, or what the response contains.

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 tight sentences. The core action is front-loaded, the scope is defined with a compact hyphenated list, and the side effect is placed second. Every word earns its place 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 tool mutates a persistent state and creates records, so an agent would benefit from knowing whether the focus is replaced or merged and whether the side effect is reversible. The description explains the side effect but omits overwrite semantics and return behavior. Given no output schema and no annotations, this is a noticeable gap, though the flat parameter set keeps it from being severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds only conceptual mapping: 'what matters now' maps to priorities and 'what to ignore' maps to ignore. It does not add syntactic detail, type constraints, or behavior beyond the schema, so it meets but does not exceed the baseline.

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 names a specific verb and resource: 'Set the current focus manifest' and then enumerates what the manifest contains ('what project is active, what matters now, what to ignore'). It also distinguishes itself from sibling tools by focusing on the concept of 'focus' and adding the unique side effect of creating ASSET_REF records. This is a clear, non-tautological statement of purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a clear context: use this tool whenever the agent needs to establish or update the current focus manifest. However, it gives no explicit guidance about when not to use it or which sibling tools might be appropriate alternatives. The context is reasonably inferable but no exclusions or comparisons are offered.

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, but it only says the tool checks and returns messages. It does not disclose whether reading marks messages as read, or whether the call is side-effect-free, which matters given the include_read parameter and the concept of already-read messages.

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 short sentences, no redundant words, and the core action is front-loaded. It earns its size.

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 two optional parameters, and the description plus schema give enough to make a basic call. However, the lack of side-effect/read-state disclosure and absence of any guidance about output or failure modes leaves a notable gap for a tool with no annotations and no 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 description coverage is 100%, so the parameters are already documented in the schema. The description adds no further meaning to limit or include_read, keeping this at the baseline rather than higher.

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?

Description names a concrete verb-resource pair ('Check... inbox') and states the return payload ('messages from other agents and the owner'), so an agent knows what the tool is for. It does not explicitly contrast itself with siblings such as goldhold_send or goldhold_search, so it misses the differentiation that would make it a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus the many messaging/search siblings. The phrase 'Check the ... inbox' implies reading messages, but no explicit when-to-use, exclusions, or alternative routing is provided.

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?

There are no annotations, so the description carries the full burden. It states a read-only list operation that returns counts and last-updated timestamps, which is a useful behavioral detail. However, it does not clarify what constitutes a 'memory folder,' mention any authorization or side effects, or describe the response shape beyond the two stats.

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. Every word adds information: the verb 'List,' the scope 'all,' the resource 'memory folders,' and the specified stats. It is an ideal length for a no-input list tool.

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 no parameters and no output schema, the description provides enough to invoke it correctly: an agent knows no input is needed and the expected output (folder names, counts, last-updated times). The only slight gap is that 'memory folders' is not defined, but this is minor for such a simple read-only 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 tool has zero parameters, and the schema already reflects that with no properties. The description does not need to add any parameter-level detail. The baseline for zero-parameter tools is 4, and there is nothing more to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear verb and resource: 'List all memory folders'. It also names the exact output field ('stats (count, last updated)') and the scope ('all'), which differentiates it from siblings like goldhold_memory_read (singular read) and goldhold_store (write). This is enough for an agent to understand the tool's unique role.

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 such as goldhold_memory_read, goldhold_search, or goldhold_store. It only states what the tool does, not which situations call for it or when a sibling would be more appropriate.

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 responsibility for behavioral disclosure. It states the core read/browse action and implies a non-mutating operation, but it does not explain what happens if both id and folder are provided, whether no arguments is valid, or what the response shape looks like. This is a meaningful transparency gap for a tool with no schema-level guidance.

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

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tightly worded sentence captures the two main operations with no filler. The direct-read action is front-loaded and the folder-browse alternative follows naturally. Every word 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?

Given no output schema and no annotations, the description is too sparse to fully equip an agent. It does not clarify required combinations of id/folder/limit, response details, or what happens with an empty call. Since all parameters are optional, critical usage behavior is left ambiguous, making the definition 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 100%, so the baseline is 3. The description adds no real semantic value beyond the schema: it maps id to direct reads and folder to browsing, but does not clarify precedence, default behavior, or how limit interacts with the modes. It meets the minimum but does not exceed 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 'Read' and clearly identifies the resource: a memory packet by ID or a folder's contents. It clearly conveys the two modes of operation, but does not explicitly differentiate this tool from siblings like goldhold_search or goldhold_memory_namespaces.

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: when you have a packet ID or want to browse folder contents. However, it provides no exclusions or alternatives, such as 'use goldhold_search for query-based retrieval,' so the agent must infer the boundary between this tool and similar 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 present, so the description carries the full burden of behavioral disclosure. It indicates a persistence/write behavior, but it does not explain overwrite semantics, whether an existing plan is required, what happens to prior checkpoints, or what the response contains.

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. It is appropriately short, though the brevity omits important behavioral and parameter context.

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?

With no annotations, no output schema, eight undocumented parameters, and many closely related sibling tools, this description is not sufficient for reliable tool selection or invocation. An agent cannot determine the meaning of most fields or the consequences of calling this 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 8 parameters with zero description coverage. The description maps only 'active_refs' and 'resume_hint' to actual schema properties, and it mentions 'task counts' even though no such parameter exists in the schema. The remaining parameters like plan_slug, open_loops, current_state, and active_task_id are left unexplained.

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 an action ('Save') and a resource ('plan checkpoint'), and names some of the stored content ('active refs', 'resume hint'). It is clear enough to separate this from plan creation or restoration, though it does not explicitly distinguish itself from the sibling goldhold_checkpoint.

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 about when to use this tool versus related tools like goldhold_checkpoint, goldhold_plan_restore, or goldhold_resume. The description only restates the action itself, leaving the agent to infer the intended use case.

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 discloses the main behavioral consequence: it writes three persistent artifacts. It does not address reversibility, idempotency, or return format, so some behavioral burden remains.

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?

One terse sentence, front-loaded with the action and followed by a compact artifact list. 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 core operation is clear, but the tool lacks annotations and an output schema, and the description does not explain required parameter values, prerequisites, or return behavior. With four parameters and only 25% schema coverage, this is not enough 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 coverage is only 25% (one property has a description), and the tool description mentions none of the four parameters. The agent is left to infer the meaning of plan_slug, summary, and followups, and the valid range of outcome is only partially hinted in 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?

States a specific operation ('Close a plan') and names concrete artifacts ('final checkpoint, outcome fact, and closed manifest'), which clearly distinguishes it from generic-close and task-completion siblings. The resource and action are 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?

No explicit when/when-not or alternative selection guidance is given. 'Close a plan' only implies finalization, and near-siblings like goldhold_close and goldhold_task_complete are not disambiguated.

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 does disclose that this is a mutating creation action and reveals the return shape ('plan_slug and task IDs'), which is helpful given there is no output schema. However, it does not explain persistence, idempotency, failure behavior, or what happens to already existing plans, so transparency is only partially complete.

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 that efficiently names the action, the included components, and the return values. There is no filler, repetition, or unnecessary background.

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 an 8-parameter creation tool with no annotations and no output schema, this description is too incomplete. It does not explain which parameters are required, how PRD/manifest relate to actual fields, or when this should be used instead of sibling tools like goldhold_plan_task or goldhold_plan_checkpoint. The return value hint helps, but significant operational context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the schema already documents most required and optional fields. The description adds a conceptual grouping ('PRD, manifest, tasks, facts, asset refs') that is not present in the schema, but it does not explain how PRD and manifest map to specific schema properties. It also adds no field-level detail for nested objects like refs and facts, leaving some semantic gaps.

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 precise action ('Create a new plan') and identifies the key components included in the call: PRD, manifest, tasks, facts, and asset refs. It also names the return values ('plan_slug and task IDs'), which clearly distinguishes it from sibling tools that close, checkpoint, restore, or add single pieces to a plan.

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 about when to use this tool versus alternatives such as goldhold_plan_task, goldhold_plan_fact, or goldhold_plan_restore. The phrase 'in one call' hints at bulk creation, but there is no when-to-use, when-not-to-use, or naming of a sibling alternative.

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

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

No annotations are provided, so the description must carry the full behavioral burden. 'Record' does disclose a write/mutation operation, but the description does not mention side effects, what happens with the optional 'replaces' field, whether an existing decision is overwritten, or any permissions/expectations around the plan.

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 short sentence, front-loaded with the core action and resource, and has no filler or redundant phrasing. It is appropriately concise for the minimal information it conveys.

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?

With 6 parameters, no annotations, no output schema, and 0% parameter description coverage, this one-sentence description is insufficient. An agent cannot reliably determine the meaning of 'replaces', the expected content of 'body' and 'why', the relationship of plan_slug, or what the tool returns or changes.

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 only loosely maps 'rationale' to 'why' and 'impact' to 'impact'. It leaves the semantics of plan_slug, topic, body, and especially 'replaces' unexplained, so the description does not compensate for the missing schema-level parameter 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 uses a specific verb ('Record') and resource ('a decision within a plan'), and explicitly frames the content as including rationale and impact. Among sibling plan tools like goldhold_plan_fact and goldhold_plan_task, this clearly identifies a distinct resource type.

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 'within a plan' gives implied context for when to use this tool, and the decision-focused resource suggests it is for recording decisions rather than facts or tasks. However, there is no explicit guidance about when not to use it or which sibling tools might be better alternatives.

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 exist, so the description carries the behavioral burden. It does disclose a critical trait: recording a fact supersedes prior facts on the same topic. However, it does not clarify whether superseded facts are deleted/archived, whether a plan must exist first, or what a successful call returns.

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 short, front-loaded sentences with no filler. The core action and the key behavioral consequence appear immediately, though the SSOT abbreviation could be spelled out.

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 no annotations and no output schema, the description leaves meaningful gaps: no usage routing, no parameter details for source/confidence, and no indication of return behavior or prerequisites. The presence of 28 siblings makes this weaker than an isolated 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 description maps some parameters: 'within a plan' implies plan_slug, 'same topic' clarifies topic as the supersession key, and 'fact' implies body content. It does not explain optional source and confidence, and schema coverage is 0%, so partial compensation only.

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?

States a specific action ('Record') and resource ('fact (SSOT) within a plan'), and adds the distinct behavior 'Supersedes previous facts on the same topic'. This differentiates it from siblings like goldhold_plan_decision and goldhold_plan_task even without naming 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?

Provides no explicit when-to-use guidance or exclusions. With several plan-related siblings (plan_decision, plan_task, plan_checkpoint), the description relies entirely on the word 'fact' to route the agent and does not say when this tool is preferred or inappropriate.

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 does list the affected components, which is helpful, but it does not say whether the operation is destructive, whether it overwrites current working state, whether it is idempotent, what side effects occur, or what prerequisites exist. For a 'restore' action, this is a notable 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 two sentences with no filler. The core action and scope are front-loaded, and the usage guidance is compactly appended. It earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description should cover invocation context, parameter meaning, and return/behavior expectations. It covers when to use it and the components involved, but omits parameter semantics, return value shape, and behavioral caveats. An agent may still be uncertain how to correctly populate context_budget or what the restore result looks like.

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 by explaining the parameters. It does not explain plan_slug, context_budget, or include_closed at all. The parameter names are somewhat self-explanatory, but context_budget in particular has unclear semantics and is left completely undocumented.

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: 'Restore a plan's working state,' and enumerates exactly what is restored (manifest, checkpoint, tasks, assets, corrections). It also distinguishes itself from search by saying to use it 'instead of search,' so an agent can tell it apart from sibling tools like goldhold_search without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit usage context: 'Use at session start instead of search.' This tells the agent when to invoke the tool and directly names an alternative to avoid, which is exactly the guidance needed for a session-start restoration tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. It lists action verbs but does not disclose side effects, prerequisites, reversibility, or what happens to dependent/blocked tasks when an action is applied.

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 sentence with the action list front-loaded and no filler. It could add mode-specific detail without becoming bloated, but as written it is compact and readable.

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 complex 7-action, 12-parameter tool with no annotations and no output schema, so the description alone is far from sufficient. It omits mode-parameter mappings, required task_id behavior, dependency interactions, and the semantics of block/cancel/reorder.

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 only 25%, and the description does not compensate by explaining which parameters apply to which action. An agent is left to infer that task_id is needed for non-create actions, order for reorder, and title/description/owner/acceptance_criteria for create/update; the schema notes task_id but the description adds no value.

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 names a concrete resource ('tasks within a plan') and enumerates seven supported operations, so an agent knows this is a plan-scoped task dispatcher rather than a generic task tool. It does not explicitly contrast with sibling task tools, but 'within a plan' provides enough differentiation.

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 'within a plan' implies this tool is for plan tasks, giving some contextual guidance. However, there is no explicit mention of when to prefer this over siblings like goldhold_task_update, goldhold_task_create, or goldhold_task_complete, nor any 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, the description bears the full burden of behavioral disclosure. It says the tool can view or update the profile but does not describe what a view returns, whether capabilities are mutable, side effects, or any prerequisites such as authentication.

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

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler makes this concise. The slight ambiguity of 'View or update' and the inclusion of 'capabilities' not present in the schema keep it from being perfectly precise.

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?

With no output schema, the description should explain what a view returns and how the optional parameters select view versus update; it does neither. For a two-optional-parameter tool it is minimally usable, but the arg-dependent behavior is a clear 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?

Schema description coverage is 100%, so the schema already explains display_name and description; the description adds no parameter-level meaning beyond repeating those names. The mention of 'capabilities' is profile context rather than a schema property, so it does not improve parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly names the resource ('agent's profile') and the two supported operations ('View or update'), and it lists relevant fields. It does not explicitly differentiate from siblings, and the dual verb plus the unmodeled 'capabilities' field keep it from being a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to choose this tool over siblings such as goldhold_agents or goldhold_task_update, and no explicit statement that calling with no arguments views the profile while passing fields updates it. The intended usage is only implied by the operation phrase.

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 clearly describes what is restored and the intended session-start context, but it does not disclose whether restoring overwrites any current unsaved state or what the response/payload shape looks like beyond the schema hint.

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 sentences, front-loaded with the core action and contents, followed by a direct usage instruction. Every part earns its place and there is no redundant phrasing.

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-optional-parameter restoration tool, the description supplies the essential context: what state is loaded, when to invoke it, and what alternative to avoid. The missing explicit return-value description is partially mitigated by the schema's 'restore payload' wording.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: context_budget has a clear description ('Max tokens for restore payload'), a default, and a type. The tool description adds no parameter-specific value, but with complete schema coverage, the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Restore the current working state') and enumerates exact payload contents: checkpoint, focus manifest, asset refs, unresolved items, directives, corrections. It steers away from 'generic search' but does not differentiate from close siblings such as goldhold_resume or goldhold_plan_restore.

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?

Gives explicit timing ('Use at session start') and an explicit alternative to avoid ('instead of generic search'). It is clear for the search-vs-restore decision, but it doesn't address when to prefer other state-related siblings like goldhold_plan_restore or goldhold_resume.

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?

There are no annotations, so the description carries the full behavioral burden. It only says 'Resume a session' and lists returned values; it does not disclose side effects, whether an active session is required, or how the compact parameter affects 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 brief, front-loaded, and free of filler; every sentence adds some information. It is slightly under-sized given the unanswered usage and parameter details, but the text itself is concise.

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?

With no annotations and no output schema, the description is too thin. It omits what compact does, whether a session must already exist, and how resume relates to restore/checkpoint, leaving important edge cases unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'compact' has 0% schema description coverage and is never mentioned in the description. The name is somewhat self-explanatory, but the description adds no explicit meaning beyond the schema's name and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific action ('Resume a session') and lists the returned items, so the basic function is clear. It does not explicitly differentiate from siblings like goldhold_restore or goldhold_checkpoint, preventing a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use resume versus the many sibling session tools, and it states no prerequisites or exclusion cases. An agent must infer the intended 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 does add behavioral context by specifying that search is 'semantic' and that results are 'ranked from past sessions'. It does not disclose output structure, edge-case behavior, or any operational constraints, but the core behavior is at least 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?

Two short, front-loaded sentences with no filler. Both sentences contribute meaningful information: the first states the operation and scope, the second states the result type and source.

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 all parameters are documented in the schema, but no output schema exists and the return shape is only vaguely described as 'ranked results'. The description is adequate for basic invocation but leaves the result format and selection criteria between sibling tools unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents query, limit, and folder. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 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 uses a specific verb and resource: 'Semantic search across GoldHold memory' and states the outcome as 'ranked results from past sessions'. It is clearly more specific than the bare tool name, though it does not explicitly differentiate from siblings like goldhold_memory_read or goldhold_discover.

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 for when to use this tool versus the many GoldHold siblings. The description does not mention alternatives, exclusions, or context that would help an agent decide between goldhold_search, goldhold_discover, and goldhold_memory_read.

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 states that a message is sent, but it does not mention whether sending is irreversible, what delivery guarantees exist, how success or failure is reported, or any permission prerequisites. This is a meaningful gap for a side-effectful 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 concise: two short sentences with the primary action front-loaded. The recipient constraint is stated immediately after the verb, and there is no filler or redundant detail. Every word contributes to the agent's understanding of the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity of this tool — three simple required string parameters, no nested objects, and no output schema — the description plus the schema is largely sufficient for invoking it correctly. It would be stronger with explicit delivery or error behavior, but those are partially covered by the simple shape of the tool and the parameter descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description partially repeats the `to` parameter's recipient values but omits the 'all' option that appears in the schema, and it adds no extra meaning for `subject` or `body`. It does not improve on what the schema already provides, but it also does not mislead.

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 clear verb and resource: 'Send a message via GoldHold messaging.' It also specifies the recipient types, which helps an agent understand the scope. However, it does not explicitly distinguish itself from sibling tools like goldhold_inbox or goldhold_channels, so it misses the full sibling-differentiation bar.

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 its usage by declaring that it sends a message, and it narrows recipients to owner, guardian, or agent name. It does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools. Usage is inferable but not clearly directed.

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 does disclose that this is a health/sync/system inspection and implies a read-only action, but it does not describe the return shape, possible states, or any side effects. This is adequate but not deeply 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?

One concise sentence that front-loads the action and names three concrete areas of inspection. Every word earns its place, 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?

For a zero-parameter tool, this is mostly complete for invoking it correctly. However, with no output schema and no annotations, the description leaves 'system info' vague and does not indicate what a successful or failed status response might look like, which an agent may need for interpreting 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 tool has zero parameters, so the input schema already fully describes invocation requirements. The description adds no parameter details, but none are needed; this matches the zero-parameter baseline.

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 verb ('Check') and a clear resource ('GoldHold connection health, sync state, and system info'). This clearly distinguishes it from sibling tools, which all perform more task-specific actions like updates, tasks, planning, or messaging.

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 used to inspect GoldHold status, but it does not explicitly say when to prefer it over alternatives or if it should be used before certain operations. There is no direct sibling status tool, so the overlap is low, but the timing/context guidance is not stated.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It does add useful non-obvious context: storage is done 'via relay and synced to Pinecone', implying an asynchronous or eventual-consistency pipeline. However, it omits side effects, failure modes, idempotency, and acknowledgment behavior, leaving important behavioral questions unanswered.

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 zero filler. The primary action is front-loaded ('Save a memory to GoldHold'), and the architectural context in the second sentence earns its place by explaining persistence behavior.

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 4-parameter write tool with no output schema and no annotations, the description provides the core purpose and storage mechanism but leaves gaps around return/acknowledgment, eventual-consistency implications, and how this tool relates to the many GoldHold siblings. It is adequate for basic invocation but not fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond framing the stored content as a 'memory', which does not exceed the baseline expected when the schema fully covers the 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 uses the specific verb 'Save' with the object 'a memory to GoldHold', clearly identifying this as a persistent write operation. It is distinguishable from read-style siblings like goldhold_memory_read, though it does not explicitly name a sibling alternative. The relay/Pinecone detail reinforces storage semantics without obscuring the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. The intended usage is only implied by the verb 'Save a memory', and with many siblings such as goldhold_memory_read, goldhold_plan_fact, and goldhold_task_create, the agent receives little help choosing among them. No alternatives, exclusions, or prerequisites 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 the full burden of behavioral disclosure. It does not mention that completing a task is likely a mutating and possibly irreversible action, nor does it describe side effects, permission requirements, or whether updates are allowed after completion. A single clause with no behavioral context is insufficient.

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 short and front-loaded, with no wasted words. However, it is so terse that it borders on under-specification rather than purposeful conciseness. It conveys the core operation but skips context that would help an agent use the tool correctly.

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 mutation tool with no annotations and no output schema, the description is incomplete. It does not explain the effect of task completion, whether it is reversible, or how it relates to task_update and task_create. An agent could misuse this tool by applying it when a task should merely be updated.

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 already documents both parameters fully, and schema description coverage is 100%. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies. The omission is acceptable because the schema carries the semantic load.

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 verb and resource: 'Mark a task as completed.' It clearly identifies the operation as completing a task, which distinguishes it from creating or updating a task. However, it does not explicitly contrast with sibling tools, so it is clear but not fully differentiated.

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 like goldhold_task_update or goldhold_task_create. The description implies use when a task should be marked complete, but it does not state conditions, prerequisites, or when another tool should be chosen instead. This leaves the agent without routing information.

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 restates the creating behavior implied by the tool name and does not mention side effects, idempotency, auth requirements, or success/failure behavior.

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

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low in complexity and has full schema coverage, making the description minimally sufficient. However, with no annotations and no output schema, return behavior and side-effect details remain unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter meaning, but the baseline of 3 is appropriate because the schema handles the heavy lifting.

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 a specific resource ('a new task in the GoldHold task queue'). It clearly distinguishes the operation from sibling tools like goldhold_task_update, goldhold_task_complete, and goldhold_task_list by emphasizing 'new'.

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 should be used when the agent needs to create a task, but it does not explicitly state when not to use it or name alternatives. Usage context is clear but left to inference.

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. The verb 'List' strongly implies a read-only operation, and 'open tasks' clarifies the filtering behavior. However, it does not disclose details like return format, ordering, pagination, or whether completed tasks are ever included, though the simplicity of the tool reduces the severity of those gaps.

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

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core action and resource. There is no filler or redundant information; every word contributes to understanding what the tool does.

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 — zero parameters, no required inputs, no output schema, and no nested objects — the description is complete enough for an agent to invoke it correctly. The phrase 'open tasks from the GoldHold task queue' provides sufficient context about what will be returned.

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 no parameters, so the schema fully covers parameter semantics and the description needs to add nothing further. The baseline score of 4 applies because there are zero parameters to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List') and a specific resource ('open tasks from the GoldHold task queue'). It clearly differentiates this read-only listing operation from sibling task mutation tools like goldhold_task_create, goldhold_task_update, and goldhold_task_complete.

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 this tool is for retrieving open task queue entries, but it does not explicitly state when to choose it over alternatives or mention any exclusions. The usage context is reasonably clear from the phrase 'open tasks', but there is no direct comparison to sibling tools.

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

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

With no annotations at all, the description carries the full burden of disclosing behavior, but it only states that a task is updated. It does not mention whether fields are updated independently, whether the task must already exist, what happens to omitted fields, or any required permissions, so the agent is left to guess about 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 entire description is a single clear sentence with no filler, front-loading the action and listing the affected fields. Every word adds meaning, and there is no redundant restatement of the tool name.

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 mutation tool with no annotations, no output schema, and an ambiguous relationship to goldhold_task_complete, this description is too thin. It omits practical guidance such as whether updating status to done is handled here or via task_complete, how partial updates behave, and what the response contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the inline schema already describes each parameter with acceptable detail. The description adds no parameter-level information beyond enumerating the fields; it neither clarifies that multiple fields can be updated at once nor adds format or constraints, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Update') plus a resource ('a task') and enumerates the mutable attributes (status, priority, assignee), which clearly differentiates it from sibling tools like goldhold_task_create and goldhold_task_list. An agent can immediately understand what this tool acts on and what changes it makes.

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: whenever an existing task's status, priority, or assignee needs to change. However, it gives no explicit guidance about alternatives, such as whether goldhold_task_complete should be preferred for marking a task done, and no exclusions are stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the compound nature and one-call behavior, but it does not disclose write side effects of send/store, whether operations are optional or combined, what compact does, or what the response looks like.

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 short, front-loaded with the core compound behavior, and contains no filler. The second sentence about being the primary tool adds usage context, though it is somewhat imprecise.

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 compound tool with nested objects, optional parameters, no annotations, and no output schema, the description is under-specified. It does not explain how the three operations combine, the meaning of compact, return values, or how this relates to the many sibling 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 already provides descriptions for send, store, and search, so the description adds little parameter-level meaning beyond naming the three operations. The compact parameter remains undocumented in both the schema and the description, leaving a noticeable gap.

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 this is a compound tool that combines search, store, and send in one call, which distinguishes it from sibling tools like goldhold_search, goldhold_store, and goldhold_send. It is more specific than a tautology, though 'the primary tool for most interactions' remains vague about what a 'turn' actually is.

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 primary tool for most interactions' gives a broad directive to prefer this tool by default, but it does not explain when to use dedicated siblings such as goldhold_send or goldhold_search instead. The usage guidance is implied rather than explicitly contrasted with alternatives.

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