agent-embassy

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

No annotations exist, so the description carries the full burden. It discloses mandatory x402 payment, exact cost, signed-receipt output, idempotent retries returning the original receipt, ephemerality warning, and live-vs-dev wallet behavior. This is far richer than simply saying 'history query'.

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 and dense, but monetization is stated three separate times ('paid... $0.25 per query via x402', 'MONETIZED VIA x402', and 'with an x402 payment ($0.25...)'). The inline schema is useful but makes it long; some redundancy could be trimmed.

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?

Covers the full call path: endpoint, method, payment, parameters, and return shape (bounded/timestamped series embedded in a signed receipt), plus an ephemerality warning. No output schema exists, so a concrete example of the receipt structure would be the main improvement; as-is it is sufficient for 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 structured schema has 0% description coverage, but the description embeds a JSON schema that documents every parameter: gpu with example and omission semantics, limit with range/default/order, idempotency_key retry behavior, and agent_wallet dev-mode caveat. It fully compensates for the schema's lack of 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?

First sentence identifies the resource (Embassy's market-intelligence log of vast.ai public asks) and the operation (paid time-series history). It enumerates available series (per-GPU cheapest/median/offer-count or whole-market) and temporal bounding, allowing an agent to distinguish it from compute_spot_prices.

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

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

The description gives clear context: it is a paid historical query and asks are ephemeral, so re-observe before decisions. However, it never explicitly names sibling alternatives or states 'do not use this for current spot prices or alerts'; the distinction is only implied by 'market history'.

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 present, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only, free, derived (not pushed), has no webhook system, and that the alert log is the snapshot log. This transparently sets expectations about side effects and underlying data source.

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 core purpose ('FREE read-only price move alerts'), followed by the mechanism and a clarifying note about the derived nature. Each sentence adds distinct value and there is no filler or redundancy.

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

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

For a read-only tool with no output schema, the description explains the source, threshold, and derivation, but it does not describe the output format (e.g., fields in an alert) or how the limit parameter affects results. Since the schema already documents the parameters, the main missing piece is return structure, which could matter for an agent parsing results.

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 both parameters (gpu and limit) are already documented in the schema. The description mentions 'per-GPU' and 'cheapest-price', which aligns with the gpu parameter, but it adds no new semantic detail beyond what the schema already provides. 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 purpose: it computes and flags price move alerts larger than 10% for per-GPU cheapest prices in the P2P GPU market. This is specific and distinguishes it from likely siblings like compute_spot_prices and compute_history, though it never names those alternatives explicitly.

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

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

No guidance is provided on when to use this tool versus the siblings. It does not mention alternatives such as compute_spot_prices for current prices or compute_history for historical data, and it gives no exclusions. The only hint is 'read-only' and 'free', which is informational but not a decision rule.

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

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

With no annotations provided, the description carries the full burden. It explicitly states 'FREE read-only' (no cost, no side effects), clarifies that listings are 'ephemeral asks, not delivered-cost guarantees', and notes that bid pricing is 'interruptible spot, cheapest but preemptible'. It also discloses the provenance and observation type. This is thorough and goes beyond a simple function summary.

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 well-organized. It front-loads the core purpose, then explains sources and types in a structured way, and ends with a caveat. Every sentence adds information relevant to selecting and invoking the tool. 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?

For a read-only market observation tool with no output schema, the description covers the return format (USD/GPU-hr, provenance), sources, pricing types, defaults, and the ephemeral nature of data. It does not discuss error handling or no-result scenarios, but these are minor for such a tool. Overall it provides enough context for an agent to use it 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% and each parameter is described in the schema, the description adds valuable semantic context. For example, it explains that 'bid' is interruptible and preemptible, that 'reserved' is only for vast-ai, and it describes the nature of each source (live asks, daily survey, manual snapshot). This enriches the schema definitions and helps the agent choose appropriate 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 the tool's function: it observes the P2P GPU compute market across multiple sources and returns cheapest rentable offers per GPU class. It names the resource (P2P GPU compute market) and the verb (observe/return), and the mention of 'spot prices' in the tool name aligns with the description. While it doesn't explicitly name sibling tools, its purpose is distinct and unambiguous.

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

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

The description explains what the tool does and details the sources and pricing types, but it does not explicitly state when to use this tool over alternatives like compute_history or compute_price_alerts. The 'FREE read-only observation' hints that it's for snapshot queries, but there is no direct comparison or exclusion. Since the criteria require explicit when/when-not guidance, this is a moderate gap.

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 burden and delivers rich behavioral detail: payment via x402 ($1.00 USDC), human review within 24h, encrypted blob that the Embassy cannot read, idempotency behavior ('retries return the original receipt'), and an acceptance test for hash verification. It also discloses side effects (one-time registration, storage) and a dev-mode vs live-mode difference for agent_wallet. This exceeds what annotations would typically 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?

The description is front-loaded with purpose and scoping, but it redundantly repeats the entire input schema verbatim inside the description, which duplicates the structured schema and adds length without new information. The parameter descriptions could have been presented more tersely. Still, the critical information (payment, safety, idempotency) is efficiently conveyed.

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, encryption, review workflow) and lack of output schema, the description is quite thorough: it explains the endpoint, payment method, the review queue, idempotency, and a verification test. It does not explicitly describe error cases or the receipt's structure, but it provides enough for an agent to invoke it correctly and understand the expected outcome.

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

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

Schema description coverage is 0%, but the description gives meaningful per-parameter explanations for all six parameters: contact_name, contact_handle, quorum_rules, recovery_blob (opaque, client-encrypted), idempotency_key (client-generated UUID, retries return original receipt), and agent_wallet (dev mode only, live mode uses payer wallet). This significantly adds value beyond the bare schema definition.

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 leads with a specific verb and resource: 'Register a dead-man's recovery configuration for your AI agent.' It clearly states what the tool does (stores a client-encrypted recovery blob and quorum rules, queues for human review) and distinguishes it from the unrelated siblings (compute_spot_prices, verified_check). The scope limitations ('v1 scope is storage + review only') further clarify its 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 strong usage context: it explains the one-time registration flow, the payment requirement, and explicitly states what the tool does NOT do ('no quorum tooling, triggers, or automated recovery exist yet'). However, it does not explicitly frame 'use this when...' or name alternative tools, though siblings are unrelated. It gives enough exclusions to guide an agent away from misuse.

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 succeeds: it discloses server-side fetching, one-time fetch behavior, signed receipt contents, per-condition pass/fail reporting, idempotency semantics, and monetization. It also flags that the tool is not callable for free and is fully automated. There is no contradiction with annotations.

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 core purpose and organized into clear sections: behavior, receipt, monetization, endpoint, and parameters. It is somewhat longer than necessary because the inline schema duplicates the structured input schema and there is promotional phrasing, but every substantive piece of information 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?

Despite having 7 parameters, no output schema, and no annotations, the description is remarkably complete: endpoint, payment mechanism, condition types, receipt fields, public-host restriction, idempotency behavior, and dev-mode behavior are all covered. An agent has enough information to invoke the tool correctly and understand what the receipt will contain.

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 structured schema has 0% description coverage, but the description embeds a complete inline schema with meaningful explanations for every parameter: URL restrictions, expectation semantics, default status 200, JSON path format, idempotency behavior, and dev-mode-only meaning of agent_wallet. This fully compensates for the structured schema gap.

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

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

The opening sentence names a specific action ('Verify a web claim') and a specific deliverable ('signed, re-checkable Outcome Receipt'), and the second sentence explains the three supported check types: HTTP status, body substring, and JSON field value. This clearly distinguishes it from the unrelated sibling tools compute_spot_prices and register_recovery.

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

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

The description gives clear operating context: the tool is paid via x402 at $0.15, accepts HTTPS URLs only, refuses private IPs, is fully automated, and has no human review. It does not explicitly name alternatives or state when not to use it, but the intended use is unambiguous given the unrelated siblings.

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