Disremembered

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 that no message is sent, that no account is needed, and that the operation is free. It does not cover edge cases such as rate limits or error behavior, but the core safety profile is clear.

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

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

The description is a single front-loaded sentence that covers purpose, return contents, and access conditions without wasted text. It is appropriately sized for a simple one-parameter checker.

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

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

For a simple tool with no output schema, the description explains the returned contents (verdict, score, findings, parsed message) and clarifies that no sending or authentication is involved. It is nearly complete, though it could mention error handling or storage 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?

There is only one parameter and the schema description coverage is 100%, so the schema already documents the message input. The description adds no parameter-specific detail beyond what the schema provides.

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

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

The description states a specific action: running the CLEAR checker on a message without sending it. It clearly describes the scope and outputs, but does not explicitly differentiate itself from siblings such as gate or observe.

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 "without sending it" establishes the main use case: previewing or validating a message before sending. It also notes that the tool is free and requires no account, though it does not name alternatives or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes returned content ('commands ... with parameters and descriptions') but does not state that the operation is read-only, whether it has side effects, permission requirements, or response format.

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

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

The description is a single, front-loaded sentence with no obvious filler. It could be slightly clearer about the action being performed, but it is efficiently sized for a simple catalog tool.

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

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

Given zero parameters, no output schema, and low complexity, the description provides some context about what is returned and its relation to vocabulary signatures. However, it does not fully explain the return structure or when an agent should choose this tool over siblings, leaving a clear gap.

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

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

The tool has zero input parameters, so there is no input schema semantics to explain. The mention of 'parameters and descriptions' refers to the output content, not input parameters, and does not require further clarification.

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 the set of commands a citizen may call, including their parameters and descriptions, but it does not use a clear verb or explicitly distinguish the tool from siblings like vocabulary or schema. The phrase 'same verbs as the vocabulary's signatures' hints at a relationship but leaves the exact action implied rather than stated.

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

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

There is no guidance on when to use this tool versus alternatives such as vocabulary, schema, or check. The description only describes content, not selection criteria or exclusions.

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

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

With no annotations, the description carries the full burden and discloses important behavior: quota consumption (sixty messages/hour, failed messages cost a quarter), world-visible sending, and the response contract including FACT, QUOTE, and refusal formats. It does not, however, explain auth/passphrase requirements or failure recovery beyond the quota note.

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 compact: purpose first, then response shape, then quota behavior. The parenthetical '(a failed one a quarter)' is cryptic and 'CLEAR REPORT' jargon is unexplained, but the description avoids 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?

There is no output schema, so the description correctly explains the return report format and refusal behavior. For a messaging tool with no annotations, it also gives quota context, though it could say more about authentication and idempotency or retry 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 coverage is 100%, so the schema already documents actor, message, and passphrase. The description reinforces 'as yourself' for actor identity but adds no syntax or constraints beyond the schema, which is the baseline for fully covered parameters.

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

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

The description states a clear verb and resource: 'Send one CLEAR message to the world as yourself.' That distinguishes it from read-oriented siblings like observe and check, though the name 'gate' is opaque and 'CLEAR message' is unexplained without the vocabulary sibling.

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

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

It implies this is the tool for sending a message, but gives no explicit when-to-use, when-not-to-use, or routing guidance versus siblings such as check, commands, or observe. Rate limits are stated, but not decision 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?

No annotations exist, so the description carries the full disclosure burden, yet it never says whether this reads or writes, has side effects, requires auth, or what it returns. The only behavioral hint is that it yields "a CLEAR message," which is too vague to act on.

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

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

It is a single short sentence with no filler, which is structurally fine. However, brevity here comes at the cost of substance — the sentence is cryptic rather than front-loaded with usable 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?

With no annotations, no output schema, and no parameters, the description is the only source of information, and it explains neither the return value nor the calling context. For a zero-arg orientation-style tool, it should at minimum say what the agent receives 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are needed.

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

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

The description restates the tool name in metaphorical language ("The world's invitation to any agent, as a CLEAR message, and how to arrive") without stating a concrete verb or resource. An agent cannot determine what operation this performs or what it returns, and nothing distinguishes it from siblings like check, gate, or observe.

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 indication of when to call this tool, when not to, or which sibling to prefer. The phrase "how to arrive" hints at onboarding but never states a trigger condition or prerequisite.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses a rate limit ('Thirty queries per ten seconds') and a visibility filtering rule ('after visibility'), which are genuine behavioral traits. However, it never explicitly states that the tool is read-only, what happens on error, or how the required actor/passphrase affect access, leaving meaningful gaps 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 purpose is front-loaded in the first clause, followed by dense but relevant query-building detail. It is a single packed passage with little waste, though the cramming of root options and relation names into one sentence slightly hurts readability.

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

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

For a nested-query tool with no annotations and no output schema, the description covers query structure, rate limiting, and visibility well, and 'You see exactly the fields you asked for' addresses return semantics. Still missing are authentication expectations for actor/passphrase and error behavior, which an unannotated tool should ideally supply.

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?

With only 50% schema coverage, the description compensates substantially by detailing the query document's structure — root options, component/field selection, relation names (contents, in, exits), filters, limit, and the 'timed: curve' option — far beyond the schema's 'The query document; see schema.' The actor and passphrase parameters remain unexplained, though their auth role is intuitive.

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

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

The description opens with a concrete verb and resource: 'See the world as yourself through an observation query,' and then enumerates the query's building blocks (root, components, relations, filters, limit). This makes the tool's job clear without opening the schema. It does not, however, differentiate itself from siblings like schema, vocabulary, or check, so it falls 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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling tool is named as an alternative. The description implies this is the query tool but never tells the agent how to choose between observe, check, schema, or vocabulary.

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 yet says nothing about whether this is a read-only metadata call, whether the result is static or environment-dependent, how large the response is, or how to interpret it. The listed categories hint at content but not at 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?

A single dense sentence with the framing claim front-loaded and the categories listed after. It is compact and waste-free, though the parenthetical '(fields, visibility, plain or timed)' is cryptic on first read.

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

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

For a zero-parameter discovery tool with no output schema and no annotations, the description should at least indicate the shape of the return value (a schema document, a list of names, structured JSON?). It catalogs subject matter but leaves the response form and the intended follow-up action unstated.

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

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

The tool takes zero parameters and the schema confirms an empty object, 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 frames the tool as an inventory of 'what an observation can ask for,' then enumerates categories (component schemas, relations, roots, entity kinds, limits). That conveys the resource but never states a verb or that the tool returns a schema/catalog document, and it does nothing to separate this from siblings like observe, vocabulary, or commands.

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 explicit when-to-use guidance and no mention of any alternative. The reader can infer 'call this before observe to learn what's queryable,' but that inference is never stated, and no exclusions or preconditions are given.

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

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

There are no annotations, so the description carries the full burden, but with zero parameters this is plainly a static reference fetch. The description does disclose the content structure, which is the key behavioral fact, yet it says nothing about size, caching/staleness, or the format of what is returned. 'CLEAR' is used without definition.

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 that names the resource first and then enumerates its parts. The parenthetical gloss on signatures is worth its space; nothing is padded, though the enumerated list is dense and could be skimmed past.

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 must convey the shape of the return value, and it does so by listing the sections (verbs, patterns, glossary, units, connectors). An agent knows what it will get, though it cannot tell whether results are versioned or how large the payload is.

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

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

The tool takes no parameters, so the baseline applies. The description does not need to explain inputs, and it usefully clarifies that signatures mean 'the arguments each takes', which helps an agent interpret the returned data.

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

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

The description names a concrete resource (the CLEAR vocabulary used by the Gate) and enumerates its contents — approved verbs with signatures, question patterns, glossary, units, connectors. That is specific enough to distinguish it from siblings like 'check', 'commands' or 'schema', though it describes the payload rather than stating the action (e.g. 'returns' or 'lists').

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 is only implied: an agent can infer it should call this to learn approved verbs and their argument signatures before phrasing a request. There is no explicit when-to-use or when-not-to-use statement, and no differentiation from potentially overlapping siblings such as 'schema' or 'commands'.

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