sebbi.pro - seal every AI decision

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

Annotations already declare openWorldHint=true, readOnlyHint=false and idempotentHint=false, so the agent knows this reaches an external service and mutates state. The description usefully adds that the external service is Stripe and that the link is for card capture plus a per-device subscription, but it omits whether each call mints a new link, whether links expire, and what permissions are required.

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

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

A single tight sentence with no filler; the key outcome (card + subscription) is front-loaded. It is a sentence fragment, but nothing is wasted.

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?

No output schema, 0% parameter coverage, and no explanation of what the returned link looks like or how it is delivered. For a 3-parameter, open-world mutation tool the description leaves too much for the agent to guess.

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% across three parameters, so the description carries the full burden. '50p per device' weakly hints that the devices parameter drives pricing, but email, product, and the accepted values for product are entirely unexplained in both schema and description.

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?

Names a specific resource (a secure Stripe billing link) and its outcome (customer adds card, sets up per-device subscription). The verb is only implied by the title ('Get a billing link'), and there is no explicit differentiation from siblings, but the purpose is unmistakable.

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

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

No statement of when to use this tool, no prerequisites (e.g. must the account already exist via sebbi_create_account?), and no alternatives named. The agent is left to infer the whole triggering context from 'for the customer'.

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?

Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's burden is lighter. It adds useful behavioral detail about what is returned (whether a human typed live, and when), but says nothing about code validity, expiry, or error behavior for bad codes.

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?

A single front-loaded sentence that states the resource, its format, and the returned facts with no padding 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?

With no output schema, the description correctly summarizes the return fields (human-typed, live, timestamp) and the required input format — enough for an agent to call it. Minor gaps remain around invalid-code behavior and how results are keyed.

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

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

Schema coverage is 0%, so the description must compensate for the single undocumented parameter — and it does by giving the expected format HK-XXXX-XXXX. It stops short of stating whether the code is case-sensitive or accepted in other formats.

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?

States a specific verb ("Look up") and resource ("a Human Keys code") with the concrete code format HK-XXXX-XXXX, so the agent knows exactly what is being fetched. It doesn't differentiate itself from sibling lookups like sebbi_verify_chain or sebbi_forever_proof, so it stops short of a 5.

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

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

The description implies the use case (checking whether a human typed text) but never says when to choose this over the sibling proof/verify tools or what prerequisites apply. Usage is inferable but not stated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds genuine context beyond them: validation uses the engine's own validator (so results match publish-time validation) and no publish side effect occurs. It does not disclose what a failed check produces or how errors are surfaced, so it stops short of rich behavioral detail.

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?

A single tight sentence with zero filler, front-loading the verb, resource, and the key constraint (no publishing). Nothing is redundant or padding.

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 validator taking a nested, fully undocumented object and returning no output schema, the description omits what a valid pack looks like and what the check reports back. The absence of any guidance on input shape or outcome makes this inadequate for correct 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?

There is a single required parameter, "pack," with a nested object and 0% schema description coverage, so the schema contributes nothing. The description names the resource type but never describes the pack's structure, required fields, or where to obtain one (e.g., sebbi_pack_reference or sebbi_list_packs), leaving the parameter effectively undocumented.

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

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

States a specific verb (Check) and resource (Signal Pack), plus a meaningful qualifier: the check runs through "the engine's own validator," implying authoritative results. The phrase "without publishing it" implicitly contrasts with sebbi_publish_pack, but the sibling is not named, so differentiation is left partly to inference.

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 clause "without publishing it" implies a check-before-publish workflow and hints at when this tool is preferable to sebbi_publish_pack. However, there is no explicit when-to-use/when-not statement and no alternative tool is named, so usage is only implied rather than stated.

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

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

Annotations declare non-readonly, open-world, non-idempotent, non-destructive, and the description adds two things annotations cannot: the API key is returned, and the agreement is permanently 'sealed into the chain.' It does not address re-invocation behavior (whether a duplicate call creates a second account) or auth requirements, so it falls short of a 5.

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

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

Three short, front-loaded sentences with no filler; purpose comes first, then the gate, then the side effect. 'Seals the agreement into the chain' is slightly jargon-heavy but conveys a real consequence.

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 7-parameter mutation tool with annotations and no output schema, the description covers the essential workflow, return value, and precondition. It omits guidance on the optional billing-related fields (devices, product), which is a minor gap given the schema describes them.

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

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

Schema coverage is only 43%, so the description carries extra burden, and it does clarify the intent behind the two gating fields (terms_version tied to sebbi_terms, customer_agreed tied to the customer's verbal consent). However, it never mentions name, company, devices, or the product enum, leaving four optional parameters to the schema alone.

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?

States a specific verb and resource ('Open a sebbi.pro account') plus the concrete deliverable ('return their API key'), which an agent cannot get from the title alone. It is clearly distinguishable from siblings such as sebbi_terms or sebbi_overview.

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 gates invocation: 'Only call after showing sebbi_terms and the customer saying yes.' This names the prerequisite sibling tool and the human-confirmation condition, leaving nothing to inference about sequencing.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful guarantee that the returned record includes tamper evidence ('proof it has not changed'), but says nothing about the required api_key authentication or any rate/scope limits, so it goes only modestly beyond the 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?

A single front-loaded sentence that enumerates the report's contents with no filler. It is efficient, though the flowery 'machine-proof / key sealed' phrasing costs a little clarity for the same length.

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, two-parameter tool with no output schema, the description does sketch what comes back, which is a plus. But it omits how 'block' identifies the decision and omits the auth requirement, so an agent still lacks what it needs to invoke the tool confidently.

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

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

Schema description coverage is 0% and the description never mentions either parameter. 'The customer's key sealed' faintly hints that api_key is the customer's key, but the required 'block' integer is entirely unexplained in both schema and description, leaving half the inputs opaque.

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

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

The description identifies the resource (a report for a single sealed decision) and enumerates its contents, but the verb is implied by the noun 'report' rather than stated, and the jargon ('machine-proof', 'key sealed') obscures whether this retrieves, generates, or verifies. It does not distinguish itself from near-neighbours such as sebbi_notary_receipt or sebbi_verify_chain.

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

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

There is no statement of when to call this versus the many related siblings (sebbi_notary_receipt, sebbi_verify_chain, sebbi_test_decision, sebbi_forever_proof). No prerequisites, no exclusions, no trigger condition — the agent must infer usage entirely.

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?

Annotations cover the safety profile (openWorldHint=true, destructiveHint=false, readOnlyHint=false), so the agent knows this is a non-read-only open-world call. The description, however, frames the tool as a 'check' ('anyone can check against Bitcoin'), which sits awkwardly against readOnlyHint=false and gives no clue that the call may write/anchor something. It also never explains the api_key requirement, cost, or what is produced.

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?

It is compact — one sentence plus a short imperative fragment — with the artifact definition front-loaded. The terseness crosses into under-specification though: 'Give code or block' is cryptic and the fragment does not clearly state which input wins or that both are optional.

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

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

With no output schema, 0% parameter coverage, and an undisclosed auth parameter, the description is too thin for a tool that appears to interact with an open-world Bitcoin-anchored chain. It should at minimum clarify the action performed, the role of api_key, and what the caller gets back.

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

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

Schema description coverage is 0%, so the description must compensate. 'Give code or block' names two of the three parameters and implies they are alternatives, but adds no format, precedence, or requiredness detail. The third parameter, api_key, is undocumented in both the schema and the description, leaving a real gap.

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

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

The description defines what a 'Forever Proof' is and its verifiability ('anyone can check against Bitcoin without sebbi.pro'), and names the input domains (notary receipt, Human Keys code, block). But the actual operation is never stated as a verb+resource: it is unclear whether the tool generates a proof, fetches one, or verifies one. It partially distinguishes itself from siblings like sebbi_notary_receipt and sebbi_check_human_proof but leaves the core action ambiguous.

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?

'for a notary receipt, a Human Keys code, or any block on the sebbi.pro chain' gives the input contexts in which the tool applies, which implies usage. However, there is no explicit when-not guidance, no prerequisites, and no routing to the many sibling tools (sebbi_verify_chain, sebbi_check_human_proof) that could plausibly overlap.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false, and the description adds genuine context beyond them: routed calls are 'scored, sealed, blocked if needed, and carry an AI-Decision-Receipt header'. That downstream behavior cannot be derived from the annotations. It does not, however, explain what state the call itself creates or why it is non-idempotent, so not a 5.

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, front-loaded with the core action and the returned artifacts, with no redundant restatement of the title. Some marketing-flavored phrasing ('scored, sealed, blocked') is slightly decorative, keeping it out of 5 territory.

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?

There is no output schema, so the description usefully names the two return artifacts (base URL and the stack-specific line). However, it leaves the undocumented 'label' parameter and the non-readonly/non-idempotent nature unexplained, so an agent cannot fully anticipate the call's side effects.

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

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

Schema coverage is only 33% (just the 'stack' example), so the description must carry more weight. It implicitly covers api_key ('their sebbi.pro key') and stack ('the exact line to change for their stack'), but 'label' is never mentioned in either schema or description. Partial compensation for a low-coverage schema warrants a 3.

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?

States a specific verb+resource: routing the customer's OpenAI/Anthropic calls through sebbi.pro and returning a gateway base URL plus the exact line to change. This is far more concrete than a bare 'setup' label and lets an agent recognize it as a gateway-provisioning tool. It stops short of naming how it differs from the sibling sebbi_setup_advice, so it lands at 4 rather than 5.

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

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

Usage is implied by the purpose (use it when you want an app's traffic routed through sebbi.pro), but there is no explicit when-to-use, when-not-to-use, or reference to sebbi_setup_advice as the alternative. The only prerequisite hinted at is holding a sebbi.pro key. Adequate but the agent must infer the trigger condition.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds only the 'published' filter scope; it says nothing about pagination, ordering, result size, or whether the library is exhaustive, which is a meaningful gap for a library-browsing call.

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

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

A single short sentence with no filler, front-loading the action and resource. It is efficient, though the brevity comes at the cost of specification rather than being tight-but-complete.

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

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

With no output schema, no parameter documentation, and no annotations describing return shape, the description leaves the agent without knowing what a pack entry looks like or how 'vertical' affects results. For a discovery tool that feeds downstream calls like sebbi_check_pack, this is under-specified.

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

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

Schema coverage is 0% and the single parameter 'vertical' is a bare string with no description. The description does not mention filtering by vertical or any other argument, so it fails to compensate for the schema gap; only the word 'library' hints that the results are category-organized.

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 gives a clear verb ('Browse') and a specific resource ('the published Signal Pack library'), and the 'published' qualifier scopes it beyond a generic list. It does not, however, distinguish itself from adjacent siblings such as sebbi_pack_reference or sebbi_check_pack, so an agent must infer which one to call.

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

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

There is no statement of when to use this tool versus the many related siblings (sebbi_pack_reference, sebbi_check_pack, sebbi_publish_pack). The word 'Browse' implies discovery, but no context, prerequisites, or exclusions are given.

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?

Annotations already declare openWorld (external Bitcoin anchoring) and non-idempotent write behavior, so the bar is lower, yet the description still adds that the notary is free and that a receipt code plus link is produced per fingerprint (batch semantics). It omits any mention of irreversibility or rate limits, which would have pushed it higher.

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

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

Three short sentences, front-loaded with the core action, then the input contract, then the return shape. No filler or repetition.

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

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

For a three-parameter tool with no output schema, the description covers the action, the input precondition, and the shape of the return (receipt code and link). The unresolved api_key parameter — whose presence is not explained anywhere — is the main remaining gap.

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

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

Schema coverage is only 33% — only 'label' is documented. The description compensates for the most important gap by specifying the digest format (SHA-256, 64 hex) and clarifying that only fingerprints are transmitted, but it says nothing about api_key or the label parameter's role. Partial compensation warrants a 3.

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?

States a specific verb and resource — timestamping SHA-256 fingerprints in Bitcoin via sebbi.pro — with concrete format constraints (64 hex). It implicitly separates itself from retrieval siblings like sebbi_notary_receipt and sebbi_forever_proof by framing this as the submission side, but no sibling is named 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?

'Hash the file or text yourself and send only the fingerprint' is real operational guidance: it tells the agent exactly what input to prepare before calling. There are no stated exclusions or named alternatives, so it stops short of the 5-level routing 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false. The description adds the enumeration of possible states (queued, sent to Bitcoin, confirmed) and the return of a proof link, which is useful output context, but it omits auth needs, latency/confirmation behavior, and why a read-looking status tool is flagged as non-read-only.

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?

A single sentence, front-loaded with the resource and its two code formats, then the returned states. It is efficient with no wasted clauses, though the em-dash stack makes it slightly dense to parse.

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

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

For a one-parameter lookup with no output schema, the description supplies the code formats and the possible result states plus the proof link, which is close to what an agent needs. The main gap is the absence of any usage/routing guidance relative to its many siblings.

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

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

Schema description coverage is 0%, so the schema says only "string" and the description must compensate. It does add value by naming the two accepted formats (NT-XXXX-XXXX or HK-XXXX-XXXX), but it does not explain what the code identifies or which format applies in which case, leaving the single parameter only partially specified.

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 what the tool returns — the status of a notary receipt (NT-XXXX-XXXX) or Human Keys code (HK-XXXX-XXXX), with the specific states queued, sent to Bitcoin, confirmed in a block, plus a link to the Forever Proof. The verb is implicit ("where ... stands" rather than "get status"), and it does not explicitly differentiate from the sibling sebbi_forever_proof, which may also surface the proof link.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as sebbi_check_human_proof or sebbi_forever_proof. The only selection cue is the accepted code formats, which is not enough to route the agent confidently.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value the annotations cannot: the scope of the returned content (every product, its function, its page, its price), which is the only disclosure of return content since no output schema exists.

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

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

Two short sentences with no filler. The content enumeration is front-loaded and "Start here" lands as the final, memorable directive.

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

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

For a zero-parameter, read-only overview with no output schema, the description covers what the tool is for and roughly what comes back. It omits any indication of result size, format, or pagination, but nothing critical for correct invocation is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies a no-argument call.

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 names a concrete resource — every product offered by sebbi.pro — and enumerates what each entry contains (function, page, price). It reads clearly as the catalog/overview entry point and is distinguishable from narrower siblings like sebbi_list_packs or sebbi_pack_reference, though it never explicitly contrasts itself with them.

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?

"Start here" is a direct, actionable usage cue that tells the agent this is the entry-point tool to call first. There is clear context but no exclusions or explicit alternatives (e.g., when to jump straight to sebbi_list_packs instead), 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered by structured data. The description adds real value by inventorying the reference's contents, which is the only signal of what an agent will get back given there is no 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?

Two short sentences, zero waste. The content inventory comes first and the actionable directive ('Read before writing a pack') is front-loaded and closing.

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

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

With no parameters and no output schema, the description is the sole source of information about what this reference contains, and it delivers that along with a usage trigger. It is adequate, though it could note scope limits (e.g., versioning or what the reference does not cover).

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 takes zero parameters, so the baseline is 4 — there is nothing for the description to disambiguate and no schema semantics to add.

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?

States a specific resource — a reference on how Signal Packs are written — and enumerates the concepts it covers (signals, measurements, flags, operators, verdicts). It implicitly separates itself from the write-side siblings like sebbi_publish_pack, but never names a sibling explicitly, so it stops short of full differentiation.

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

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

'Read before writing a pack' gives a concrete trigger condition that tells the agent when to call this rather than proceeding directly to pack authoring. No when-not guidance or named alternatives are given, 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?

Annotations already cover the write/idempotency profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), but the description adds real context beyond them: the pack is 'sealed into the chain' (permanent/immutable record), dated, and attributed to the author, plus it is free. It still omits whether publishing is reversible or what the caller receives back.

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

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

Three short sentences, front-loaded with the action and destination, and each clause adds distinct information (chain sealing, dating/credit, cost). 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?

This is a mutation tool with no output schema and a completely opaque nested-object parameter. The description should explain the pack's shape, prerequisites (account/proof), and what the caller gets back (receipt, hash, id), but covers none of these.

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

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

There is a single required parameter 'pack' typed only as a bare nested object with zero schema description coverage. The description names 'Signal Pack' but never explains its structure, required fields, or format, leaving the agent with no way to construct a valid payload from the definition alone.

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?

States a specific verb ('Publish') and resource ('Signal Pack') with the destination ('open library'), which separates it from siblings like sebbi_list_packs, sebbi_check_pack, and sebbi_pack_reference. It stops short of explicitly naming those alternatives, so differentiation is implied rather than stated.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives. The description does not say whether an account, human proof, or payment step is required before publishing, which matters given the sibling tools sebbi_create_account and sebbi_check_human_proof exist.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that the output is tangible ('working code or a ready prompt'), which is useful. However it says nothing about the api_key parameter, any auth requirement, rate limits, or how the openWorld recommendation is bounded.

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?

A single sentence that front-loads the deliverable (recommend products, step-by-step setup, working code) before the qualifying context. It is dense but not padded. Slight reading cost from cramming inputs onto the same line.

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, open-world advisory tool with no output schema, the description conveys the core value. Gaps remain: the role of the api_key, why 'device' matters, and any signal separating this from sebbi_overview or sebbi_gateway_setup are absent.

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 75%, above the threshold where the schema carries most of the load, so baseline is 3. The description reinforces two parameters (stack via 'Python, Node, Lovable, Zapier, a website builder', and goal via 'what they want to achieve') with extra examples, but it does not address device or the api_key parameter, which is entirely undocumented in both schema and description.

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 names a specific verb pair (recommend products + give step-by-step setup) and a concrete resource (sebbi.pro products, working code or a ready prompt). It is clear what the tool produces. It does not explicitly distinguish itself from nearby siblings such as sebbi_overview or sebbi_gateway_setup, so it stops short of a 5.

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

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

Usage is implied through the input framing ('how the customer builds... and what they want to achieve'), which tells the agent the context that suits this tool. There is no explicit when-to-use, when-not-to-use, or named alternative to route against, so it remains at an implied level.

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?

Annotations already declare readOnly=false, idempotent=false, destructive=false and openWorld=true, so the safety profile is largely covered. The description adds the ordering constraint (set before approval) and the optional nature of payees, but says nothing about overwrite semantics for an existing policy, auth requirements for api_key, or currency handling — notable gaps for a non-idempotent write.

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

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

Two tight sentences with the core action front-loaded and the prerequisite placed last as a constraint. No filler, though the opening could have named the tool's read mode implied by its title.

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 6-parameter, non-idempotent write with no output schema and only 33% schema coverage, the description leaves real gaps: it never explains the 'read' behavior its own title advertises, nor the agent/api_key/currency parameters, nor what the response looks like.

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

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

Schema description coverage is only 33%, and the description compensates partially by glossing per_tx ('most it may pay in one go'), daily ('per day') and payees ('allow-list of payees'). It leaves api_key, agent and currency unexplained, and does not resolve the tension between the schema's 'in pounds' wording and the presence of a currency parameter.

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

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

States a specific verb and resource ('Set the spending limits for an AI agent') and enumerates the dimensions it configures (per-payment, per-day, optional payee allow-list). It is clear enough to distinguish a policy-setting tool from siblings like sebbi_spend_request or sebbi_spend_verify, though it never names them.

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

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

Provides a genuine lifecycle prerequisite ('Must be set before the agent can be approved to spend'), which tells the agent when this must happen. However it gives no exclusions and does not contrast with the spend_request/spend_verify siblings that operate on an already-configured policy, so the routing is only implied.

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

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive. Beyond that the description discloses the return contract (signed APPROVED/DENIED token), the gating rule for releasing funds, and the non-custodial posture ("sebbi.pro never holds the money") — genuinely useful behavioral context. It omits retry/idempotency implications and auth expectations for api_key.

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?

Four short sentences, zero waste, with the core action and the decision-token outcome front-loaded. Every sentence earns its place.

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

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

The request→decision→release workflow is covered and the return value is described in lieu of an output schema, but with 6 parameters at 17% coverage the description leaves the majority of the input contract undocumented and says nothing about failure modes or repeated-call behavior.

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

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

Schema description coverage is only 17% (just "Amount in pounds"), so the description carries the burden — yet it explains none of api_key, agent, payee, reason, or currency. An agent gets no guidance on payee format, agent identity, or currency default (implied GBP by the amount unit).

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?

States a specific verb and resource: ask sebbi.pro to approve a payment before an agent makes it, and returns a signed APPROVED/DENIED token. The scope is unambiguous, but it never names the adjacent siblings (sebbi_spend_verify, sebbi_spend_policy) that an agent must choose between.

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?

"Ask ... before an AI agent makes it" plus "Only release the money if it is APPROVED and spendable" gives a clear trigger condition and a clear follow-up rule. It stops short of stating when NOT to call it or explicitly routing to sebbi_spend_verify for token validation.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine non-annotation context: the operation is permissionless and requires no key, which is exactly the kind of auth information an agent needs before calling.

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

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

Two short sentences, the core check front-loaded and the access caveat second. No filler or restatement of the title.

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 single-parameter tool with no output schema, the description should convey what a verification result looks like (valid/invalid, expiry, signature failure) and it does not. Annotations carry the read-only safety profile, but the return semantics gap keeps this merely adequate.

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

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

There is one required parameter with 0% schema description coverage. The description only implies that 'token' is a Spend Gate token and does not state its format (opaque string, JWT, encoded payload) or where it is obtained, so it compensates only marginally.

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?

States a specific verb (check/verify) and resource (Spend Gate token), and further specifies the two things checked: signature validity and remaining spendability. This cleanly separates it from siblings like sebbi_spend_request or sebbi_spend_policy, though it never names an alternative directly.

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

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

Usage is implied rather than stated: you verify a token before relying on it. The sentence 'Anyone can call this; no key needed' addresses authorization, not when-to-use versus alternatives such as sebbi_spend_request or sebbi_verify_chain. No explicit when-not 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds a genuine behavioral obligation beyond that – the consent/precondition requirement before account creation – though it says nothing about return format or whether terms are cached/versioned on 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?

Two short sentences, front-loaded with what the tool returns and followed by the workflow constraint. Every clause earns its place and nothing is padded.

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

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

With no parameters and no output schema, the description adequately covers what comes back (terms plus version) and when to call it. It could say slightly more about the shape of the response or version semantics, but nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to add or omit. The schema is trivially complete with no gaps.

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

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

The description states the resource returned – the service terms and their version – which is a specific, identifiable artifact. It doesn't use an explicit verb, but 'Read the terms' in the title plus the content statement makes the purpose unambiguous, and it implicitly differentiates from sebbi_create_account by naming it as the follow-on step.

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

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

It gives an explicit workflow condition: show the terms to the customer in full, obtain a clear yes, and only then call sebbi_create_account. That is a named prerequisite plus a named alternative/gate, leaving nothing to inference.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false – so the safety profile and non-idempotency are already covered structurally. The description adds 'with the customer's key' and 'real' (vs test), implying live external side effects, which is useful context beyond the annotations, but does not say what 'sealed' means, whether a record is persisted, or what the experiment ('test_') actually affects.

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?

A single sentence, appropriately brief and front-loaded with the action. But it is under-specified rather than tight; the brevity is not earning its place because essential parameter and usage context is simply absent.

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?

A live, non-idempotent, open-world call with 5 undocumented parameters and no output schema needs substantial description. Instead the agent gets one sentence about 'verdict and sealed block' with no parameter docs, no return shape, and no mention of side effects or billing/cost implications of a 'real' live call.

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% for all 5 parameters, so the description carries the full burden of explaining action, amount, country, user_id, api_key. It mentions only the api_key implicitly ('customer's key') and gives nothing about the four decision-shaping parameters, nor which are required, nor accepted values.

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 says 'send one real decision through the live engine' and 'show the verdict and the sealed block' – a specific verb (send, show) and resource (decision, verdict, sealed block). However it does not explain WHAT a 'decision' is or what the engine does, and it does not distinguish from rich siblings like sebbi_decision_report or sebbi_spend_verify. An agent seeing 19 sebbi_* tools cannot map this to a domain concept.

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 when-to-use guidance and no mention of alternatives. With 19 sibling tools, several (sebbi_decision_report, sebbi_spend_request, sebbi_spend_verify) sound adjacent to 'decision', yet none are referenced for disambiguation.

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?

Annotations already declare the safe-read profile (readOnlyHint, non-destructive, open-world), so the bar is low. The description still adds real context by disclosing that no authorization is needed ('Anyone can run this') and that it returns chain height and tip. It stops short of describing cost, rate limits, or what a failed verification looks like.

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

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

Two short sentences, zero waste, with the core action and its outputs front-loaded before the permission note.

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

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

For a zero-parameter read tool with no output schema, the description covers the essential gap by stating what is returned (height and tip). It could say a little more about what 're-verify' checks or how failure is surfaced, but nothing critical is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it does not need to.

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 gives a specific verb and resource ('re-verify sebbi.pro's whole chain') and even names the return values ('height and tip'). The scope is unambiguous and distinct from every sibling, though it never explicitly contrasts itself with a related sibling such as sebbi_overview.

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?

'Anyone can run this' implies the tool is freely callable, but it gives no conditions for when to reach for it over siblings like sebbi_overview or sebbi_notary_receipt, and no exclusions. Usage is only loosely implied.

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