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

Annotations only declare readOnlyHint=false, leaving the description to explain behavior. It adds that there are five sequential gates and automatic invocation within fraggate_call, but it never says what the gates do, whether the proposal is modified, or what happens on failure.

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-loads the main function, but 'Freedom without clarity is chaos' is philosophical filler that does not help an agent invoke the tool. The useful information is concise but mixed with non-functional text.

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 optional parameters, no output schema, and minimal annotations, the description is too sparse. It omits return behavior, gate semantics, parameter requirements, and side effects, leaving an agent without enough context to call the tool 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 description coverage is 0% and the description does not mention any of the six parameters: values, evidence, statement, impact_neg, impact_pos, and accountable. The word 'proposal' gives loose context, but no parameter is explained or mapped to the tool's behavior.

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 the tool runs DecisionGATE as 'five sequential gates on a proposal' and notes it also runs inside fraggate_call, giving a clear action and resource. It doesn't fully differentiate from sibling gate tools, but the core function is identifiable.

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

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

The description implies usage by noting DecisionGATE 'runs automatically inside fraggate_call before exec,' which hints that direct invocation is for standalone gating. However, it provides no explicit when-to-use guidance or exclusions relative to siblings like fraggate_verify or fraggate_list.

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?

Without rich annotations, the description discloses a full behavior chain: DecisionGATE evaluation, possible refusal, ResultEnvelope plus ledger tip, and the exact FG-HALLUC-TOOL refusal for unknown names. It does not detail side effects or authorization, but it is far more transparent than a bare mutate verb.

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 pipeline notation front-loads the flow and the second sentence packs parameter and error behavior compactly. It is concise and scannable, though slightly cryptic due to the arrow notation.

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

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

For a 5-parameter tool with no output schema, the description provides enough to attempt a basic call (op/payload/name/slug) and explains refusal, but it leaves ambiguity about whether name/slug is required given the schema marks only op required, and it does not describe the ResultEnvelope or ledger tip 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?

Schema already documents op, name, and claim; the description adds that name/slug are alternatives and that payload is passed, and clarifies claim is optional. With 60% schema coverage, this is helpful but does not fully define payload, slug, or the DecisionGATE proposal structure beyond the schema's field list.

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 action—passing a CallEnvelope into FragGate for a handler to process or refuse—and states the result (ResultEnvelope + ledger tip). It clearly implies execution rather than listing or describing registry entries, though it does not explicitly name a sibling to differentiate from.

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 operational guidance ('Pass name/slug, op, payload', 'Optional claim ... Default exec path') and warns that unknown names refuse, but it never states when to choose fraggate_call over siblings like fraggate_verify, fraggate_describe, or runtime_run. Usage is implied rather than explicitly contrasted.

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

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

Annotations already carry readOnlyHint=true and openWorldHint=false, and the description's 'Describe' verb is consistent with those, so there is no contradiction. The description adds value by disclosing what the describe output covers (type classification, public ops, digest), but it does not cover error behavior or edge cases such as unknown names.

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 zero waste; the core purpose and output categories are front-loaded, followed by the single invocation note. Every phrase 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?

For a simple read-only tool with no output schema, the description compensates by listing the return categories (live/stub/local_only, public ops, digest). It is slightly incomplete on what 'public ops' means and what happens for unrecognized names, but these are minor gaps given the tool's low complexity.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does provide the key disambiguation: 'Argument: name or slug' tells the agent the two parameters are alternatives. However, it gives no format guidance or examples for what constitutes a valid name versus a slug, leaving the agent 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?

The description states a specific verb ('Describe'), a specific resource ('one catalog name'), and enumerates the returned information ('live vs stub vs local_only, public ops, digest'). It implicitly distinguishes from siblings like fraggate_list by scoping to a single name, though it never names an alternative explicitly.

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 singular scope ('one catalog name') implies this is for inspecting a single registry entry rather than listing, verifying, or calling, but there is no explicit when-to-use guidance or mention of alternatives. The 'Argument: name or slug' note is invocation detail, not usage selection guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful behavior context by defining the entry categories, noting entries are hashed, and warning 'Do not invent tools,' which reinforces that the listed names are authoritative. No contradiction with annotations.

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

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

The description is three short sentences plus a reference URL, front-loads the primary action and scope, and contains no filler. The 'Do not invent tools' warning earns its place, and the kernel URL is compact optional 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?

For a parameterless list tool with no output schema, the description is largely complete: it names the resource, categories, and purpose. It does not detail the exact response shape, but 'List...entries' and 'Discover names' sufficiently convey what the agent will get from a simple registry listing.

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

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

There are zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description does not need to document parameters; it also correctly implies no arguments are needed to list the registry.

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 resource ('hashed registry entries') and distinguishes the action from siblings like fraggate_describe, fraggate_verify, and fraggate_call. It also states the entry categories (live/stub/local_only), leaving no ambiguity about what is listed.

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?

'Discover names' provides clear context for when to call this tool: when the agent needs to know what registry entries exist. It does not name alternatives or explicitly say when not to use it, but with zero parameters and a simple list purpose, the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, so the read-only safety profile is covered by structured data. The description adds one behavioral detail — the registry is 'hashed' — implying matches are validated against stored hashes. However, it does not disclose the output shape, whether matching is exact/fuzzy, or what happens on a failed match. With annotations present, the bar is lower, and the description provides marginal but real added context; a 3 is appropriate.

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 15-word sentence with the verb front-loaded and zero filler. The 'hashed FragGate registry' qualifier earns its place by scoping the verification target. Nothing in the description is redundant with the title or annotations.

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

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

For a tool with three undocumented optional parameters, no output schema, and several closely related siblings, the description is too thin. An agent lacks: the return shape, the meaning of 'slug', how parameters combine, and when this tool is preferable to fraggate_describe. The readOnly annotation covers safety but not the operational semantics an agent needs to invoke this 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 fully. It does clarify that 'name' and 'digest' are identifier types being checked against the registry, but it never mentions the 'slug' parameter at all, and it gives no hint about how the three optional parameters relate (alternatives? AND? priority?). additionalProperties: true further widens the ambiguity. The description covers two of three params without relational semantics, which is insufficient at 0% schema coverage.

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

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

The description uses a specific verb ('confirm') with a defined resource ('a name or digest against the hashed FragGate registry'), so an agent can tell this performs an existence/authenticity check rather than enumeration or inspection. It is not tautological and adds the meaningful 'hashed' qualifier. It loses one point because it never states what a verification returns (boolean vs. details) and doesn't explicitly distinguish itself from fraggate_describe.

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 whatsoever about when to use this tool versus fraggate_list, fraggate_describe, or fraggate_call. The description neither states a triggering condition nor names alternatives. Given a sibling set full of registry tools, the agent is left to guess whether verification is for CI checks, pre-call validation, or ad-hoc lookups.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only' and adds the corpus scope and the exclusion of private-file searches. It does not disclose further behaviors like authentication, rate limits, or return format, but the bar is lowered by the annotations.

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

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

Two short sentences, front-loaded with the read-only nature and scope. No filler; every phrase adds 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?

The description is adequate for a simple read-only lookup but leaves the meaning of 'example' and 'skill' modes undefined and does not mention what the response contains or how q behaves across modes. Given no output schema, an agent gets only partial guidance.

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 documents op values ('search (default), example, or skill') and the description repeats that mapping with 'aziel-corpus search / example / skill'. The q parameter remains undocumented in both schema and description; only the tool name and 'lookup' imply it is a query string. 50% coverage leaves room for more.

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 clear verb and resource: 'Read-only library lookup' of the Aziel Digital Library, with explicit scope (aziel-corpus search/example/skill). The negative clause 'Not a private-file search engine' adds a boundary, though it does not explicitly differentiate from sibling tools like runtime_skill.

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?

Implies usage for aziel-corpus lookups and excludes private-file searches, but provides no explicit when-to-use comparisons or alternatives among the sibling tools. The guidance is inferred 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?

The annotations already provide readOnlyHint=true and openWorldHint=false, so the safety and closed-world nature are covered. The description adds scope ('every product') and intended audience ('human/catalog helper'), but it does not describe return shape, ordering, or other runtime behavior beyond what the title and annotations imply. No contradiction exists, but the added behavioral detail is modest.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded in the first sentence, and the routing guidance is delivered as a clear, separate second sentence. 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?

For a zero-parameter, read-only list tool, this description is complete enough for an agent to select and invoke it correctly. It states the scope, identifies the intended audience, and explicitly points to the alternative for agent-facing use. With no required arguments and annotations covering safety, nothing critical is missing for 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?

There are zero specified parameters and zero required parameters, so the description has no parameter burden to carry. The schema is fully covered with no defined properties, and the baseline for zero-parameter tools is 4; nothing in the description is missing on this front.

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 starts with a specific verb and resource: 'List every Aziel Eliab product,' and it identifies itself as a 'human/catalog helper,' which separates it from its sibling tools. It also explicitly names fraggate_list as the alternative, so an agent can distinguish the tools 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?

The sentence 'Prefer fraggate_list for the agent door' explicitly tells the agent when not to use this tool and which sibling to prefer instead. The 'human/catalog helper' label establishes the intended context, making the routing guidance direct rather than implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context that this is an advanced/internal tool and not the default path, but it does not disclose additional behavioral traits such as output shape, pagination, or failure behavior. This is adequate given the low complexity and annotation coverage.

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 the most important information: the tool is advanced/internal and returns a machine manifest with specific fields. The routing guidance and default-path warning are packed into two additional clauses 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 parameterless, read-only tool with no output schema, the description provides the essential invocation context: what the manifest contains and when to avoid this tool. It does not explain terms like 'door=fraggate' or 'engine slugs,' but for an advanced/internal tool this is likely sufficient for the intended audience.

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

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

There are zero parameters and a vacuous 100% schema description coverage, so the baseline of 4 applies. The description mentions the manifest fields, which is enough context for a no-argument call.

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 as a machine manifest and enumerates its contents (version, role, door=fraggate, engine slugs). It does not use a direct verb like 'get' or 'list,' and the distinction from runtime_skill/fraggate_list is more about routing than function, 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?

It gives explicit alternatives ('Prefer runtime_skill or fraggate_list') and warns this is not the default agent path, which tells an agent when not to use it. However, the positive condition for when runtime_manifest should be chosen is only vaguely implied by '[advanced/internal]', not explicitly stated.

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

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

The readOnlyHint annotation already establishes this as a safe read operation, so the description's main job is to add what the tool exposes. It does that by listing the returned aspects (name, version, skill, download, ops), which is useful given there is no output schema. It does not address error behavior or return format, but the annotation lowers the burden here.

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, with the core action and parameter stated first. The trailing 'Argument: slug' is slightly redundant with the input schema, but the overall wording is efficient and has 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 simple read-only tool with one parameter, the description provides a workable level of context: the identifying parameter and the main fields returned. However, it leaves some ambiguity around terms like 'ops' and gives no indication of what happens when the slug is not found, so it is adequate but not 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?

Schema coverage is 0%, so the description must carry the meaning of the slug parameter. It does indicate that slug is the lookup key for identifying one product, which is the minimum needed for a single required string parameter. It does not provide slug format, constraints, or examples, but the simple one-parameter case is adequately served.

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 action ('Open') and resource ('one product'), and specifies the identifying key (slug) and the facets returned (name, version, skill, download, ops). It is distinct enough from the sibling runtime_* tools, though it does not explicitly name an alternative.

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 usage context is implied: an agent should call this when it needs to open a product by slug. However, there is no explicit guidance on when to prefer this over closely related siblings such as runtime_run, runtime_manifest, or runtime_session_open, and no exclusions are 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?

Annotations already declare readOnlyHint=false. The description adds governance-related behavior: it is 'DecisionGATE-admitted' and 'not a backdoor,' meaning it is still subject to policy checks. This is useful context but does not disclose side effects, state changes, or error behavior beyond the annotation.

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—two sentences with no filler. It front-loads the '[advanced/internal]' label and the core governance message. Brevity is achieved, though at the cost of semantic 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?

With four parameters, no output schema, no parameter documentation, and no description of return values or failure modes, the description is severely incomplete. An agent cannot construct a correct invocation or understand the tool's behavior from this text alone.

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 makes no mention of slug, op, payload, or session_id. There is no explanation of what these parameters mean, how they relate to the execution, or what valid values look like. The agent is left entirely to infer parameter semantics from names alone.

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 labels the tool an 'Advanced exec façade' but never states what it executes, what resource it operates on, or what outcome it produces. The phrase 'raw runtime_run' largely restates the tool's name, and while it distinguishes itself from fraggate_call, it fails to define its actual function.

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

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

The description explicitly says 'Prefer fraggate_call,' which gives an alternative and a clear preference. The '[advanced/internal]' tag signals restricted usage context, and 'not a backdoor past the door' clarifies it should not be used to bypass governance. However, it does not specify exactly when an agent should choose this over its 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?

The annotations only indicate readOnlyHint=false, so the description carries the burden of behavioral disclosure. It states that sealing blocks further exec, which is a useful effect. However, it does not disclose whether the action is reversible, whether special permissions are required, or what happens to the session object. For an 'advanced/internal' tool, more transparency about side effects and irreversibility would be expected.

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 a bracketed tag, front-loading the action and its effect. There is no filler or redundancy; every word contributes to understanding the tool's purpose and usage. The structure is efficient and easy to parse.

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 one required parameter, no output schema, and minimal annotations, the description needs to cover parameter semantics, return behavior, and any caveats. It explains the action and usage preference but omits what session_id means, what the tool returns (if anything), and clarifies the meaning of 'raw session.' For an advanced tool, this is a significant gap that could lead to misuse.

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

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

The input schema provides zero description for session_id (coverage 0%), and the description does not mention the parameter at all. It gives no indication of what session_id refers to, how to obtain it, or its format. The description focuses entirely on the action, leaving the sole parameter completely ambiguous and forcing the agent to guess from the parameter name alone.

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

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

The description clearly states the action ('Seal a raw session') and its immediate effect ('Further exec is rejected'). This is a specific verb+resource combination that distinguishes it from sibling tools like runtime_session_open, runtime_session_exec, and runtime_session_receipt, all of which have different purposes.

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

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

The description provides explicit guidance: 'Prefer leaving sessions to expire unless the user asked to close.' This tells the agent when to use the tool (only when explicitly requested) and implies the default alternative (letting sessions expire naturally). While it doesn't name specific sibling tools, the condition is clear and actionable.

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

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

Annotations only indicate readOnlyHint=false and openWorldHint=false, so the description carries the burden of disclosing side effects, security behavior, and operational details. It mentions 'FragGate-admitted on the MCP path' and 'Binding-only ops stay per-op proxy_fallback,' but these phrases are too jargon-heavy to be transparent to an agent. No clear explanation of mutation risks, permissions, or failure behavior is provided.

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 with the main purpose, which is good. However, several clauses are cryptic and likely do not help an agent ('FragGate-admitted on the MCP path,' 'Binding-only ops stay per-op proxy_fallback'). These sentences take up space without adding clear instructional 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 four parameters, no output schema, no parameter descriptions, and advanced/internal positioning, this description is far from complete. It lacks guidance on parameter semantics, expected behavior, return values, error cases, and when to override the 'Prefer fraggate_call' advice. An agent would not have enough information to invoke this tool reliably.

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 does not explain session_id, slug, op, or payload. The only hint is that the session must already be open, which weakly relates to session_id. There is no meaningful guidance on how to construct op, slug, or payload, making correct invocation very difficult.

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

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

The description states the tool's core function: 'Raw session exec for an already-open session.' It also names fraggate_call as the preferred alternative, which helps differentiate it from a key sibling. However, terms like 'FragGate-admitted' and 'proxy_fallback' are not defined, leaving some ambiguity about what 'exec' actually entails.

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 a clear usage signal by saying 'Prefer fraggate_call' and notes that this tool targets an already-open session, which implies a prerequisite. It does not, however, provide explicit conditions or scenarios where raw exec should be chosen over the preferred alternative, beyond labeling it 'advanced/internal.'

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

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

The annotations only mark readOnlyHint=false and openWorldHint=false, so the description carries most behavioral weight. It adds meaningful context: the operation is internal/advanced, session plumbing is normally hidden, and visible effects appear only when the receipt chain is requested. This is useful, though it does not detail side effects or lifecycle requirements.

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

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

The description is two short sentences with no filler. The advanced/internal status is front-loaded, the preferred alternative is immediate, and the usage condition is stated efficiently. Every phrase contributes.

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 internal tool with no output schema, the description gives enough to decide when to call it and what to expect at a high level. It could name related lifecycle tools like runtime_session_close or runtime_session_receipt, but the core context is present and not misleading.

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

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

There are zero parameters, so the description has no parameter burden to carry. The schema is fully covered by being empty; no additional parameter explanation is needed. The mention of 'session object' gives semantic context 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 a specific action ('Open a raw session object') and immediately distinguishes itself from the preferred sibling ('Prefer fraggate_call'). The '[advanced/internal]' tag further clarifies it is a low-level alternative, so an agent can differentiate it from normal session 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?

It explicitly names fraggate_call as the preferred alternative and gives a concrete condition for when the raw session is relevant: 'unless the user asked for the receipt chain.' This tells the agent both when not to use the tool and when the advanced path is justified.

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

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

Annotations already indicate readOnlyHint=false and openWorldHint=false, so the mutation behavior is covered. The description adds useful context that 'Identity remains Aziel Eliab,' clarifying the auth identity, and notes this operates on a 'raw session.' However, it does not explain what happens to existing rules, whether the policy is immediately applied, or what side effects may occur on the session.

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

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

The description is compact and front-loaded with the important context, action, and alternative routing. Every sentence earns its place, though the final sentence about identity could be more explicitly tied to behavior or authorization.

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 an advanced tool with five parameters, no output schema, and no parameter-level documentation. The description does not explain return behavior, how allow rules combine with existing session policy, or what kv_increment and max_payload_bytes control. Given the tool's complexity, the description is not complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only vaguely references 'allow rules' without mapping to allow_ops or allow_slugs, and it says nothing about kv_increment or max_payload_bytes. With five parameters and no schema documentation, this is a significant 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 states a specific verb and resource: 'Attach allow rules on a raw session.' It also distinguishes itself from fraggate_call, which is the default path that 'applies defaults.' The 'advanced/internal' tag further clarifies its targeted role, making the purpose unmistakable.

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

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

The description explicitly names fraggate_call as the preferred alternative and gives a clear reason: it applies defaults. This tells the agent when to choose the sibling instead. However, it does not spell out specific conditions or scenarios where this tool should be selected beyond the 'advanced/internal' signal.

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

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

Annotations already establish readOnlyHint=true, so the description is not burdened with safety disclosure. It adds useful context about the advanced/internal nature and the raw-session scope, but does not explain what a receipt contains or what 'the chain' refers to. This is adequate but not rich.

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

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

The description is two short sentences with no filler. The advanced/internal label, the action, and the routing preference are all front-loaded, and every clause adds 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 simple read-only tool with one parameter, the description gives enough to identify the tool and basic invocation intent. However, with no output schema and no explanation of receipt contents or the 'chain' concept, an agent may lack sufficient context to interpret the result correctly.

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

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

The schema describes session_id only as a required string, and the description provides zero additional parameter guidance. Because schema description coverage is 0%, the description needed to compensate but did not explain the expected format or meaning of session_id in the context of a raw session.

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 ('Read the last receipt') and a specific resource ('a raw session'), making the core purpose clear. It also frames the tool as advanced/internal, which helps distinguish it from product-facing display tools, although it does not explicitly differentiate from the sibling runtime_session_receipts.

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 instruction to prefer product output (display) unless the user asked for 'the chain' provides a concrete when-to-use guideline. It does not name alternatives explicitly, but the directive is actionable enough for an agent deciding between this and a display-oriented 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?

Annotations already declare readOnlyHint=true, and the description's 'Read' is consistent. The description adds useful context that this is an advanced/internal low-level view and that it returns the full chain, but it does not disclose return structure, ordering, pagination, or empty-result 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?

Two short sentences with no filler: the first defines the tool's scope, the second gives routing guidance. The '[advanced/internal]' tag is front-loaded and informative.

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

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

For a one-parameter read-only tool, this provides the core call intent and a usage preference. However, with no output schema, terms like 'raw session' and 'chain' are left undefined, and the description does not address possible error conditions or how the receipts are ordered.

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 carries the full parameter-documentation burden. It adds that session_id refers to a raw session and that the tool returns the full receipt list for that session, which is meaningful but still leaves the format or accepted values of a raw session unspecified.

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 ('Read') and a specific resource ('full receipt list for a raw session'), which distinguishes it from the singular runtime_session_receipt sibling and other runtime session tools. It could be stronger by naming the alternative product output tool, but it is not tautological or misleading.

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 'Prefer product output unless the user asked for the chain' gives an explicit when-to-use condition and points away from this tool for normal cases. It is actionable, though it does not name the preferred alternative explicitly.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds context beyond that by disclosing the 'one door' agent flow (discover, route, refuse) and the dual surface (agent chat vs. Worker/Flutter/local install), which helps set expectations for what the skill covers.

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 the second sentence relies on jargon ('technical UI chrome', 'complete human software', 'counted download') that may confuse rather than clarify. It earns its place conceptually but is not as crisp as it could be.

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

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

For a no-parameter, read-only skill the description conveys the general purpose, but it leaves the 'discover, route, refuse' process unexplained and does not state what the returned content looks like. Given no output schema, a slightly more explicit account of what the agent will receive would make it complete.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly spends no space on inputs.

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 opening 'Read how an agent uses Aziel Eliab software' gives a clear verb and resource, and the title 'How to use this software' reinforces it. The following 'one door — discover, route, refuse' is cryptic, but the core purpose is still identifiable and distinct from the runtime_bundle/fraggate siblings.

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

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

The imperative 'Read how an agent uses...' implies this is the orientation/entry point for understanding the software. However, it does not explicitly state when to prefer this tool over runtime_manifest, runtime_session_policy, or other siblings, nor give any when-not-to-use conditions.

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