SKV Network

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

With no annotations, the description carries the full behavioral burden, but it only enumerates action names. It does not disclose side effects, whether actions are destructive or reversible, required permissions, or what each action changes.

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-loads the action list with no filler. However, for a polymorphic tool with eleven parameters, this level of brevity leaves out critical structure such as per-action parameter requirements.

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 complex action-dispatch tool with eleven parameters, no annotations, no output schema, and no schema descriptions, the description is far too sparse. It names the actions but omits parameter mapping, behavioral detail, and routing guidance needed to invoke board_act 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 needs to compensate, but it only lists action values and notes that 'result' is required for done. It does not explain which of the other nine parameters apply to which action, or what fields like key, kind, item_id, event_id, parent_id, and waiting_for mean.

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 identifies the tool as handling 'Board actions' and lists the supported action names, which gives a basic sense of its role. However, it does not clarify what a 'board' is here, what each action operates on, or how this differs from the sibling board_list tool.

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 board_act versus board_list or any other sibling, nor on how to choose among the listed actions. The only constraint-like note is '(result required)' for done, which is a requirement rather than usage guidance.

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

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

With no annotations, the description carries the full burden. It hints at returned fields (priority, subtasks, waiting_for, results), but it does not disclose read-only behavior, pagination, permission requirements, or what the history parameter changes.

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 fragment with no wasted sentences, and the resource is front-loaded. However, the terseness leaves important details under-specified rather than making it efficiently complete.

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 two-parameter list tool with no annotations and no output schema, the definition is incomplete. It does not explain how status filtering works, what history does, or what a caller should expect from the response.

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 lists status-like values but does not explicitly connect them to the status parameter or explain filtering behavior, and the history parameter is entirely unaddressed.

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 identifies the resource as a task board and enumerates statuses and item fields, but it does not explicitly state the action (listing/retrieving). The verb is only implied by the tool name board_list, and board_act is not 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 board_act or other siblings, nor any prerequisites or exclusions. The agent can infer it is for viewing the board, but the definition provides no explicit usage 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?

No annotations are provided, so the description carries the full burden and largely fails: it does not confirm this is a read-only operation, does not state page size or how many pages exist, and does not say what happens past the last page or whether an out-of-range page errors or clamps.

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?

It is front-loaded and contains no filler, but it is under-specified rather than efficient — four words are too few to carry the pagination contract. Brevity here costs more than it saves.

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, and 0% parameter documentation, the description is the only source of behavioral detail and it supplies almost none. An agent can call it, but cannot predict the response shape, page size, or termination condition.

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 `page` parameter, so the description must compensate. "Paged" weakly connects to `page`, but it never explains page size, whether pages are 1-indexed, or how to know when paging is complete, leaving the caller to guess.

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?

"Full constitution, paged" names the resource and indicates the complete document is returned in pages, so an agent can infer it is a retrieval tool. However, no verb is stated and it gives no basis for distinguishing it from siblings like constitution_status, which presumably returns summary state rather than the full text.

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 when-to-use guidance, no mention of when to prefer constitution_status (summary) over this full fetch, and no note about how pagination should drive repeated calls. The word "full" hints at a distinction but never makes it 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 behavioral burden and does well: it discloses the consent requirement, prohibits silent installation, lists the duties being accepted, and explains the post-install step_zero sequence. It stops short of describing reversibility, persistence, or failure behavior, so it is not fully 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 dense but front-loaded and every clause contributes operational information. It is slightly telegraphic and semicolon-heavy, but not padded.

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

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

For a consent-gated installation with no annotations, no output schema, and minimal input schema, the description supplies the essential consent gate, fallback path, and return sequence. Remaining gaps around permanence, uninstall, and error handling keep it from being fully 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 single parameter has 0% schema description coverage, so the description must compensate. It does so precisely by instructing the agent to pass user_confirmed=true only after explicit user consent, and by explaining that a negative response should route to the plain memory tool instead.

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: install the constitution. It also distinguishes the action from sibling read/status tools by framing it as a consent-gated installation with enumerated duties and rules.

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 condition: install ONLY after the user explicitly says yes, and never silently. It also names the fallback behavior when the user declines: use the plain memory tool instead.

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 meaningful behavior: a positive result implies consent is already given and prescribes the next call. It does not describe the return shape (e.g., what an uninstalled result looks like) or whether the call has side effects, leaving gaps for a zero-annotation 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?

It is short with no wasted prose, and the actionable routing is front-loaded after the status question. But the phrasing is overly telegraphic ("then turn every turn"), trading clarity for brevity rather than achieving genuine 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 zero-param, no-output-schema status tool, the description should convey what it returns and what to do next; it gestures at both but cryptically. It is minimally sufficient but not complete for an agent to confidently interpret a negative (not-installed) result.

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 and the schema is empty with full coverage, so there is nothing for the description to disambiguate. Baseline 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 is a telegraphic fragment ("Installed?") that largely restates the name constitution_status rather than stating a specific verb+resource. An agent can infer it checks installation state, but the definition never plainly says what the tool does or distinguishes it from the sibling constitution_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?

It does provide workflow routing after a positive result ("next_action=step_zero(page=1), then turn every turn"), which is genuine usage guidance. However, it never addresses when to call this versus constitution_get or constitution_install, so the when-to-use decision against siblings is 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, the description carries the full behavioral burden and does so well: it discloses that the call is paid, that secrets are masked, what is returned, that the user must be told the total cost, that advice is data rather than instructions, and that nothing runs by itself.

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

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

The description is compact and front-loaded: it leads with what the tool is, then immediately covers consent, outputs, cost handling, and safety. Every sentence carries operational value.

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 annotations and no output schema, the description covers the important behavior, return values, cost warning, safety note, and consent rule. The main gap is the unexplained tried and failed parameters.

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 explain all four parameters. It clarifies task as one masked task and consent as requiring prior user approval, but it does not explain tried or failed at all.

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 and resource: sending one task to Claude and ChatGPT for a paid second opinion. It also distinguishes the follow-up sibling by saying the return includes an id for consult_accept.

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 clear prerequisites: ask the user first and set consent=true only after the user agrees. It also names consult_accept as a follow-up path, though it does not explicitly state when not to use this tool.

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

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

With no annotations, the description carries the load well: it discloses the side effect (saves to memory), the differing return shapes per mode ([ev:id] vs a cube_create draft), and an explicit non-behavior ('Does not run the advice'). It does not state whether re-accepting the same consult_id double-writes or is idempotent.

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 tight clauses with the core action front-loaded and mode behavior second; almost no waste. The 'which=claude|gpt' shorthand is terse to the point of being slightly telegraphic, but 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?

For a 3-param mutation with no annotations and no output schema, return values and mode effects are covered, which is the important part. Gaps remain on idempotency, the fate of the non-selected answer implied by 'one', and the source of consult_id.

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 — and it does well for two of three params, supplying the `which` enum values (claude|gpt) that the schema lacks and the two `as_kind` modes with their returns. `consult_id` is never mentioned, leaving its provenance (presumably from `consult`) 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 verb+resource are specific: 'Keep one consult answer' — persist a chosen answer from a prior consult. It is clearly distinguishable from sibling `consult` (which asks) and from `cube_create` (which the cube draft feeds into). It stops short of 5 because 'keep' doesn't explicitly say whether the unchosen answer is discarded.

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 routes between the two modes (as_kind=note vs as_kind=cube) and gives the condition for the cube path: 'submit only after the advice proved itself.' It also excludes a plausible-but-wrong expectation with 'Does not run the advice.' No explicit precondition that consult_id must come from a prior `consult` call.

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 load and does well: it discloses the read semantics via the GET endpoint and describes the return shape (old and new versions in full, per-field diff, with hooks_changed and skill_md_changed reported separately). It omits auth/permission needs and rate limits, which keeps it below a 5.

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 dense sentences, front-loaded with the resource and endpoint, with no filler. The terse arrow/underscore notation is efficient but slightly cryptic for a first-time reader.

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 does a solid job covering return structure and how to interpret the diff fields. Remaining gaps are permission requirements and the slight mismatch between the endpoint's {id} and the input fix_id, which is only loosely reconciled.

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% with one parameter, so the description must compensate; it does so by explaining fix_id=0 means all pending cases. It doesn't explicitly define nonzero fix_id values, but the single-param surface and the clear zero-case semantics make the meaning derivable.

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 the specific resource (a court case for a new cube version or fix) and pairs it with the concrete endpoint GET /court/case/{id}, so it is unambiguously a read of case records. It does not explicitly contrast with the sibling court_removal_request, keeping it from 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?

"fix_id=0 -> all pending cases" gives a useful condition for the all-cases mode, and "Judge from both" tells the agent how to consume the output. However, it never states when to call this versus court_removal_request or the cube_* tools, so the usage guidance is implied rather 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. It usefully discloses that published cubes are permanent public property and that there is no author retract path, plus a 10+ character reason requirement. However, it does not explain what the court does with the request, what a successful request produces, authentication requirements, or whether the request is public or reviewable.

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

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

The description is tightly front-loaded: action and endpoint first, then the critical permanence constraint, then parameter semantics. Every clause carries useful information with no filler.

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

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

For a no-annotation, no-output-schema mutation/request tool, the description covers invocation well: endpoint, grounds, reason format, and the no-retract constraint. It is incomplete regarding the court process and what the agent should expect after submitting, which matters for a request that initiates a legal action.

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 defines the full ground enum (personal_data | secret | harmful | illegal | legal_claim) and clarifies that reason should state 'what exactly' with a 10+ character minimum. cube_id is not described, but its meaning is self-evident.

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 — 'Ask the court to remove a published cube' — and the endpoint reinforces the action. It also distinguishes this from direct author retraction by noting that published cubes are permanent public property with no author retract.

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 clear context for when this tool is appropriate: published cubes cannot be retracted by the author, so removal must go through the court. It also enumerates valid grounds. It stops short of explicitly naming when-not-to-use or comparing against alternatives like court_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 carries the full burden and does disclose the key behavioral trait: this is a stateful publish gated on a prior status check, with an ordering constraint tied to the user's next message. It does not state failure behavior, idempotency, or whether repeated publishes are safe, which is a real gap 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?

Front-loaded with the verb and endpoint, then parameters, then the status vocabulary, then the gating rule — a logical order with no filler. The parenthetical status glosses are dense but each carries a distinct instruction, and nothing is redundant enough to penalize heavily.

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 2-param tool with no annotations and no output schema, it covers the workflow and return-state vocabulary reasonably. However, it never explains how this consent gate relates to sibling action tools (cube_create, cube_vote), which is the main ambiguity an agent would face when deciding whether and when to invoke it.

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 fully compensates: it defines action=status|notice_shown and explains msg_ref as 'id of the current user message (e.g. t648u)' with a concrete example. It does not say whether msg_ref is required for each action, nor mention that action defaults to status, so it is not a 5.

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 concrete verb and resource ('Publish consent') plus the backing endpoint (POST /cube/consent), and enumerates the two action modes (status, notice_shown), so an agent knows exactly what the tool does. It does not differentiate itself from siblings such as cube_create or cube_vote, which keeps it out of 5 territory.

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 conditional guidance: call notice_shown when status=notice_required, and 'publish only after the user's next message' when status=notice_pending, plus the hard rule 'Publish only when status=allowed'. What it lacks is any reference to alternative tools or what to do on error/unknown, so it stops short of full when/when-not coverage.

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 disclosure burden. It implies a write plus sharing ('shared experience cube') but never states who sees the cube, that cube_publish defaults to true (a real side effect), how supersedes/cube_id rebinding behaves, or whether creation is idempotent. For a mutating, publishing tool this is a significant 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?

It is a single compact sentence with the required-field list front-loaded, so there is little waste. But the compression comes at the cost of clarity: 'DUTY at task end' and 'send duty=cube_nothing' are dense internal shorthand that force the agent to guess.

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 12 parameters, no annotations, no output schema and 0% schema coverage, the description is far too thin to let an agent call this correctly. It never explains what a cube is, what the optional fields change, or what publishing means, leaving the majority of the call surface undocumented.

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% across 12 parameters, so the description must compensate and largely doesn't. It mentions topic, essence, rules, skill_md, hooks and carrier but explains none of them, and omits kind, cube_id, msg_ref, evidence, supersedes and cube_publish entirely — including the publish flag, which materially changes the tool's effect.

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 verb (create) and a resource (shared experience cube) and lists the three required fields, so the basic action is recoverable. However, 'cube' is unexplained jargon and nothing distinguishes this from sibling tools like cube_install or cube_link, so an agent cannot confidently tell which creation path applies. 'DUTY at task end' adds ambiguity rather than 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?

It does state a trigger ('at task end') and gestures at an alternative ('send duty=cube_nothing'), which is more than most descriptions offer. But the alternative is phrased in an internal vocabulary that is never explained, and there is no guidance on when to use cube_create versus cube_install or cube_link.

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, and it says nothing about whether 'open' is read-only or mutates state (e.g. marks the cube as opened, creates a session, requires consent given cube_consent exists as a sibling). No permission, side-effect, or error behavior 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 single short sentence is front-loaded and free of padding, but it is under-specified rather than concise: the brevity removes information an agent needs instead of removing waste.

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

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

With no annotations, no output schema, and no documented parameters, the description is the only source of behavior and it supplies essentially none. For a tool whose verb is ambiguous within a large sibling set, far more disclosure is required.

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% for the single required parameter cube_id. The phrase 'by id' only confirms that cube_id identifies the cube — it adds no format, source, or lookup guidance (e.g. where to obtain the id, whether it is the same id returned by cube_search).

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 resource (a cube) and a specific operation (open it, by id), so an agent can tell it apart from cube_create or cube_search at a rough level. But 'open' is not a well-defined verb — it could mean retrieve, activate, join, or establish a session — so the actual purpose stays vague.

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 statement of when to use this tool versus cube_search (to find a cube), cube_create (to make one), or cube_install, even though those siblings occupy adjacent semantic space. The agent must infer usage from the name 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, the description carries the full burden. It discloses a genuinely important behavior — the call is refused unless the user has explicitly confirmed — which is real value. But it says nothing about what installation changes, whether it is reversible, what permissions are required, or what happens on a partially-satisfied confirmation.

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 immediately followed by the gating condition; nothing is padded. The telegraphic "otherwise refused" is slightly cryptic but does not waste space.

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 gating protocol is covered, but for a no-annotation, no-output-schema mutation tool the definition omits the effect of the operation, failure modes beyond refusal, and the role of two of its four parameters. It is adequate to avoid an obvious misuse but not complete enough to call confidently.

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

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

Schema coverage is 0% across four parameters. The description explains only user_confirmed (and implies the turn-based evidence protocol), leaving user_quote and user_said_install completely undefined in both schema and prose — an agent cannot tell whether these are evidence artifacts it must populate or optional audit fields. Only cube_id is self-evident.

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?

"Install a cube" names a verb and resource, but it largely restates the tool name and does not explain what installing a cube actually does (vs. cube_create or cube_consent, both present in the sibling list). An agent still has to guess at the semantic difference between creating, consenting to, and installing a cube.

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 conditional "user_confirmed=true ONLY after the user's explicit yes in this turn" gives a concrete precondition, and "call turn(user_message) first" names a prerequisite step. However, it gives no guidance on when to prefer cube_install over cube_create or cube_consent, so tool selection among siblings is left 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 provided, so the description carries the full burden of behavioral disclosure, and it discloses nothing. It does not say whether linking is a write/mutation, whether it is reversible, whether it requires permissions or a consent step, whether it creates an implicit relationship object, or what it 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?

A single sentence, but brevity here is under-specification rather than economy — there is no waste because there is almost no content. Nothing is front-loaded beyond the tautological restatement.

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?

Three parameters, zero schema descriptions, no annotations, and no output schema; the description supplies none of the missing context. For a domain-specific relational tool that mutates state, this is wholly inadequate to 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?

Schema description coverage is 0%, so the description must compensate entirely and does not. "Two cubes" faintly maps to src/dst, but neither is described (ID? name? path?), and the third parameter `kind` with default "progress" is completely unaddressed, leaving the agent to guess at the meaning of the most important discriminator.

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?

"Link two cubes" restates the tool name (cube_link) almost verbatim and never defines what a "link" is in this domain. It gives no signal for distinguishing it from cube_create, cube_install, cube_consent, or cube_vote, all of which plausibly operate on cubes.

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, no prerequisites (does linking require consent? a prior cube_create?), and no mention of any sibling as an alternative. An agent has no basis for choosing cube_link over the other nine cube_* 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, but it does disclose two real behavioral traits: results are relevance-ranked and only latest versions are returned, which affects expectations about ordering and duplicates. It says nothing about permissions, consent requirements, result caps, or pagination — notable gaps for a search 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?

A single tight sentence with the resource first and the behavioral qualifiers parenthesized — no waste and front-loaded. It is efficient rather than padded, though its brevity is part of why other dimensions suffer.

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?

No annotations, no output schema, and three undocumented parameters leave the definition thin. The description doesn't convey result shape, ranking explanation, or how the two boolean filters change the result set — an agent could call it but not confidently configure it.

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, and it largely doesn't. 'Shared' hints at the community/exclusion scope but neither exclude_own nor community_only is explained, and the query semantics (matching behavior, syntax) are left entirely to guesswork.

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 verb (Search) and resource (shared cubes) and adds scope qualifiers — relevance-ranked, latest versions only — that separate it from cube_get (fetch by id) and cube_create. It doesn't name a sibling explicitly, so it stops short of a 5.

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

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

No when-to-use or when-not-to-use guidance is given. The agent must infer that this is the discovery path when it lacks a cube id and that cube_get is the retrieval path, and nothing tells it when exclude_own or community_only should be set.

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 real weight: it discloses the 403 failure mode for self-voting and that fix_* fields trigger an edit proposal rather than a plain vote — a non-obvious side effect. It stops short of covering vote reversibility/idempotency or the response shape, so not a 5.

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 prefixed with 'DUTY' with no filler. The arrow shorthand ('403 -> feedback_submit instead') is compact but slightly telegraphic for an unannotated 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 an 8-parameter mutation tool with no annotations, no output schema and no schema descriptions, the description covers the critical behaviors (eligibility, failure routing, edit proposal) but leaves parameter-level detail and the return/refusal contract underspecified. Adequate, 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 coverage is 0% across 8 params, so the description must compensate. It does explain vote values (+1/-1, which the schema does not encode as an enum), the reason requirement for -1, and that fix_* fields propose an edit, but 'topic' and the distinct meanings of fix_hooks/fix_rules/fix_essence/fix_skill_md are left unstated.

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 verb and direction ('vote +1/-1') against a specific resource ('cubes'), plus the eligibility scope (cubes you opened/installed/used). It also explicitly contrasts with the sibling feedback_submit, so an agent can distinguish the two without inspecting schemas.

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 when-to-use (cubes you opened/installed/used), when-not (own cubes, which yields 403) and the correct alternative in that case (feedback_submit). It also states a precondition on the payload: a -1 requires a reason.

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, and it discloses almost nothing: no indication of whether the report is publicly visible, whether it notifies maintainers, whether resubmission duplicates, or what a successful call returns. The only behavioral facts given (description required, title optional) duplicate the schema.

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

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

A single compact line with the resource and the required-field note front-loaded; no filler. It is arguably over-compressed rather than padded, but nothing in it is wasted.

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 six parameters, no annotations, and no output schema, the description should say what happens on submission and how to choose a type or severity. It leaves the agent guessing about the outcome of a mutation call and about the meaning of the unconstrained enum-less 'type' field.

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 type, title, cube_id, event_id, severity, and description. The parenthetical adds only that description is required and title defaults from it, which restates schema content rather than adding syntax or selection guidance. Baseline 3 is appropriate.

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

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

The description names the resource (a feedback/bug report on SKV or a cube) and, via the tool name, the action (submit). An agent can tell this creates a feedback record rather than reading or acting on boards/cubes, and no sibling tool overlaps with feedback capture. It falls short of 5 because the fragment omits the verb and never states what submission actually does.

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

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

There is no guidance on when to use this instead of, say, board_act, court_case, or memory_event for reporting a problem. Nothing explains which of the four type values (bug | proposal | improvement | anomaly) an agent should pick in a given situation, so selection is left entirely 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, the description carries the full behavioral burden and does usefully disclose that create/accept issue a new project key shown once, and that only data saved under that key is shared. It still omits auth requirements, what close/leave actually do, and error or irreversibility 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 two dense sentences: the purpose and action inventory come first, followed by the key sharing behavior. The action list is compact and every clause adds functional 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 multi-action tool with no annotations and no output schema, the description covers actions and key sharing but does not explain return values for list, invites, or other actions. It is adequate to begin calling the tool but leaves meaningful gaps around outputs and operational constraints.

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, and it does by mapping actions to parameters: create(title), invite(project_id, email), accept(project_id), info(project_id), revoke(project_id, email), leave(project_id), close(project_id). It still does not explain formats or constraints for email, project_id, or title.

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 resource, 'joint project memory for 2-5 people,' and enumerates the actions available. It does not explicitly differentiate itself from siblings like joint_search or memory_search, but the purpose is clear from the action list.

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

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

The action list implies when each operation would be used, and inline parameter hints clarify which arguments attach to which action. However, there is no explicit guidance on when to choose this tool versus alternatives such as joint_search, nor any stated exclusions or prerequisites.

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 a decent job: it discloses the read scope ('only project lines of active members are read') and a non-obvious side effect ('every search is audited and visible to members'). It also specifies the return token format and citation convention. It omits whether a missing/invalid key errors out or how access to the key is obtained.

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 tight sentences, front-loaded with the action and its precondition, followed by the output/citation format. Every sentence carries information; nothing is padded.

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

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

With no output schema, the description usefully explains the return token shape and citation rule, which is the most valuable thing it could add. But it is silent on the `limit` parameter and on how the required project key is supplied or what happens when it is absent, leaving real gaps for a search tool.

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

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

Schema description coverage is 0% for both parameters. The description explains nothing about the required `query` (matching behavior, syntax) and never mentions `limit` (default 8), so an agent gets no signal about result-size control. The 'project key' it does discuss is not even an input parameter here, leaving the actual parameters undocumented everywhere.

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 verb+resource: 'Search the joint project memory', which is distinguishable from the generic memory_search and cube_search siblings by the 'joint project' scope. It does not explicitly name the sibling it supersedes, but the resource qualifier makes the domain clear.

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 parenthetical '(only with a project key)' gives a hard prerequisite, which is useful gating guidance. However, it never states when to prefer this over memory_search, cube_search, or joint_project, so the agent must infer the routing itself.

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 valuable behavior: it scans all history including L2/L1 summaries, returns summaries plus events with ev ids, and opens the episode around an event. It never states that this is a read-only operation, nor anything about result volume, ordering, or cost of a full-history scan.

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?

Front-loaded with 'Dig deeper' and organized as three semicolon-delimited modes ending in a memorable directive; nearly every clause carries information. It is dense and slightly run-on, but not padded.

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

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

For a 7-parameter tool with no annotations and no output schema, the three main invocation modes are well covered but the remaining parameters are opaque — an agent cannot tell whether since/until filter by time, what radius measures, or what exclude_imports suppresses. That gap matters for a tool described as scanning 'all history'.

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, and it does explain query, focus_id (with accepted value formats) and focus_event_id. However, since, until, radius and exclude_imports — four of seven parameters — receive no explanation anywhere, leaving the compensation only partial.

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 breaks the tool into three explicit modes (query scan, focus_id open, focus_event_id episode) with concrete id namespaces (l1:/l2:/crit:/board:/ev), so an agent knows exactly what it retrieves. 'Dig deeper' implies contrast with memory_search, but no sibling is named outright, keeping it short of a 5.

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

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

'Use before saying you do not remember' is a clear, actionable trigger, and the per-mode parameter descriptions imply which call to make when. There is no explicit when-not guidance or named alternative (e.g., memory_search for shallow lookups), so it stops at 4.

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. 'Open ... in full' usefully signals a complete-record read rather than a summary, but nothing is said about missing-id behavior, permissions, or what an 'event' 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?

One short sentence with the key modifier ('in full') up front and zero filler. Appropriately sized for a one-parameter lookup, though it is terse to the point of under-specification.

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 trivial single-id read with no output schema, the description covers the core intent (retrieve the full event by id). It leaves gaps on what distinguishes 'an event' from other memory artifacts and on failure behavior for unknown ids.

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?

Single required parameter with 0% schema description coverage. 'by id' tells the agent the argument identifies a specific event, but gives no format, source, or provenance hint (e.g. where ids come from).

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 verb+resource ('Open one memory event') and adds scope with 'in full by id', which distinguishes it from listing-style siblings like memory_search and memory_dig that presumably return summaries. Differentiation is implied rather than explicit, so it stops short of 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?

'by id' and 'in full' imply this is the follow-up call after a search that returned ids, but no sibling is named and there is no explicit when/when-not guidance. Usage is inferable rather than 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, the description carries the full behavioral burden. It discloses ordering, conflict handling via superseded_by, and per-hit timing, but omits whether this is read-only, how pagination works despite offset/top_k, what filters like source/mode do, and what the result shape is.

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 and front-loaded, but it is too compressed for a 9-parameter search tool. Fragments like 'Prefer turn' and 'time per hit' are cryptic rather than efficient, so the brevity comes at the cost of clarity.

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 9 parameters, 0% schema description coverage, no annotations, and no output schema, so the description must do much more. It supplies some behavioral context but leaves most parameter behavior and result interpretation undocumented.

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 explains none of the 9 parameters. Terms like 'newest first' and 'time per hit' do not map clearly to query, mode, lines, since, until, top_k, offset, source, or exclude_imports.

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 ('Search memory') and adds useful scope details: newest-first ordering, superseded_by marking for conflicting facts, and per-hit timing. It also distinguishes itself from memory_event by routing full-text retrieval there, though the sibling routing is compressed.

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 names alternatives ('Prefer turn', 'Full text: memory_event') but gives no explicit conditions for when to choose this tool over turn or memory_event. The guidance is implied rather than actionable, leaving the agent to infer the selection criteria.

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. It discloses that the result includes a consent question, rule 0, essentials, and recent memory, but says nothing about read-only vs. side effects, permissions, idempotency, or interaction with the user beyond the phrase 'consent question'. This is insufficient for an unannotated 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 short sentences, front-loads the key condition ('STEP 0 before install'), and wastes no words. The telegraphic style ('consent question + rule 0 + essentials + recent memory') is compact but slightly cryptic, which keeps it from 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?

Given four undocumented parameters, no annotations, and no output schema, the description is too sparse to let an agent call the tool correctly. It explains the when but not the how, leaving parameter usage and return behavior entirely undisclosed.

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 4 parameters with 0% description coverage (page, query, detail, session_id), and the description does not explain any of them. An agent receives no guidance on what these parameters mean or how to use them.

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 identifies this as the pre-install onboarding step that returns consent, rule 0, essentials, and recent memory, and explicitly distinguishes it from step_zero for post-install use. However, it uses telegraphic phrasing ('STEP 0') rather than a clear verb+resource statement, leaving the exact operation somewhat vague.

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 condition ('before install') and names the alternative sibling for the opposite state ('Once installed use step_zero'). The only gap is that it does not address other memory-related siblings like memory_search or memory_dig, but the primary routing decision 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 full burden and does well: it discloses the isolation model (no network, no host), execution limits (15 s, 256 MB), and rate limit (10 runs/min), all of which an agent needs before invoking. It omits what happens on timeout/limit breach and whether the sandbox state persists across calls.

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 dense line with everything front-loaded: action, constraints, return fields, purpose, rate limit. No sentence is wasted and the most decision-relevant facts come first.

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?

No output schema exists, yet the description names the return fields (stdout, stderr, exit_code), and no annotations exist, yet it covers isolation and limits. The one real hole is the undocumented `files` parameter, which is not offset anywhere else.

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 implicitly enumerates the valid `language` values (python/pytest/node) and `code` is self-evident, but the `files` parameter is never mentioned at all — an agent cannot tell whether it writes files into the sandbox, mounts them, or returns them.

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 verb and resource: run python/pytest/node code in an isolated sandbox, with the isolation constraints spelled out inline. It is unmistakable against all siblings (cube/board/memory tools), though it never explicitly names an alternative it is not.

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?

"For cube tests and snippets" implies the intended context, but there is no explicit when-not guidance, no statement about what to do if the code needs network access, and no alternative tool suggested when the sandbox is 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?

With no annotations, the description carries the full burden. It does disclose the pagination contract ('page=1..N until done=true'), which is genuinely useful behavioral information since no output schema exists to reveal the done flag. It does not state that the operation is a read with no side effects, nor anything about payload size or ordering, leaving gaps for a zero-annotation 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?

A single dense sentence, front-loaded with the trigger condition and followed by the payload and the loop rule. Nothing is wasted, though the telegraphic phrasing ('full constitution + memory + last session') reads like shorthand rather than a complete sentence, which slightly raises parsing effort.

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 bootstrap tool with no output schema, this covers the essential contract: what triggers it, what it returns at a high level, and how to iterate to completion. The absence of an output schema means the 'done' flag and payload shape are undocumented elsewhere, and the description only partially fills that gap, but the critical calling guidance is present.

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 'page' parameter, so the description must compensate, and it does: 'page=1..N until done=true' explains both the iteration range and the termination condition. This is meaningfully more than the bare integer schema provides. It stops short of saying whether page numbering is 1-based by default (schema shows default 1) or what happens past the last page.

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 the payload ('full constitution + memory + last session') and its trigger point, which lets an agent infer this is a bundled bootstrap fetch rather than a single-resource get. However, no verb is stated (retrieve? load? assemble?), so the action itself is left implicit. It is distinguishable from siblings like constitution_get and memory_search only by inference from the union of resources.

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?

Timing is explicit and unambiguous: 'after install, and at every session start when installed.' That answers the when-to-use question decisively. It does not name alternatives for cases where the agent only needs the constitution or only memory (constitution_get, memory_search), which keeps it from 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 burden and delivers real behavioral facts: the server does not judge the draft, it only validates that each [ev:id] exists (otherwise verdict=revise + invalid_ids and nothing is saved), the turn is saved and a seal is returned to append as the last line. Remaining gaps are the format/meaning of the 'seal' and the shape of the returned self_check list, which are left unexplained.

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 ordering is sensible (workflow first, then compact mode, then memory digging), but the prose is a single dense run-on with invented shorthand and an untranslated Russian word ('вспомни'), forcing the agent to parse rather than read. Several clauses could be split or moved to a note without losing 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?

For a 21-parameter, no-annotation, no-output-schema tool, it covers the main workflow and the failure path but is thin on how the many optional state fields (duty, profile, task_done, l1/l2 summaries, second_look) interact with the save/seal cycle. It is adequate to call the tool in the common case but incomplete for the richer modes it implies.

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% across 21 parameters, yet the description only explains compact, draft, answer (as a draft alias), lines, and user_message indirectly — roughly a quarter of the surface. It also references a 'offset' parameter that does not exist in the schema, and leaves duty, query, profile, critical, event_id, sensitive, task_done, l1_summary, l2_summary, msg_ref, session_id, second_look, draft_summary, profile_review, and source_event_ids entirely undefined.

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?

It names a concrete action (submit the user message plus draft each turn and receive memory facts, cubes, and a self-check list) and contrasts the role with named siblings (memory_search, memory_event, memory_dig). The jargon 'cubes', 'self_check', 'seal' is never defined, so the resource it returns is only partly clear despite the distinctive verb.

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 states the timing explicitly ('EVERY TURN, ONE CALL... before the user sees the reply'), covers the no-draft case ('No draft = context only'), and routes the agent to the correct alternatives before declaring it does not remember ('memory_search by meaning and by keywords... memory_event... memory_dig'). The when-to-use, when-to-skip, and alternative-tool paths are all present.

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 and does disclose key traits: server-side substitution, sending the request, returning status/scrubbed body, and never returning the secret. It omits important context such as permissions, error behavior, and side effects of the outbound request.

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, and free of filler. Each sentence adds operational information about substitution, sending, and return 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?

The description covers the central mechanism and return safety, but for a tool with five undocumented parameters, no annotations, and no output schema, it leaves gaps around method defaulting, body semantics, purpose meaning, and request error behavior.

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 only partially explains name usage via [vault:name] and notes that purpose is required. It does not explain method, body versus url handling, or what purpose semantically represents.

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 explains that this tool substitutes a vault secret into an HTTP request and sends it, returning status and a scrubbed body. It is specific about the core mechanism and return behavior, though the verb 'Use' is less precise than a dedicated operation name.

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 it by telling the caller to put [vault:name] in url or body when a secret must not be exposed. However, it does not explicitly compare against alternatives or state when not to use it.

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