Mnemos — memory as a service

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

No annotations are provided, so the description carries the full burden. It adds useful behavioral context: 'FREE' suggests no cost to call, and 'Discover' implies a read-only catalog listing. However, it does not explicitly state 'read-only' or 'no side effects', which would be stronger 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?

Two sentences with no filler. The first sentence states purpose and outputs; the second gives a clear directive. Every word adds value.

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

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

The tool is simple (zero parameters) and has an output schema. The description covers what the catalog includes and how to pay, as well as the recommended calling order. Siblings are unrelated, so no additional 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?

The tool has zero parameters, so the schema provides complete coverage. The description correctly avoids mentioning parameters. Baseline 4 is appropriate for a zero-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?

The description uses a specific verb 'Discover' and identifies a clear resource: the full Agora x402 service catalog. It lists specific content: prices in USDC and settlement parameters (network, asset, payTo). This differentiates it from all sibling tools, none of which mention catalogs or payment.

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 instructs 'Call this first to see what you can buy and how to pay', providing clear when-to-use guidance. Since siblings are entirely different (code review, embeddings, summarization, etc.), no exclusions are necessary, but the directive covers the main use case.

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

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

With no annotations provided, the description carries the disclosure burden. It explicitly mentions the payment requirement (0.25 USDC), the x402 quote, and that the report is delivered after payment. It does not cover privacy or rate limits, but the essential workflow 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?

The description is two sentences, front-loaded with the payment information, and contains no redundant wording. Every phrase adds value: cost, purpose, output, and the quote/report flow.

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

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

The tool has a simple schema and an output schema, so the description need not explain return structure in detail. It covers the payment flow, the review focus, and the nature of the results. Minor missing context (e.g., language support specifics) is not critical.

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%, with both 'code' and 'language' fully described. The tool description adds generic context ('code snippet', 'correctness, security, clarity') but does not provide additional parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Review a code snippet for correctness, security, and clarity' and specifies the output ('severity-ranked findings report'). It distinguishes itself from sibling tools like summarize or fact_verify by focusing uniquely on code review.

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 context: it is a paid code review service that returns a quote and then a report after payment. It does not explicitly mention when not to use it or name alternatives, but the purpose is distinct enough that a user can infer when to invoke it.

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 transparency burden and does so excellently. It discloses the cost (0.005 USDC), the local execution environment, truncation at 6000 chars, max batch of 32, and the two-step flow (quote + payment, then result delivery). This goes well beyond a basic functional description and preempts questions about payment and data limits.

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 long and front-loaded with the most critical alert: 'PAID (0.005 USDC)'. Each clause carries unique information (model, limits, payment flow, output shape). No fluff or repetition. This is a model of efficient, structured 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 complexity (payment-gated, batch processing, truncation), the description covers the essential operational flow: the agent receives a quote and payment instructions, then receives {model, dims, vectors} after payment. It does not explain the x402 payment protocol mechanics, but with an output schema present and the sibling context, this is a minor gap. Overall, the description is well-rounded for a paid API.

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% (the sole parameter 'texts' is described as 'List of strings to embed (max 32)'). The description adds value by specifying a 6000-character truncation limit per text, which is not in the schema. It also reinforces the max 32 with an additional usage note, and mentions output dimensions implicitly via 'dims'. This exceeds the baseline 3 for high 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 clearly states the tool's function: 'Text embeddings via local Jetson Ollama' with a specific model (nomic-embed-text). It also includes key limits and payment context, distinguishing it from all sibling tools which address different tasks (search, summarization, notarization, etc.). The verb 'embed' and the resource 'batch' are 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 provides clear context: this is a paid tool requiring x402 quote + payment before output delivery. It mentions batch size and truncation limits, which help an agent decide if input fits. While it does not explicitly name alternatives or state when not to use it, the distinct purpose and payment requirement make usage conditions clear. This aligns with 'clear context, no exclusions'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the paid nature of the call, the return of verdict/reasoning/citations, and the x402 quote/payment instructions. This covers cost and high-level output behavior, though it omits details on failure modes or limitations.

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 with no wasted words. It front-loads the payment warning, then states the purpose, and finally summarizes the return flow. 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?

Given the tool's simplicity (2 params, flat schema) and the existence of an output schema, the description adequately covers the core function and high-level return. It could mention prerequisites or latency, but it is complete enough for an agent to understand the tool's role.

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 already provides clear descriptions for both parameters (claim and optional sources), achieving 100% schema coverage. The description does not add meaning beyond what the schema offers, so the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'verify' with the resource 'factual claim' and clearly states it returns a supported/refuted verdict with reasoning and citations. This distinguishes it from sibling tools like trust_check by focusing on fact verification with a binary verdict outcome.

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 over alternatives such as trust_check or research_brief. While it notes the tool is paid (0.10 USDC), it does not clarify under what circumstances the cost is justified or when a different tool should be chosen.

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?

Since no annotations are provided, the description carries the full burden. It discloses the cost ('PAID (0.005 USDC)'), the payment mechanism ('Returns an x402 quote'), and the bi-temporal semantics that prevent hindsight leakage. These are significant behavioral traits beyond what the schema offers, though it stops short of mentioning rate limits or authentication requirements.

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

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

The description is three sentences, front-loaded with the cost and primary function. It packs essential details (use cases, uniqueness, return quote) without wasted words. Every sentence contributes distinct value, earning a high score for efficiency.

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

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

This is a complex bi-temporal tool with 5 parameters and an output schema. The description explains the core concept, cost, use cases, and return type (x402 quote). Parameter details are covered by the schema, so the description complements rather than repeats. The completeness is high for a novel read operation.

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% (baseline 3), but the description adds conceptual meaning to tx_time and valid_time via the core question: 'what did the store BELIEVE at `tx_time` about what was TRUE at `valid_time`?' This explains the temporal axes beyond the schema's simple ISO8601 descriptions. The description also hints at the role of key/query in context, though it does not elaborate on k.

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: a bi-temporal read that answers what the store believed at tx_time about what was true at valid_time. It uses a specific verb ('Answers:') and distinguishes itself from sibling tools by claiming 'the thing no other memory service on this mesh sells.' Specific use cases like replaying decisions and auditing corrections further clarify purpose.

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

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

The description provides explicit usage scenarios: 'replay an agent's decision', 'audit corrections', and 'distinguish "we were wrong" from "the world changed"'. It implies when not to use alternatives by claiming uniqueness, though it does not explicitly name sibling tools or state exclusion conditions. This provides clear context without formal 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 full responsibility. It discloses the paid nature (0.005 USDC), prompt-injection exclusion, deduplication to most-recent belief, budget-packing behavior, and the ability to assemble as of a past time. These are non-obvious behaviors 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?

The description is front-loaded with the cost warning and packs multiple behavioral details into a compact five-sentence structure. No filler or redundant phrases.

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

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

Given the tool has an output schema and the description covers cost, filtering, deduplication, time-travel, and return format, it is sufficiently complete. It also mentions returning an x402 quote, which is a cost-related operational detail. Without annotations, this description compensates effectively.

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 does not add substantial new meaning beyond what the schema already provides for query, k, as_of, and max_chars. It mentions max_chars in the context of budget-packing and as_of for time-travel, but these are already described in 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 purpose: 'searches your memories, dedupes to the most-recent belief per key, budget-packs them into max_chars, and returns a ready-to-paste context block plus structured provenance.' This clearly differentiates it from sibling tools like mnemos_search by focusing on pre-completion context assembly with deduplication and budget-packing.

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 opening 'The endpoint to call right before a completion' establishes a clear when-to-use context. It also notes optional 'AS OF a past time,' implying historical assembly. However, it doesn't explicitly name alternative tools or state when not to use it, 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, the description carries the full burden and does well: it discloses cost (0.50 USDC monthly floor), the auth model (payment is identity), the one-time display of the tenant key, and that it returns an x402 quote. Minor gaps remain (e.g., refund/cancellation), but the critical behavioral traits are clearly stated.

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 compact sentences with no filler. It front-loads cost and purpose, then explains the payment flow and one-time key behavior. 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?

Given one optional parameter and an output schema, the description explains the core flow (quote -> payment -> key) and the tool's purpose sufficiently. It doesn't describe every edge case (e.g., what happens if payment fails), but for the complexity level it is complete enough.

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 the single 'label' parameter is already described. The description adds some context (tenant key, namespace) but does not significantly deepen the meaning of the label parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description opens with 'Mint your own fully isolated bi-temporal memory namespace,' using a specific verb (mint) and clear resource (namespace). It also clarifies what makes this tool distinct from siblings (payment-as-identity provisioning), so purpose is both specific and differentiated.

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

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

The description clearly frames when to use this tool: when you need an isolated namespace by paying via x402 without signup or email. It doesn't explicitly list alternatives, but the context is strong enough to infer that this is for provisioning while other mnemos_* tools are for storing/searching/retrieving.

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 takes on the burden. It discloses that the tool is free and does not access tenant data, clarifying its safety profile. It doesn't explicitly state read-only, but the 'no payment, no tenant data' wording conveys non-destructive behavior. The output format is covered by the output 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?

The description is a single paragraph but dense with relevant info. It is front-loaded with 'FREE' and a clear call to action. Could be slightly more scannable with bullet points, but 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 no-parameter info tool with an output schema, the description fully covers the purpose, content, and safety, and gives usage timing. It is complete for its simplicity.

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 baseline is 4. The description adds relevant context (no payment, no tenant data) but no parameter-specific semantics are needed.

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

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

The description clearly identifies the tool as an informational resource about Mnemos-as-a-Service, detailing specific topics (bi-temporal contract, tenant isolation, limits, pricing, worked example). It distinguishes itself from sibling tools by focusing on pre-purchase learning rather than operations like store/search/provision.

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 instructs 'Call this first' and frames usage as a pre-purchase step, providing clear context for when to use this tool versus actual service tools. While no alternatives are named, the directive is unambiguous.

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 transparency burden and excels: it discloses the cost, ranking algorithm (cosine similarity with nomic-embed-text), local computation, privacy guarantee (raw vectors never returned), and the payment flow. This is far more than typical and gives the agent a complete behavioral picture.

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

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

The description is tightly packed into two sentences, with the most critical operational detail (cost) front-loaded. Every clause adds value: methodology, privacy, and payment processing. There is 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?

Given the presence of an output schema, the description need not cover return values, and it fully covers the remaining aspects: purpose, payment, algorithm, privacy, and execution steps. For a tool of this complexity, it is complete and provides all necessary context for safe 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 input schema covers all parameters with 100% description coverage, so the baseline is 3. The description does not add additional parameter-specific semantics; it only gives context about 'current beliefs' and the payment workflow, which does not materially enhance understanding of the query, k, or kind parameters.

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

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

The description clearly states a specific verb ('search') and resource ('your CURRENT beliefs'), which immediately distinguishes it from sibling tools like mnemos_store or mnemos_provision. The mention of 'CURRENT' also differentiates from historical tools like mnemos_as_of, and the semantic nature is 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 provides clear usage context: this tool is for semantic search over current beliefs, and it includes payment instructions (x402 quote, X-TENANT-KEY). While it does not explicitly name alternative tools or state when not to use it, the emphasis on 'CURRENT' implies it is for current-state queries, which is sufficient 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 and excels at it. It discloses the cost (PAID 0.01 USDC), the non-destructive nature of supersedes, the distinction between world time and system time, the server-stamped timestamps, and the required X-TENANT-KEY header, all of which are not visible in 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?

The description is dense but every sentence contributes: it starts with the cost, then states the core purpose, and follows with essential behavioral details. It is front-loaded and structured logically, with no redundant content.

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

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

Given the tool's complexity (bi-temporal semantics, payment, headers) and the presence of an output schema, the description covers all critical aspects: purpose, cost, append-only behavior, parameter semantics, authentication, and return value. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Although schema coverage is 100%, the description adds significant semantic value. It explains the behavioral implications of 'supersedes' (marks prior belief as no longer held without destruction) and clarifies that valid_from/valid_to describe truth in the world, with backdating allowed. This goes beyond the schema's basic field descriptions.

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: 'Store a memory in your isolated bi-temporal namespace.' It uses a specific verb and resource, and the detail about append-only and supersedes distinguishes it from sibling tools like mnemos_as_of and mnemos_search, which are query-oriented.

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 context for when this tool is appropriate (storing memories, updating via supersedes) and even references mnemos_as_of for querying past states, but it does not explicitly list alternative tools or state when not to use this tool. The guidance is implied rather than fully explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the cost (PAID 0.10 USDC), the tamper-evident nature of the output, and the payment-before-signed-record flow. It does not cover error cases or reversibility, but the key behavioral traits are clearly 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?

The description is two sentences long and front-loads the critical information: cost, action, and deliverable. Every phrase adds value—payment amount, tamper-evident, sha256 digest, signed timestamp, and the payment workflow. No fluff or redundant content.

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

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

The description covers the purpose, cost, output details, and workflow, which is sufficient for a simple one-parameter tool. An output schema exists, so return values are partially handled, but the description still summarizes the output. It lacks edge-case handling but is otherwise complete 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 already provides a description for the single 'content' parameter ("The content to notarize.") which fully covers its meaning. The tool description adds no additional parameter-level details beyond mentioning the sha256 digest, which is more about output than input validation. With 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool produces a tamper-evident notarization record with sha256 digest and signed timestamp for a piece of content. This specific verb+resource combination distinguishes it from sibling tools like trust_check or fact_verify, which serve different purposes.

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

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

The description provides clear context on when to use the tool: to notarize content in exchange for payment (0.10 USDC). It also explains the workflow with the quote preview including the sha256 digest before payment. However, it does not explicitly mention alternatives or when not to use it, so it falls 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 behavioral disclosure. It clearly discloses that the tool is paid, returns an x402 quote and payment instructions, and delivers the brief only after settlement. This adds 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?

The description is concise and front-loaded with the most important fact (PAID). Two sentences convey the core purpose, payment flow, and delivery mechanism without any 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 presence of an output schema covers return-value details, and the description explains the payment and settlement process adequately. It could mention what happens after delivery or any prerequisites, but overall it is complete for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add new parameter-level details beyond what the schema provides, but it reinforces the purpose of the 'topic' parameter through the overall tool description. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: producing a structured, cited research brief on a topic. It uses a specific verb and resource, and the paid, x402-based delivery distinguishes it from sibling tools like summarize and fact_verify, though it does not explicitly name any 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 when to use the tool (when you need a paid, cited research brief) and provides context about the payment flow, but it does not explicitly state when not to use it or which sibling tools might be alternatives. This is acceptable but not explicit.

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

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

With no annotations, the description carries full responsibility. It clearly discloses the payment requirement (0.05 USDC), the x402 quote + payment instructions, and that the summary is delivered only after payment settles. This is strong transparency for the tool's key behavioral traits, though it doesn't detail the x402 protocol or any additional 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 a single, front-loaded sentence that conveys payment, quality, and delivery flow with zero wasted words. It is efficiently structured and immediately highlights the most important facts.

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

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

The description covers the essential workflow (quote, payment, delivery) and has an output schema to explain return values. It doesn't explain the x402 quote in detail, but that is an external protocol. Sibling tools exist but no comparison is made, slightly reducing contextual completeness for a tool with this level of 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 covers both parameters (text and max_words) with descriptions, so the baseline is 3. The description adds no extra meaning about parameter usage, defaults, or constraints beyond what the schema already provides.

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

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

The description clearly states the tool's function: "Full-quality document summarization." It specifies a verb ('summarization') and resource ('document'), and the 'PAID' marker plus 'Full-quality' distinguishes it from the sibling summarize_demo, which likely offers a demo or lower-quality version.

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 this is the paid, full-quality summary tool, but it does not explicitly state when to use it versus alternatives like summarize_demo or research_brief. The presence of a payment requirement and 'Full-quality' suggests a trade-off, but no direct when/when-not guidance is provided.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that the tool is free, a demo, returns a deterministic extractive summary (first + most-salient sentences, capped ~280 chars), and requires no payment/auth. It also notes the output is a short preview, setting accurate expectations for the demo behavior.

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

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

The description is two sentences, front-loaded with 'FREE' and the demo purpose, followed by precise behavioral details. Every sentence adds value with no fluff or repetition, making it highly efficient.

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

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

The description covers the purpose, usage context, behavioral details, and limitations, while the schema and output schema handle parameter and return format. For a simple one-parameter demo tool with a sibling paid tool, this is complete and self-sufficient.

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 description covers 100% of the parameter (`text`), including the 'any length; only a short preview is returned' caveat. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states it is a free demo of the paid `summarize` tool, returning a tiny deterministic extractive summary capped at ~280 chars. It uses a specific verb ('returns') and resource ('demo'), and distinguishes itself from the sibling `summarize` tool by explicitly noting the demo status and free/no-auth nature.

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 says 'so agents can verify the connector end-to-end before buying,' giving clear context for when to use this demo. It implies the paid `summarize` is for production use, but does not explicitly name it as an alternative or state 'use summarize for real summaries.' The guidance is clear enough for an agent to infer the correct choice.

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 disclosure. It explicitly states that the tool is paid (0.05 USDC), returns a quote and payment instructions, and delivers the combined result only after payment settles. This discloses the monetary cost and the asynchronous payment flow, which are critical behavioral traits beyond basic data retrieval.

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 and front-loaded, starting with the critical cost information ('PAID (0.05 USDC)') before describing the rest. It uses three sentences, each adding meaningful information: the payment/cost, what the probe includes, and the delivery workflow. No redundant or filler content is present.

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 complexity (payment flow, combined data sources) and the presence of an output schema, the description covers all essential aspects: the parameters, the data collected, the cost, and the post-payment delivery. The single parameter is fully described, and the workflow is transparent. The description is complete for an agent to invoke the tool correctly without additional clarification.

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 100% coverage for the only parameter (url), with a clear description. The main description adds minimal extra semantics beyond what the schema already provides (mentioning 'https URL to probe' in the text, but the schema already says 'The https URL to probe (watchtower)'). Since the schema fully documents the parameter, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: a combined trust probe that aggregates bazaar-index stats and a watchtower attestation for a URL. It specifies the action (probe) and resource (URL), and the output includes a quote and payment instructions. This distinguishes it from sibling tools like fact_verify or notarize, which have different purposes.

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

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

The description implies the tool should be used when a combined trust assessment of a URL is needed, with the context of payment. It does not name alternatives or explicitly state when not to use it, but the unique nature of the tool and the clear context ('Combined Trust Oracle probe') provide adequate guidance for an agent to select it appropriately.

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