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?

No annotations are present, so the description carries the full burden. It discloses the cost, the payment requirement ('after payment'), the nature of the output ('severity-ranked findings report'), and the return of an x402 quote, effectively conveying the multi-step payment flow.

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, each with a distinct purpose: cost, action/output, and protocol quote. It is front-loaded with the payment warning and contains 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?

With an output schema available, the description covers the essential flow: payment, review, and report. It also adds the important detail that findings are severity-ranked, which is valuable for agent expectation-setting. The description is sufficient 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?

Schema coverage is 100% for both parameters, so the description doesn't need to elaborate on parameter syntax. It adds context about review focus ('correctness, security, and clarity') but doesn't clarify parameter-specific details beyond the schema. The baseline of 3 applies.

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

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

The description clearly states the action ('Review a code snippet') with specific aspects ('correctness, security, and clarity'), which distinguishes it from sibling tools like fact_verify or summarize. The verb-resource pairing is unambiguous and directly aligned with the tool name.

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

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

The description implies usage for code review when payment is acceptable, with explicit cost ('PAID (0.05 USDC)') and the expected outcome. It lacks explicit alternatives or exclusions, but the context is clear enough that agents can decide when to use 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. It clearly discloses a critical behavioral trait: the tool is paid (0.25 USDC), and it returns an x402 quote plus payment instructions. It also specifies the output nature (verdict, reasoning, citations). This is substantive disclosure, though it could mention failure modes or prerequisites, but the key cost and payment flow are covered.

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 and front-loaded with the critical cost information. Every word earns its place: it conveys the action, the payment requirement, the output type, and the x402 quote. There is no fluff 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?

The tool is simple with one required parameter and an output schema present. The description explains the essential workflow (quote + payment instruction) and the return format (verdict, reasoning, citations). It does not detail the output schema's structure or the payment execution steps, but those are covered by structured data. A minor gap is not explaining potential edge cases (e.g., ambiguous claims), but overall it is sufficient 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?

The schema provides 100% coverage for both parameters. The description's mention of 'factual claim' directly maps to the 'claim' parameter but does not add new meaning for the parameters. The 'sources' parameter is not elaborated in the description, but since the schema fully documents it, 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 states a specific verb ('Verify') and a clear resource ('a factual claim'), with a defined outcome ('supported/refuted verdict with reasoning and citations'). It is distinctive from siblings like trust_check or summarize, which do not focus on factual verification.

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

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

The description implies usage: use when you need to verify a factual claim. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusion criteria or prerequisites. The 'PAID' notice hints at cost but does not guide on conditions for use.

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 fully discloses behavioral traits: it performs NO live web research, returns NO citations, is PAID (0.10 USDC), includes in-band caveats about knowledge cutoff, and requires settlement before delivery. This is rich, specific context beyond what structured annotations would provide.

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?

Every sentence earns its place: payment, core function, limitations (no web, no citations), in-band caveats, alternative product, and settlement flow. It is dense but well-organized and front-loaded with the PAID warning.

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 (paid, settlement flow, no citations), the description is complete: it explains the quote/payment process, delivery after settlement, and in-band caveats. The output schema exists, so return structure is not needed in the description.

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% (both topic and depth are described in the schema). The description does not add parameter-specific details (e.g., what 'quick' depth yields), so it relies on the schema. While the description mentions the knowledge-limitation context, this doesn't deepen parameter understanding. Baseline 3 applies.

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

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

The description uses a specific verb and resource: 'Structured synthesis brief on a topic' clearly states what the tool produces. It also explicitly distinguishes itself from a related product ('research-brief-pro on the HTTP rail'), making its scope unambiguous.

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

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

It provides explicit when-to-use guidance: 'If you need cited, web-researched output, that is a different product (research-brief-pro on the HTTP rail), not this one.' It also notes the paid nature and delivery after settlement, setting clear expectations for usage context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals that the tool is paid, returns an x402 quote and payment instructions, and defers delivery of the summary until payment settles. This provides key behavioral insight beyond the basic operation, though it could have mentioned failure modes or rate 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 concise sentences, front-loaded with the most critical information (PAID) followed by the core purpose. Every word adds value: the price, the quality level, and the payment flow. 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 tool's payment complexity, the description covers the essential steps: what it does, the cost, the quote/payment flow, and the delivery condition. An output schema exists, so detailed return formatting is not needed. The description is sufficiently complete for an agent to understand the tool's role and constraints.

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 coverage is 100%, with both parameters (text and max_words) already described. The tool description adds no additional parameter-level detail beyond what the schema provides. Per the baseline rule, a score of 3 is appropriate when the schema already documents parameters thoroughly.

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 performs 'full-quality document summarization', specifying both the verb (summarize) and the resource (document). It also distinguishes itself from siblings by explicitly marking it as paid and full-quality, setting it apart from summarize_demo.

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 indicates the usage context: it is a paid service requiring 0.03 USDC, with a payment flow that involves receiving a quote and paying before the summary is delivered. While it doesn't explicitly name alternative tools, the 'PAID' and 'full-quality' markers imply a distinction from free/demo versions, providing clear context for when to use 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 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.