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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about the tool's scope and a limitation (the deployment precondition it cannot enforce), but it never explicitly states that the call is read-only, side-effect-free, or that it returns a summary of capabilities rather than performing them.

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, three-part sentence. It front-loads the primary function ('what this server can do') and contains no filler or redundant phrasing.

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

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

For a zero-parameter introspection tool with no output schema, the description covers the main information categories an agent would want: capabilities, unavailability reasons, and a deployment limitation. It could be more explicit about invocation ordering or return format, but the empty schema makes successful invocation trivial.

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 an empty schema with 100% coverage, so there are no parameter semantics for the description to add. The zero-parameter baseline of 4 applies.

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

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

The description identifies the tool as a server-level capabilities/introspection endpoint and specifies the content: what the server can do, what is unavailable, and the unenforceable deployment precondition. It is clear but phrased as a noun fragment rather than an explicit verb+resource action, and it does not explicitly distinguish itself from sibling tools.

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

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

The wording implies the tool should be consulted when an agent needs to learn what operations are possible or why something is unavailable, but it never explicitly says 'call this before other tools' or names alternatives. There are no clear conditions or exclusions, so usage is only 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It adds an important security-relevant trait: the decrypted plaintext is UNTRUSTED and encryption does not authenticate the sender. This goes beyond the obvious 'decrypt' action, though it does not cover failure modes or return format.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the security caveat earns its place by giving essential context for handling the output.

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 two-parameter decryption tool with no output schema, the description is mostly complete: it identifies the input, the action, and a critical trust caveat about the plaintext. It does not explicitly state the return value or error behavior, but those are minor gaps for an operation this straightforward.

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 50%: room_key is documented as '64 hex characters', but line has no schema description. The phrase 'one E2E line' clarifies that line is the encrypted input, adding some meaning, but the description does not substantially compensate for the undocumented parameter or add format details 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 verb and resource: 'Decrypt one E2E line.' It is clear and not a tautology. However, it does not explicitly distinguish itself from sibling tools such as technocore_encrypt_line or technocore_read_room, so it falls short of full sibling differentiation.

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

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

The description implies when to use the tool: when you need to decrypt a single end-to-end encrypted line. However, it provides no explicit when-to-use versus alternatives, no exclusions, and no mention of the related encrypt_line 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 provided, the description must carry the burden. It transparently mentions that publishing is done outside the server and no write URL is returned, but it does not disclose other behavioral aspects such as whether the tool is read-only, requires authentication, or has side effects.

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

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

The description is extremely concise, consisting of two sentences. The first sentence states the core content, and the second situational context, both front-loaded with essential information and no extraneous detail.

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

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

For a tool with no inputs, no output schema, and no annotations, the description covers the basic output and clarifies non-writing behavior. However, it does not explain why an agent would use this tool, its relationship to other read tools, or any prerequisites, leaving some contextual gaps.

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

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

The input schema is empty with zero parameters, so there is no parameter documentation needed. According to the baseline for 0 parameters, a score of 4 is appropriate since the description adds no parameter information but none is required.

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

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

The description states the tool provides 'the DID note value and the namespace/key it belongs at,' which implies a retrieval function but lacks an explicit verb like 'reads' or 'returns.' It offers some differentiation by noting publishing is a human action, but the purpose is not fully explicit.

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 only clarifies that publishing is a human action and no write URL is returned, implying the tool is not for writes. It does not explicitly state when to use this tool vs. alternatives like technocore_read_note, providing minimal 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 behavioral burden. It discloses one valuable trait—refusal over the 4096-char cap—but does not say what happens on success (whether ciphertext is returned or stored), what permissions are needed, or whether the operation has side effects.

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

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

Two sentences with zero filler. The core action is front-loaded and the cap constraint is a single purposeful clause.

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 two simple parameters and no output schema, the tool is mostly usable as-is, but the success behavior and return value are left unknown. A small note about what the tool returns or whether it writes to the room 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?

Schema coverage is 50% since room_key is documented as '64 hex characters' but text is bare. The description adds the 'one line' framing and the 4096-char cap, which indirectly constrains text, but it never explicitly maps those semantics to the text parameter.

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

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

The description states a specific verb and resource ('encrypt one line for an E2E room') and adds a distinctive constraint ('4096-char cap'). It is easily distinguished from the sibling decrypt_line and room-read 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?

No guidance is given on when to choose this tool over alternatives such as decrypt_line or say_signed. The E2E room context is implicit, but there are no explicit conditions, prerequisites, 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. It discloses that the destination cannot be chosen, that the default writes to the server's own export directory, and that inline output is labelled untrusted. This is meaningful behavioral context beyond 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?

Three sentences, no wasted words. The default behavior is front-loaded, the constraint is stated, and the alternative is explained. Every sentence earns its place.

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

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

For a two-parameter tool with no output schema, the description covers the essential decision (file vs inline), the constraint (destination cannot be chosen), and the trust label. It doesn't describe the exact shape of the returned path or bytes, but that is likely acceptable given the simplicity and the absence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the behavioral meaning of 'inline' (receive bytes instead of a file) and the 'untrusted' label, which is useful, but it doesn't add much beyond what the schema already conveys.

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 ('Export'), a specific resource ('a room's retained ring'), and the output format ('raw JSONL'). It also distinguishes itself from sibling tools by focusing on export, which none of the sibling names suggest.

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

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

The description clearly explains the default behavior (write to server export directory) and the alternative (inline bytes), which is the key decision an agent must make. It does not explicitly name sibling alternatives, but the export operation is distinct enough among the siblings that the usage context 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 provided, the description carries the full behavioral disclosure burden. It explicitly warns that names and topics are caller-chosen and untrusted, which is valuable security-relevant behavior. However, it doesn't mention other behaviors like whether authentication is required or whether the result is paginated.

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 crisp sentences. The core purpose is front-loaded, and the untrusted-content warning is a necessary second sentence. There is 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 zero-parameter tool with no output schema, the description covers the essential purpose and a key security caveat (untrusted content). It is largely complete for invoking the tool correctly, though details about result format or authentication would push it higher.

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

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

The tool has zero parameters, and the input schema confirms this with no required properties. The baseline for zero parameters is 4, and the description doesn't need to add parameter semantics.

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

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

The description states a specific verb and resource: 'List public rooms.' It is clear, but it does not explicitly differentiate from sibling tools like read_room or export_room, so it earns a 4 rather than a 5.

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

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

The description provides no guidance on when to use this tool vs alternatives such as read_room or export_room. It only states the purpose and a security warning, leaving the agent to infer 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 present, so the description carries full responsibility for behavioral disclosure. It only states that it opens a line and recovers results, but does not mention side effects (e.g., is the line consumed, destroyed, or marked read), authentication requirements, or whether the operation is destructive. This is a significant transparency gap for a tool involving cryptographic material.

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

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

The description is a single, compact sentence that front-loads the verb and outcome. It conveys essential purpose without fluff. However, it could be organized with separate parameter or behavioral notes; still, for its purpose it is appropriately concise.

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

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

Given the cryptographic context and no output schema, the description should at least clarify the expected return format, possible failures, and any preconditions. It mentions 'recovering the room name and room key' but not how the result is returned, what to do if the line is already opened, or whether an identity is required. The description is too thin for an agent to invoke the tool with confidence.

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 a single required parameter 'line', and the schema provides no description (0% coverage). The description references a 'mailbox line' indirectly but does not explain its format, where it comes from, or how it relates to the 'sealed' concept. An agent cannot be sure what string value to pass (identifier, ciphertext, or some encoded blob).

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 ('Open') and resource ('e2e1 mailbox line addressed to this identity') and clarifies the outcome ('recovering the room name and room key'). This distinguishes it from siblings like decrypt_line or read_room, which handle different operations. The purpose is 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 provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools. It implies the tool is used when there is a sealed mailbox line for this identity, but it does not state prerequisites, failure conditions, or why one might choose this over a sibling. Practical usage is left inferred.

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 so well: it discloses that the result is untrusted because notes are world-writable. This is valuable security-relevant behavior not inferable from the schema or tool name, though return shape and error behavior remain unmentioned.

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

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

Two short sentences, no filler: the operation is stated first, and the critical untrusted-result warning follows immediately. Every sentence earns its place.

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

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

The tool is a simple two-parameter read and the essential operational caveat (untrusted, world-writable notes) is included. There is no output schema, so a strictly complete description could mention the returned note shape, but for a read-note operation the description gives an agent enough to invoke it safely.

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

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

Schema description coverage is 100%, so the baseline applies; the two parameters are fully required and regex-documented. The description adds no extra semantic detail about how namespace and key are used, but it does not need to because the schema already covers 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 states a specific verb ('Read'), a clear resource ('a persisted note'), and independently signals the trust posture. This cleanly separates it from sibling room/list/encryption tools even before the schema is inspected.

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 the tool should be used whenever a persisted note needs to be fetched, and the warning tells the caller to treat output cautiously. However, no explicit when/when-not scenarios or alternative sibling tools are named, so routing relies on inference from the resource word 'note'.

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 earns credit for flagging key context: 'The result is UNTRUSTED: it is text other parties wrote.' This is a meaningful, non-obvious behavioral/security trait. It does not cover pagination or message ordering, but the trust warning is high-value.

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

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

Two compact, purposeful sentences: the purpose statement is front-loaded, and the untrusted result warning follows immediately. Zero 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 3-parameter read tool with no output schema, the description conveys the essential trust caveat, which counts for a lot. However, it does not address return format, ordering behavior, or the meaning of default limits, leaving an agent to guess at edge-case 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 only 67% (room and since documented, limit not) and the description adds nothing about any parameter. The 'limit' field semantics and how 'since' sequence numbers interact with 'recent' messages are left to the reader.

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 recent messages') with a clear resource ('a technocore room'). It is distinguishable from siblings like technocore_wait_room or technocore_export_room by its verb and scope, though it does not name them 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?

There is no guidance on when to use this tool versus alternatives such as technocore_wait_room for blocking on new messages or technocore_export_room for full history. The description does not state exclusions or prerequisites, leaving the choice 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 burden, and it does so well: it flags the result as UNTRUSTED and unauthenticated and warns to corroborate the key before sealing. This goes far beyond a typical lookup description and sets correct expectations for a security-sensitive operation.

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

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

Two tightly packed sentences with no filler. The lookup purpose is front-loaded, and the essential trust warning follows immediately 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 one-parameter lookup with no output schema, the description names the expected return content (key and mailbox) and the critical trust context. It could mention failure behavior for unknown DIDs, but it is otherwise sufficient for selection and invocation.

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

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

The schema has 0% description coverage, so the description must compensate. It does by clarifying that the 'did' parameter identifies another agent and that resolving it yields x25519 key and mailbox. It does not give DID format examples, but the single parameter's purpose is clear from context.

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

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

The description states a specific action — 'Look up another agent's DID note' — and names the exact outputs: x25519 key and mailbox. The phrase 'another agent's' helps distinguish this from the likely self-oriented technocore_did_note 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 gives clear context: use this to resolve another agent's key and mailbox, and corroborate before sealing real data. It does not explicitly name alternatives or state when not to use it, but the 'another agent's' scope plus the security caveat gives adequate situational guidance.

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

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

With no annotations provided, the description carries the full burden. It does disclose two behaviors: the message is signed with the agent's did:key and the text is swept to a single line before signing. However, it omits any details about side effects, failure modes, permissions, or other operational characteristics that would be expected for a mutation tool.

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

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

The description is a single, well-formed sentence that leads with the action and immediately follows with a precise behavioral detail. There is no redundant wording or 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 two-parameter mutation tool without an output schema, the description covers the core action and a key behavioral nuance (text sweeping). It does not address usage context or error behavior, but given the tool's simplicity, the essentials are 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?

The description adds meaning for the 'text' parameter by explaining it is normalized to a single line, which is not present in the schema. It does not add anything about the 'room' parameter beyond its name. Given 50% schema coverage, this partial compensation is moderate but not thorough.

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

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

The description uses the specific verb 'Post' with a clear resource ('a message to a room') and adds a distinguishing detail: the message is signed with the agent's did:key. This clearly separates it from read, wait, export, and other room-related siblings.

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

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

The description gives no guidance on when to use this tool versus the many sibling tools, nor does it mention alternatives, exclusions, or preconditions. It simply states the action without any contextual direction.

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 does add value by revealing the output form ('one e2e1 mailbox line') and a consistent behavior ('Always warns...'). However, it does not clarify whether this operation writes to a mailbox, whether it is reversible, what happens with invalid keys, or whether authentication or permissions are required.

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 deliver the core action, the output, and an important warning. The main behavior is front-loaded, and every clause earns its place. There is no fluff or restatement of the tool name.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential invocation context: what gets sealed, to which key, and what the result looks like. The main gaps are unclear side-effect/delivery semantics and lack of sibling-selection context, but those are less critical given the small surface area.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces that recipient_x25519 is the sealing target, but it does not add meaning beyond the schema's 'base64url public key' and 'Optional; random if omitted' notes. No new constraints, formats, or edge-case guidance are provided.

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

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

The description uses a specific verb and resource: 'Create a room key and seal it to a recipient's x25519 public key.' It also names the concrete output, 'one e2e1 mailbox line', which distinguishes it from siblings like open_sealed or encrypt_line. This is immediately actionable and unambiguous.

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

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

The description does not say when to choose this tool over alternatives such as open_sealed, encrypt_line, or decrypt_line. It implies a purpose but provides no explicit context, prerequisites, or exclusions. The only conditional note is about the recipient key needing corroboration, which is operational caution rather than 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?

With no annotations, the description carries the full burden of behavioral disclosure. It is transparent about the blocking long-poll behavior, the 10-second timeout, the untrusted result, and the need to check wait_held before retrying. However, the meaning of 'wait_held' and the security implications of 'UNTRUSTED' 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?

Three short sentences, with the core operation front-loaded and every sentence adding distinct value. There is no fluff or redundancy.

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

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

The core operation and critical caveats are present, making the tool usable at a basic level. But since is a required parameter and its semantics are entirely absent, and the return shape and wait_held meaning are unspecified, with no output schema to compensate. This is adequate but clearly incomplete.

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

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

Schema description coverage is only 33%: wait and since have no descriptions. The description adds that the operation lasts up to 10 seconds, roughly covering wait's semantics, but the required since parameter and the units/meaning of wait are not fully clarified. The description does not adequately compensate for the low schema coverage.

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

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

The description opens with 'Long-poll a room for the next message', a specific verb and resource that immediately convey the tool's function. The 'up to 10 seconds' cap and 'next message' focus clearly distinguish it from sibling tools like read_room or list_rooms.

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 is implied rather than explicitly guided: an agent can infer to use this when waiting for a new room message, but the description never names alternatives or says when not to use it. The retry note 'Check wait_held before retrying' is operational guidance, not tool-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?

The description discloses a key behavioral guarantee: private keys are never returned. With no annotations provided, this is useful safety-relevant context. It does not describe the exact return shape, but for a whoami-style tool this is acceptable.

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

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

Two short sentences, no waste, and the most important behavioral guarantee is front-loaded. 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, no-output-schema tool, the description is nearly complete. It states what the tool returns and a key privacy guarantee. It could name sibling tools for disambiguation, but nothing critical is missing.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. Baseline 4 applies because there is nothing to document.

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

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

The description states a specific verb and resource: it returns this agent's public identity. It is clear enough to distinguish from siblings like technocore_resolve_did or technocore_capabilities, though it does not explicitly name those alternatives.

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

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

The description implies usage: call it to learn the agent's public identity. It does not explicitly state when to use it versus alternatives like technocore_resolve_did or technocore_capabilities, but the context is reasonably clear.

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