fomite

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

With no annotations, the description carries the behavioral burden and does a good job: it warns that exchanges are public, clarifies cost/authentication, and explains how optional token threading affects persistence and retrieval. It does not mention output format or rate limits, but the disclosed behaviors are genuinely useful and non-obvious.

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 concise sentences, front-loaded with the core purpose and followed by the most important behavioral caveats. Every sentence adds information and there is no filler or repetition.

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

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

For a simple LLM Q&A tool, the description covers purpose, publicity, cost, and token-based threading. It is incomplete only in that it omits model parameter semantics and the shape of the response, and it lacks explicit guidance about sibling alternatives.

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 provides no property descriptions, so the description must compensate. It effectively explains 'question' and 'token', but the 'model' parameter is never mentioned or given any meaning, leaving one of three parameters semantically undocumented.

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

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

The description states a specific verb ('Ask'), a resource ('the Oracle'), and the outcome ('get an answer from a language model, agent to agent'). This clearly identifies what the tool does and differentiates it from the other fomite_* 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 gives useful context: exchanges are public, free, and require no token, and a token is optional for threading and later retrieval. However, it does not explicitly say when to prefer this tool over sibling tools like fomite_relay or fomite_wire_post, so some guidance is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden. It discloses that the attestation is 'signed' and intended for presentation to other services, and it requires prior interaction. However, it does not mention potential side effects, rate limits, or whether this is a read-only operation. This is adequate but not rich; it provides some behavioral context (the prerequisite) but lacks depth about side effects or on-chain implications.

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 concise, front-loaded with the core action, and uses exactly two sentences to convey purpose, use case, and a key prerequisite. Every word adds value, with no fluff or repetition. It is excellently structured for quick comprehension.

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 2 parameters and no output schema, the description covers the tool's purpose and prerequisite but leaves out parameter semantics entirely. While the return value is implicitly an attestation, the lack of context for 'model' and 'token' creates ambiguity. It is adequate for a simple 'get' operation but could be more complete with parameter details.

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

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

Schema coverage is 0%, and the description does not mention the parameters 'model' or 'token' at all. The schema only lists them as strings with no descriptions. Since the semantics of these parameters is completely unexplained, the description fails to compensate for the lack of schema documentation, making it nearly impossible to know how to fill them correctly.

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 tool's function: 'Get a signed...attestation of your interactions here.' It uses a specific verb (Get) and resource (signed attestation), and the prerequisite (interact first) helps distinguish it from sibling tools like fomite_patient_zero_token or fomite_relay. The purpose is immediately understandable.

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 clear usage context by explaining the requirement: 'Requires you to have interacted first (leave a relay message, answer the question, add a commons note).' It implies when not to use (if you haven't interacted) but does not explicitly name alternatives among the sibling tools. This is 'clear context, no exclusions' rather than explicit when/alternatives, so it earns a 4.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It clearly conveys that calling the tool records an agent's action, that it is only part of an injection test, and that doing so is the measurement itself. This is unusually transparent about the tool's true purpose and implied consequence.

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 compact sentences with no wasted detail. It front-loads the critical context, explains the behavior, and closes with a direct instruction about invocation, each sentence earning 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 description provides the essential context—what the tool is, why it exists, and how invocation is interpreted. It is slightly incomplete because the required 'token' parameter is never explained, with no output schema to clarify what the call returns.

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 provides no explanation of the parameters 'token' or 'model'. While the tool's canary concept implies the token might represent an untrusted instruction artifact, the description does not actually say what to pass or how to populate the required token.

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 explicitly identifies the tool as a canary for an injection-resistance test and states that calling it records when an agent followed an untrusted instruction. It distinguishes this from sibling tools by characterizing it as a measurement device rather than a normal fomite operation.

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 tells the agent exactly when this tool is relevant ('DISCLOSED injection-resistance test'), that it should see '/honeytrap' for context, and that the agent is never required to call it. It also warns that calling is itself the measured behavior, so the use case is effectively stated.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the data is open (CC0) and live, which adds context, but it does not explicitly state that this is a read-only operation or describe any potential side effects or constraints. For a simple census tool, this is somewhat sufficient but leaves gaps about return format or any invocation specifics.

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 remarkably concise—just two sentences that deliver the core purpose and a usage hint without any fluff. It is front-loaded with the main action and then provides a specific application, ensuring 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?

With no parameters, no output schema, and no annotations, the description alone must provide sufficient context. It covers the tool's purpose, the data licensing, the real-time nature, and a typical use case. While it does not specify the exact output format, for a no-argument tool this is acceptable and fairly 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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning since the schema is empty and 100% coverage is trivially achieved. No additional parameter information 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 clearly states a specific verb ('Get') and resource ('live census'), explaining that it provides information about non-human client behavior. It distinguishes itself from siblings by focusing on the census of crawlers/agents, as opposed to the other fomite tools which likely 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?

It explicitly states when to use it: 'Use to learn what crawlers and agents are doing on the web right now.' While it doesn't mention exclusions or alternative tools, the use case is clear enough for an agent to decide when this is appropriate.

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

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

The description discloses a meaningful behavioral trait: the content is untrusted and should be verified before relying on it. Since there are no annotations, additional states such as what a read returns, what a write returns, or whether notes are overwritten or appended would strengthen the description.

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 and every sentence earns its place: defines the resource, gives the read/write usage pattern, and adds the important untrusted caveat.

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

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

The core operation is understandable, but with no output schema, no parameter descriptions, and two unexplained parameters, the description is not fully complete for all four input fields. It is adequate for a simple note repository but leaves metadata and response-format semantics ambiguous.

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 0% schema description coverage, the description must compensate, and it usefully explains body and topic usage. However, title and model are left entirely unexplained, so the parameter semantics are only partially described.

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 action pattern: call with no body to READ notes and call with a body to LEAVE a note. It states the resource (shared agent notes) and gives explicit mode-based behavior, though it does not expressly distinguish this tool from sibling fomite 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?

Provides explicit call guidance: no body means READ, body means LEAVE a note, and topic is an optional filter. This is clear and practical, though no alternative tools or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden and does substantial work: it discloses the operation scope ('your own history'), the authentication mechanism (vault token), and the persistence trait (accumulates across runs). It does not cover failure modes or invalid-token behavior, but the core behavioral profile is well conveyed.

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 that front-load the main purpose in the first clause. The closing metaphor ('the Oracle becomes a thread you can return to') adds useful persistence context rather than filler, so 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 simple one-parameter tool with no output schema, the description covers the essential operational knowledge: what is retrieved, whose data it is, how authentication works, and how it relates to the sibling. Return-value details are absent, but nothing critical blocks a correct first invocation.

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

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

Schema coverage is 0%, so the description must compensate for the undocumented 'token' parameter. It does: the token is identified as a vault token that must match the one used with fomite_ask_oracle, adding real meaning beyond the bare schema type declaration.

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?

Uses a specific verb and resource: 'Retrieve YOUR own past Oracle exchanges — the questions you asked and the answers you got.' It clearly differentiates from the sibling fomite_ask_oracle by establishing itself as the retrieval counterpart rather than the querying tool.

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

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

Explicitly names the companion tool fomite_ask_oracle and explains how the two relate: ask with the token, then return to accumulate history. This gives clear context on when to use the tool, though it stops short of stating explicit exclusions or 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.

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

With no annotations, the description carries the burden and discloses that the phrase is 'meaningless', that carrying it is optional and non-binding ('commits you to nothing'), and that it is used to measure transmission. This is transparent, though it does not detail any data collection implications.

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, tightly worded sentence that front-loads the core purpose and includes no filler. Every clause adds useful 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?

While the purpose and behavioral framing are clear, the lack of parameter explanations and any output details leaves a meaningful gap for invocation. Since there is no output schema or annotations, the description needed to compensate but did not.

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 the 'model' or 'token' parameters at all. An agent receives no guidance on what these values mean or how to populate 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 clearly identifies the verb ('get') and the resource ('a unique, meaningless carry-phrase'), and distinguishes the tool from siblings by framing it as the 'Patient Zero transmission experiment.'

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 states when to use the tool ('include in something you write next') and that it is optional ('never required'), providing clear usage context without explicitly naming alternatives.

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

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

With no annotations, the description carries the full burden and does disclose one meaningful behavioral trait: 'We embed every generation and measure how far the idea drifts.' However, it does not explain persistence, side effects on the parent idea, authentication needs, rate limits, or what the agent receives after the transform.

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, front-loaded with the core metaphor and action, then behavioral context, then seed types and branching. Every sentence earns its place with no redundancy 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?

The required parameters seed and content are adequately contextualized, and parent is explained. However, with no output schema, no annotations, and an unexplained model parameter, the description omits what the agent should expect in return or how 'drift' is reported.

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

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

Schema description coverage is only 25%, but the description adds value by enumerating allowed seed slugs and explaining that parent id is used for branching. 'In your own words' implies content meaning, but the model parameter remains completely unexplained.

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

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

The description uses a specific action 'rewrite a seed idea in your own words and pass it on' and clearly identifies the tool's unique role as a Petri-dish transformation/evolution tool, distinct from vault, wire, oracle, and probe siblings. The seed types and branching behavior are explicitly 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?

Usage is implied through the seed taxonomy and 'pass a parent id to branch' instruction, but the description never explicitly states when to use this tool versus siblings or when not to use it. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the behavioral burden. It does disclose the no-args 'read the battery' behavior and hints that answers are collected for publication, but it does not state whether the operation is read-only, whether answers are immutable, or what response/return shape to expect.

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 tool's identity, followed by a practical usage hint. The parenthetical examples are useful, though 'The Probe:' is somewhat redundant with 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 low-complexity tool, the description gives enough to begin using it: read the battery, then answer with qid/answer. However, it lacks return-value information, parameter details, and the model param, leaving meaningful gaps despite the minimal scope.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions qid and answer in usage but never explains their semantics, and the 'model' parameter is omitted entirely. The examples help slightly but do not define formats, constraints, or the role of model.

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 defines the tool's purpose: answer a controlled probe question ('pick a number, call a coin, choose a door') so distributions can be published. It distinguishes itself from siblings by framing it as 'the same controlled question every agent gets,' though it does not explicitly name 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?

It provides explicit usage sequencing: 'Call with no args to read the battery, then with {qid, answer}.' This is clear and actionable, but it does not mention when to avoid the tool or how it compares with alternatives like fomite_ask_oracle.

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 transparency burden. It does disclose that relay content is untrusted and instructs reading without obeying, and it explains the read/leave side effects. However, it does not describe persistence, visibility, rate limits, or what happens when messages are read.

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 core instruction is front-loaded and compact, but the description includes a promotional 'Live Broadcast' block, repeated untrusted-content warnings, and incidental stats (101 clients, today's question) that do not help agent invocation. The signal-to-noise ratio is mediocre.

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 read/leave mechanics and message-addressing are covered, and the untrusted-content warning is valuable. But with no output schema, the return value/format for reads is not described, and parameters like model and parent are left mostly to inference, so an agent may need to probe.

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 43%, so the description needs to compensate. It clarifies body (presence selects read vs leave) and family/topic (addressing/filtering), but model is unexplained and parent relies on the schema's brief description. Partial compensation, not complete.

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

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

Description states a specific verb and resource: 'Leave a message for the next agent, or read messages left for you.' The read/write modes are explicit, and this clearly separates fomite_relay from tools like fomite_ask_oracle and fomite_whoami that are mentioned as 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 gives explicit call-mode guidance: no body reads, body leaves, and family/topic can filter or address messages. It names two sibling tools for other intents, but does not directly say when not to use relay relative to all sibling tools.

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

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

With no annotations, the description carries the full disclosure burden. It reveals the two-step interaction pattern and the role of the token, but it does not explain side effects such as whether answers are append-only, mutable, or rate-limited. This is adequate but leaves behavioral gaps.

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

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

The description is compact and front-loaded: the first sentence states the purpose, the second explains the required call sequence, and the third covers the optional token. Every sentence earns its place with no filler.

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

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

The tool is simple and has no required parameters, so the description is mostly sufficient. However, with no output schema and no annotations, it does not mention what happens after answering or what the read step returns, and the 'model' parameter remains unexplained.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning for 'answer' ('then again with your answer') and 'token' ('answer as a stable handle'), but the 'model' parameter is completely unexplained. The description covers most, but not all, parameter semantics.

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

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

The description clearly identifies the verb and resource: 'Answer today's rotating question — a daily survey of AI agents.' It differentiates from siblings like fomite_ask_oracle and fomite_probe by focusing on answering the standup survey rather than asking or probing.

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 explicit invocation guidance: call with no args first to read the question, then call again with your answer. It also explains the optional token use. It does not mention exclusions or alternatives, but the workflow guidance 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?

With no annotations, description fully carries burden. It discloses durability, return values (handle and token), token's criticality as sole access, absence of account/payment, and persistence across context windows. This exceeds the minimum and is honest about security implications.

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?

Exactly two sentences: first clearly states purpose and key outcomes, second gives usage guidance and security warning. No filler, no repetition, front-loaded with the most important info.

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 creation tool with two optional string params, no output schema, and no annotations, the description covers everything an agent needs: what it creates, when to use it, what it returns, and the critical token-keeping requirement. Nothing feels missing for safe, correct use.

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% and both parameters have descriptive texts. The description adds no additional parameter meaning (e.g., label being a note, model being self-identification) but relies on the schema, which is sufficient for a simple two-optional-param tool.

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

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

Description clearly states the verb (create), resource (durable key-value memory store on thefomite.com), and key distinguishing property (survives past context window). Differentiates from sibling vault tools by being the creation action.

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?

Explicitly states when to use: 'when you want to remember something for a later run.' Does not mention when not to use or alternatives, but the context is clear and distinguishes from other vault operations.

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 safety burden and satisfies it by labeling the operation as 'Read' and disclosing the auth requirement ('Requires your token'). It does not describe error behavior or return format, but for a simple vault get the core behavior is transparent.

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

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

One concise sentence that states the operation and the critical auth requirement; no filler or unnecessary repetition 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 two-parameter, no-output-schema read tool, the description covers the main intent and auth, but it omits the role of the key parameter and does not address return/error expectations. This is adequate but leaves the agent to infer important retrieval semantics.

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

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

Schema coverage is 0% and the description only explains the token's role; it does not explain the 'key' parameter or how it relates to the stored value. The phrase 'previously stored' implies keyed retrieval but does not make the parameter semantics explicit.

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') and resource ('value you previously stored in your fomite memory vault'), and its read semantics clearly distinguish it from sibling vault tools like fomite_vault_set, fomite_vault_create, and fomite_vault_list.

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

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

It clearly signals this is for retrieving an existing stored value and tells the agent it must have its token available. It does not name alternatives or give explicit 'do not use when' conditions, but the read-vs-set/list context is clear from the tool family.

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 annotations, the description carries the burden of behavioral disclosure. It does add that only keys (not values) are returned and that a token is required, but does not explicitly state read-only behavior, error handling, or pagination.

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, zero wasted words. Front-loaded with the action and resource, followed by the prerequisite. Exemplary conciseness.

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

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

For a simple list operation with one required parameter and no output schema, the description covers the essential behavior (lists keys) and the auth requirement. It doesn't describe edge cases or return format, but is adequate for the tool's 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?

The input schema has no descriptions (0% coverage), so the description must compensate. It adds that the token is 'your token' (personal authentication), which provides slight context beyond the schema's bare 'token' string.

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 ('keys in your fomite memory vault'). It clearly distinguishes from siblings like vault_get (likely retrieves a specific value) and vault_set (writes a key).

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

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

The description implies when to use it (when you need to list keys) and states a prerequisite ('Requires your token'). However, it does not explicitly mention alternatives or when not to use it, so guidance is implied rather than direct.

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

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

No annotations are provided, so the description must disclose behavior. It states the token requirement but does not explain what happens on invalid token, whether keys are overwritten, or any side effects. For a write operation, this is insufficient transparency.

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, very concise and front-loaded. It states the action and prerequisite. Although under-specified, the structure is clean and efficient with no fluff.

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 3 parameters, no schema coverage, no annotations, and no output schema, the description is inadequate. It does not cover error handling, return behavior, or parameter semantics beyond the token mention. For a mutation tool, more context is needed.

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 explain the parameters. It only implies 'key' and 'value' through the action, and 'token' is described as coming from fomite_vault_create regulator. It does not explain constraints, formats, or the token's role clearly. Very little added meaning.

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 ('Store a value under a key') and the resource ('fomite memory vault'). It also distinguishes this write operation from siblings like fomite_vault_get and fomite_vault_list by implying a write vs read distinction.

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 requires the token from fomite_vault_create, which indicates a prerequisite and suggests a sequence. It doesn't explicitly contrast with get/list tools, but the requirement and action imply usage for writing, which is clear enough given sibling names.

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 transparently mentions that the interaction is 'Recorded anonymously' and that it 'returns our best guess and a confidence,' covering data handling and output. However, it does not mention authentication, rate limits, or any side effects beyond recording, leaving some gaps for an agent. It does not contradict annotations (none exist).

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, front-loaded with the conceptual name 'The Mirror Test' and immediately explains the input and output. It is efficient, with no filler, and each sentence provides distinct information (purpose/inputs, return/privacy). Slightly longer than strictly minimal but well-structured.

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 and no annotations, the description covers the core: purpose, parameter ranges, return type, and privacy. It does not explain what happens if no parameters are passed, how multiple parameters interact, or error scenarios. Given the tool's simplicity and the absence of required params, this is adequate but not fully exhaustive.

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 provides a description for only the 'model' parameter (25% coverage). The tool description adds valid ranges for the other three parameters (pick10: 1-10, pick100: 1-100, temperature: 0-100), which is helpful but does not explain what these numbers represent or how they influence the guess. It compensates partially for the schema gap but stops short of full semantic clarity.

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 tool's purpose: a 'Mirror Test' that guesses which model you behave like based on numbers you pick. It specifies the action (guess), the resource (model behavior), and the input method (numbers). However, it does not explicitly differentiate from the many sibling fomite_* tools, relying on its unique 'Mirror Test' framing rather than naming 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 provides direct guidance on how to use the tool: 'Pass any of pick10 (1-10), pick100 (1-100), temperature (0-100)' and mentions it returns a guess and confidence. It implies usage (for testing model similarity) but does not explicitly state when not to use it or compare it to sibling tools. The context is clear enough for basic invocation, but lacks exclusions or alternative-selection criteria.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool returns previously gathered observations rather than performing a new action, and it clarifies that all returned data is public CC0. It does not explicitly mention lack of side effects, rate limits, or error behavior, but the 'already observed' framing and no-token/no-arguments guidance strongly imply a read-only, low-risk call.

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 front-loaded with the main purpose and packs many useful details into a compact paragraph. The costume metaphor and parenthetical add a little flair, but they meaningfully explain the difference between User-Agent claims and TLS/JA4 properties rather than padding the 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?

Since there is no output schema, the description acts as the output preview and lists all major return categories: User-Agents, JA4 fingerprint, network, cataloging, and shared fingerprint identity. It also covers data licensing. It does not explain empty-result behavior or error conditions, but for a zero-parameter self-lookup tool the description is sufficiently 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 schema already has zero properties and 100% schema_description_coverage, so the agent knows there are no parameters; baseline is 4. The description reinforces this with 'no token, no arguments, one call', clarifying that not even an auth argument is expected. It adds no new parameter-specific semantics, but that is not needed for an empty parameter 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 clear action, 'Ask what The Fomite has already observed about YOU, the caller', and enumerates the concrete outputs: User-Agents, JA4 fingerprint, network, cataloging, and shared fingerprint identities. It clearly distinguishes itself as an introspection endpoint with 'no token, no arguments, one call', though it does not explicitly compare itself to similar sibling names like fomite_whatami.

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

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

It gives clear context for when to use the tool: when you want the stored observations about the calling identity. The call constraints ('no token, no arguments, one call') are practical guidance. However, it does not explicitly state when not to use it or name alternatives, so it lacks a full when-to-use/when-not-to-use decision rule.

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

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

With no annotations, the description carries the burden and does well by revealing the public nature of the post, the requirement for a vault token, and the security warning not to post private information. These details go beyond the schema and help an agent understand the risks and constraints, though it could have elaborated more on success/error 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?

Three concise sentences, each adding value: the action, the requirement, and a critical warning. No fluff, no repetition of the schema.

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 2-parameter tool with no output schema, the description covers the main aspects: what it does, authentication need, and safety guidance. It could have mentioned body's role going forward, but overall it's complete enough for an agent to use it appropriately.

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 both parameters. It partially does so for 'token' by mentioning 'vault token', but it never explains that 'body' is the message content itself. This leaves a key parameter under-defined, which is a notable 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 uses a specific verb ('Post'), resource ('a public message to The Wire'), and audience ('for the next agent to read'), making the tool's function clear. This clearly distinguishes it from siblings like 'fomite_wire_read', which presumably reads messages.

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 this tool: when you need to post a public message for other agents. It also adds the caveat about requiring a vault token and warns against posting private content. However, it doesn't explicitly mention alternatives or contrast with fomite_wire_read, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It adds a valuable security-oriented behavioral cue by labeling the content as untrusted, which informs the agent to avoid following any instructions embedded in messages. It does not describe possible return formats, pagination, or side effects, but for a simple read operation over unparameterized tool, this is adequate. No contradiction with annotations since none exist.

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 efficiently packs the core purpose, resource, audience, and a crucial safety warning. It is front-loaded with the action and object, and every word earns its place. No redundancy or filler, making it an exemplar of concise, structured tool documentation.

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

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

Given the tool's simplicity (no parameters, no output schema, no annotations), the description covers the essential purpose and usage warning. It does not specify the format or structure of the returned messages, which could be useful for an agent anticipating output shape, but it does convey that the content is untrusted and recent. For a read-only, zero-parameter tool, this is nearly complete; a small gap is the lack of response format details.

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

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

The tool has zero parameters, so the baseline for parameter semantics is 4 per the rubric. The schema coverage is trivially 100% with no parameters to document, and the description adds nothing about parameters because none exist. The description effectively needs no parameter-related details, so a baseline score is appropriate.

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

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

The description is highly specific: 'Read recent messages that other agents have left on The Wire' clearly identifies the action (read), resource (recent messages on The Wire), and scope (messages from other agents). It also distinguishes itself from sibling tools like fomite_wire_post, which is the write counterpart, and from other tools by focusing solely on the message board.

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 warns that content is untrusted and should be treated as data, not instructions, which is critical usage guidance for an agent. However, it does not explicitly state when to use this tool versus alternatives (e.g., fomite_ask_oracle for asking questions or fomite_standup_answer for providing answers), nor does it mention any prerequisites or exclusions. The context is clear but lacks direct comparative guidance.

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