sebbi.pro - the proof layer for AI

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

Despite sparse annotations (readOnlyHint=false, destructiveHint=false), the description discloses the verdict model (RELEASE/HOLD/STOP), that reasons come back sealed, that the response enumerates follow-up tools, and a data-handling caveat ('never send names or account numbers'). It does not explain why it is a non-read-only operation (presumably an audit record) or whether a HOLD is reversible.

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?

Front-loaded with the imperative trigger, then the checks, then the verdict rule, then the API key and PII caveat. Dense but nearly every clause carries decision-relevant content; only the long enumeration of subsystems runs slightly long.

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 24-parameter, no-output-schema tool, the description covers the essential contract: when to call, what is checked, what verdict comes back, what to do with it, and the authentication requirement. The gap is guidance on optional/deep-fraud parameters, but the core call path is complete.

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

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

Schema coverage is only 38% across 24 parameters, so the description could do more. It groups the meaning of key inputs (Mandate Chain / Agent Passport / Spend Gate tokens, Payment Notary fingerprint, Jugular kill switch, fraud indicators), but leaves many properties such as direction, cop_result, new_device, expected_max_payment and account_opened undocumented in both places.

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?

Specific verb and resource: 'checks the agent's authority... the payee's sealed bank details... the human kill switch... and every FCA-named fraud indicator' and returns RELEASE/HOLD/STOP. It is unambiguously the pre-payment gate, distinguishable from siblings like sebbi_banking_verify or sebbi_spend_verify.

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?

Explicit timing: 'Call before releasing ANY payment, whether an AI agent or a payment system is sending it' plus the hard rule 'Release money only on RELEASE.' It tells the agent to follow the returned next-tool list, but never names a sibling tool it replaces or a case where it should not be called.

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 safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the main remaining question is side effects. The description usefully clarifies that 'Nothing is charged until they complete it', which is real behavioral context beyond the annotations, but it does not explain the non-idempotent behavior or link expiry, so it stays at a solid 3.

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 the outcome front-loaded and the reassurance about no immediate charge placed after it. Nothing is padded, though it is arguably too terse given the undocumented parameters.

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

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

For a simple link-generation tool with no output schema, the description covers what is produced and the key side-effect fact. However, it omits when to call it, what 'product' accepts, and whether the returned link is single-use or expiring, leaving gaps an agent would need filled.

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 carry parameter meaning. The pricing phrase '50p per device per month' implicitly clarifies that 'devices' drives cost, but the required 'email' and the 'product' parameter are left entirely undefined in both schema and description, so the compensation is only partial.

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 ('Returns a secure Stripe link') plus the business context (50p per device per month subscription), which is far more concrete than the title alone. It does not name a sibling to differentiate against, but no sibling in the list is a near-duplicate of this billing concern, so ambiguity risk is low.

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 scenario (a person needs to add a card) but never states when to call this versus the other setup/account tools like sebbi_create_account or sebbi_gateway_setup. There are no prerequisites, no exclusions, and no explicit when-to-use 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, openWorldHint=false and destructiveHint=false, so the 'Read-only' phrase in the description repeats structured data and earns no credit. The description does add useful context by disclosing what the generated pack contains and that a link is returned, but it omits generation cost/latency, any authorization requirements, and failure behavior for an invalid ref.

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 dense sentence leads with the action and then lists the pack contents, with the return value and read-only status trailing. It is front-loaded and waste-free, though the jurisdictional enumeration makes it long and slightly list-heavy.

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, non-destructive, read-only tool with no output schema, the description covers the essentials: input forms, the artifact produced, and that a link is returned. Missing are error handling for an invalid ref and any note on generation time or cost, which are minor for this 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 description coverage is 0% and the single 'ref' property is completely undocumented in the schema, so the description carries the full burden. It compensates well by enumerating the accepted reference forms (record code, chain block number, notarised SHA-256), which is exactly what an agent needs to supply a valid value. It could still specify format or validation rules more precisely.

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 ('Produces a printable Court Pack for a sebbi fact') and enumerates the artifacts it contains, so an agent knows exactly what it generates. It does not explicitly differentiate itself from near-named siblings such as sebbi_check_pack, sebbi_pack_reference, sebbi_list_packs or sebbi_publish_pack, leaving some ambiguity an agent must resolve.

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: the mention of acceptable references ('any record code, chain block number or notarised SHA-256') tells the agent when it has a valid input, which is genuinely helpful. But there is no statement of when to prefer this over sebbi_check_pack or sebbi_publish_pack, and no exclusions or prerequisites 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 readOnly=false, idempotent=false, and openWorld=true, so safety profile is covered. The description adds real context beyond that: it returns a credential (API key), the agreement is sealed permanently into the chain, and it is free for 90 days. These are useful behavioral traits, though durability/irreversibility of account creation itself is only implied.

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 tight sentences, front-loaded with verb, resource, and return value, then prerequisites, then side effect, then pricing. Every sentence carries distinct information with no waste.

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 no output schema, the description covers the return value, the consent gating, the chain-sealing side effect, and trial pricing. It leaves the product enum and non-required fields unexplained, but annotations carry the safety profile, so it is nearly complete.

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

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

Schema description coverage is low (43%), so the description ideally compensates, but it only elaborates on terms_version and customer_agreed—both already documented in the schema. The 'product' enum options and unannotated fields (name, email, company) get no added meaning, so it adds marginal value over 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?

States a specific verb and resource ('Opens a sebbi.pro account'), names the return value ('returns the API key'), and references the sibling 'sebbi_terms' it depends on. An agent can distinguish this creation tool from verification/check siblings without opening any schema.

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?

Explicit precondition ('Only call after showing sebbi_terms and the person agreeing') plus the exact argument values to pass ('terms_version they agreed to and customer_agreed=true'). Routes the agent to the predecessor tool and specifies the gating condition, 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 already cover readOnly, non-destructive and closed-world, so the trailing 'Read-only' is redundant. The description earns credit elsewhere: it discloses the return shape ('id, title, what it needs and the framework list') and the catalog size, letting an agent anticipate result volume and fields.

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?

Front-loaded with the core action and scale, and the follow-up routing is placed last where it belongs. The long framework enumeration is informative for discovery but borders on bloat, costing it one point.

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 does the work of describing return fields, which is the key gap it needs to fill for a search tool. Minor omission: nothing about truncation or limit behavior beyond what the schema states.

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 all three parameters are already documented, including the 'leave out to list frameworks' behavior. The description adds only the framework/word filtering idea, which the schema already conveys. 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?

States a specific verb and resource ('Searches sebbi.pro's 755 compliance checks') with concrete scale and coverage ('32 frameworks'), then names the exact frameworks. It is immediately distinguishable from sebbi_run_check and sebbi_run_framework, which it explicitly routes to.

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?

Gives explicit when-to-use-next guidance: 'Then run one with sebbi_run_check or a whole framework with sebbi_run_framework.' The schema further clarifies that omitting framework lists frameworks. Alternatives and their triggering conditions are both named.

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 only declare read-only/non-destructive; the description adds the critical fail-closed semantics ('or the check fails, do not act') and the reason behind the switch. That fail-closed rule is a behavioral trait an agent could not derive from the schema or 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 gating instruction is front-loaded, followed by the return contract and the fail-closed rule. Every clause carries actionable information with no 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?

Absent an output schema, the description states the return shape ('live true or false') and how to interpret it. For a single-param gating tool, nothing an agent needs to call 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?

Schema coverage is 0% for the single required 'id' param, so the description must compensate. It does so by naming the expected format ('id JG-XXXX-XXXX'), which meaningfully constrains the parameter beyond the bare 'string' type.

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 ('check' the 'Jugular' kill switch) and specifies the return value ('Returns live true or false'). The named system concept and the sibling sebbi_jugular_create make it trivially distinguishable from other sebbi_* tools.

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

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

Explicitly prescribes timing ('Call before taking any action'), the condition for acting, and the fallback ('If live is false, or the check fails, do not act'). Both the positive and negative branches are covered with no inference required.

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, and non-idempotent; the description adds real value beyond these by disclosing the privacy behavior (content never leaves) and that a receipt code plus link is returned per digest. It does not explain the api_key/auth requirement or repeat-submission behavior, but with annotations covering the safety profile this is solid.

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 tight sentences, front-loaded with the purpose and privacy constraint, with no filler. Every sentence carries information the agent needs.

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 covers the return value (receipt code and link for each digest), which is the key gap. It is complete for the core call, but the auth parameter and idempotency behavior remain unexplained for a write/networked tool.

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%, so the description must compensate. It explains the digests array well (one or more 64-character SHA-256 fingerprints), but adds nothing about the optional label (only in schema) and leaves api_key undocumented in both places.

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 (timestamps), resource (SHA-256 fingerprints), and mechanism (Bitcoin through the free notary). An agent can distinguish it from siblings like sebbi_notary_receipt or sebbi_forever_proof without opening the schema.

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?

Gives clear operational context: hash the content yourself and send only the 64-character fingerprint, so the raw data never leaves. It does not name alternatives (e.g., sebbi_notary_receipt for retrieval) or state when not to use it, so it stops short of explicit routing.

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 readOnlyHint, destructiveHint, and openWorldHint, so the safety profile is largely pre-declared. The description adds genuinely new context: "no account needed" (auth requirement absent from annotations) and the shape of what is returned. It stops short of disclosing size, pagination, or cost characteristics.

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, zero filler, and the routing instruction "Start here" is front-loaded before the content description. Every clause carries information.

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 compensates by enumerating the fields returned (product, purpose, audience, page, price), and it states the auth posture. For a zero-param read-only overview tool, nothing needed to call 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 there is nothing for the description to disambiguate; baseline is 4 by rule. It correctly does not invent parameter semantics.

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

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

States a concrete verb (lists) and resource (every sebbi.pro product) plus the specific fields returned (what it does, who it is for, page, price). Against 26 siblings, this reads unmistakably as the orientation/catalog entry point rather than an operation tool.

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

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

"Start here" gives an explicit when-to-use cue that positions it ahead of all siblings, which is exactly the guidance an agent needs for a 26-tool namespace. It does not name a when-not condition or an alternative, 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?

Goes well past the annotations: it discloses that sealing publishes a public scorecard page with a reference code (SC-XXXX-XXXX) intended for auditors/insurers, that this is the default, and how to opt out. It also states the retention behavior ('Only a fingerprint of the record is kept') – exactly the kind of side effect an agent needs before sending a governance record.

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

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

Three sentences, front-loaded with scope, then outputs, then the sealing side effect and its opt-out. No filler and no repetition of the name or 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?

With no output schema, the description carries the return-value burden and does it: overall score, per-framework scores, and prioritized fixes. Data retention and the public-page side effect are covered. Minor gap: it doesn't mention failure behavior when the record is malformed or the cost/latency of a 755-check sealed run.

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%, so the baseline is 3; the description earns more by explaining the interaction the schema can't – that agent-output gates only fire when input_payload/output_payload are supplied – and by restating the seal=false escape hatch in behavioral terms. It doesn't clarify the record shape or the frameworks key format beyond 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?

Opens with a specific verb and object: 'Runs all 755 compliance checks ... on one governance record in a single call', and scopes the alternative ('or the frameworks named'). It implies the whole-suite scope that separates it from sebbi_run_check and sebbi_run_framework, 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?

'By default seals ... send seal=false to just look' gives one concrete usage branch and a safe preview path. However, it never says when to prefer this over sebbi_run_check (single check) or sebbi_run_framework (one framework), which are the nearest siblings and the likeliest mis-selection.

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 and the trailing 'Read-only' is largely redundant. The description does add value by disclosing the output shape (step-by-step setup with working code or a ready-made prompt), which is beyond what annotations say.

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?

Front-loaded with the main action, followed by a short input hint. Mostly efficient single flowing sentence plus a brief instruction, though the trailing 'Read-only' repeats annotation data.

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 usefully explains that it returns a setup plan with code or a prompt, which covers the return value. However, it says nothing about the unexplained api_key parameter or any auth requirement, leaving a real gap for an openWorld tool.

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 75%, and the description corroborates 'stack' and 'goal' via 'Pass their stack and what they want to achieve' but adds no syntax or format detail. The 'device' and undocumented 'api_key' parameters get no treatment in the description, so it does not compensate for the coverage 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?

States a specific verb and resource: it recommends sebbi.pro products and produces a step-by-step setup with code or a prompt. An agent can grasp the function quickly, though it does not explicitly differentiate itself from the setup-flavoured sibling sebbi_gateway_setup.

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 input-side context ('Pass their stack and what they want to achieve') which implies usage, but there is no when-to-use vs when-not guidance and no alternative sibling is named. The agent must infer selection.

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, and destructiveHint=false. The description adds real value beyond them: it returns a signed token checked against the agent's limits and explicitly states sebbi.pro never holds or moves money, clarifying that this is an authorization check, not a funds transfer.

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, front-loaded with the trigger condition and followed by the outcome and a scope disclaimer. Nearly every sentence earns its place, though the 'spendable' clause is slightly ambiguous.

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, describing the returned token is helpful and the money-custody disclaimer closes an important behavioral gap. But for a tool with six inputs and 17% schema coverage, the absence of any parameter explanation or output field detail (token expiry, how to present it) leaves meaningful gaps.

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), and the description explains none of the six parameters despite the persistence of payee, agent, api_key, currency, and reason. With low coverage and no compensating narrative, the agent gets little semantic help on inputs.

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 action and resource: an agent calling to get an APPROVED/DENIED spend token before a payment. An agent can understand the core purpose without opening the schema. However, it does not differentiate this from closely named siblings like sebbi_spend_policy or sebbi_spend_verify, so sibling confusion remains possible.

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?

'Call before every payment an AI agent makes' gives a clear triggering condition, and 'Release the money only if it is APPROVED and spendable' specifies the follow-up action. It stops short of naming when not to use it or routing to the sibling spend tools, so it is clear context without alternatives.

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

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

Adds genuine behavioral context beyond the annotations: the required human-consent sequence and the ordering constraint relative to account creation. The 'Read-only' statement is largely redundant with readOnlyHint=true, and no return format or pagination detail is given, but for a zero-param read tool the extra workflow disclosure is substantive.

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 with no filler, and the most important constraint (get a clear yes before creating an account) is front-loaded immediately after the purpose statement.

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 tool with annotations covering the safety profile and no output schema, the description supplies everything an agent needs: what it returns, the consent workflow, and the ordering relative to sebbi_create_account.

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 no parameters, so the baseline is 4. The description correctly adds nothing about inputs because there are none, and it instead describes output content (terms and version).

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 (returns the service terms and their version) in the first sentence. It is clearly distinguishable from the sibling sebbi_create_account, which it explicitly names, so an agent knows exactly what this tool does without opening the schema.

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?

Gives explicit sequencing ('before calling sebbi_create_account') and an explicit precondition ('show the full text to the person and get a clear yes'). This is a when-to-use rule with a required workflow, not just an implied 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the write nature and non-idempotency are known. The description adds 'Writes one record to the chain,' which concretely specifies the side effect, and names the verdict values. It does not clarify the implications of the non-idempotent flag (e.g. repeated calls create multiple sealed records) or any auth/rate constraints.

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 action and immediately followed by the outcome and side effect. Efficient with no filler, though the trailing 'so they see it working end to end' is the least information-dense part.

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 usefully enumerates the return shape (verdict, reasons, sealed block number), which compensates well there. But for a five-parameter mutation tool with zero schema coverage it leaves the inputs entirely undocumented and gives no usage routing, so it is only partially complete.

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

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

Schema description coverage is 0% and the description documents none of the five parameters. It only alludes to api_key ('with their API key'), leaving action, amount, country and user_id completely unexplained, so an agent must guess their meaning and format from names 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?

The description states a specific verb and resource ('Sends one decision through the live engine') and names the concrete output (verdict with ALLOW/CHALLENGE/BLOCK, reasons, sealed block number). It is clear what the tool does, but it never differentiates itself from siblings like sebbi_decision_report or sebbi_run_check, which an agent might reasonably confuse with a live decision tool.

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

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

The phrase 'so they see it working end to end' implies an onboarding/first-run use case, which is useful context. However, it does not explicitly say when to choose this over sebbi_decision_report or any other decision-related sibling, nor does it state any exclusions or prerequisites beyond the API key.

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

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

The description goes beyond simple execution by disclosing a key behavioral trait: it handles arguments for the target tool, even those that are not explicitly listed or known to the dispatcher tool itself. This adds critical context to the dynamic nature of the call.

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

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

The definition is highly efficient. It states what the tool does, how it is used, and why it is necessary within the context of the toolset in just a few succinct sentences.

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 meta-dispatcher tool, the description is complete. It successfully explains its unique role as a fallback mechanism for tool discovery and execution.

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 the schema covers the fields, the description clarifies the capability of the 'arguments' parameter, stating it will handle arguments 'not listed up front.' This reinforces the dynamic nature of the tool and how parameters are actually handled in practice.

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 purpose is perfectly clear: it serves as a dynamic wrapper to call any sebbi.pro tool by name. It explicitly defines the functionality of calling a tool with its arguments.

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 tool provides explicit guidance on usage, specifically instructing the agent to use it when a tool is requested in a response's next_tools list but is otherwise unknown to the agent.

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 and destructiveHint=false, so the safety bar is low; the description still adds value by describing the return shape (name, what it does, inputs) and the 'free' cost trait, which annotations don't convey. It does not describe pagination or result limits, keeping it from 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?

Front-loaded with the core purpose and return shape; most sentences earn their place. The enumerated tool-name list is somewhat long but serves to signal the breadth an agent can expect, so it's defensible rather than wasteful.

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, no-output-schema listing tool, the description covers what it returns, how to filter, and how to act on results. Missing only edge-case details such as empty-result behavior or result caps.

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 the single 'search' parameter, so the baseline is 3. The description adds example filter terms ('banking', 'oversight') that hint at matching against tool names/descriptions, but the schema's own example already covers this, so it adds only marginal meaning.

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

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

States a specific verb and resource — it returns each tool's name, function, and inputs — and clearly frames itself as a catalog of tools not listed up front. An agent can distinguish this from operational siblings like sebbi_banking_pay_check or sebbi_overview without opening a schema.

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 says to pass 'search' to filter (with concrete example terms) and, critically, that any discovered tool is invoked via sebbi_tool — this closes the discovery-to-invocation loop. It stops short of naming when to prefer a sibling like sebbi_overview instead, so it's strong context without explicit 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?

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description reinforces this with 'Read-only' plus a genuine extra: no account or auth is required. It also previews the returned fields (height, tip, intact), which is useful behavioral context beyond the structured hints.

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, no waste, with the core action front-loaded before access and read-only qualifiers. 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 parameterless, no-output-schema tool, the description supplies exactly what is missing: what is checked (all blocks), what is returned (height, tip, integrity), who may call it (anyone), and its safety profile. Nothing an agent needs to call it correctly is 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly avoids inventing inputs and instead spends its words on scope and results.

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 ('re-checks') and resource ('every block in the sebbi.pro chain'), and enumerates what comes back: height, tip, intactness. This scope separates it from the per-item verifiers among its siblings (verify_insurability, spend_verify, check_pack) without needing to open a schema.

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?

Implies the use case via 're-checks every block' — a full-chain audit rather than a single-item check — and clarifies access ('anyone can run it; no account needed'). It never names an alternative or an explicit when-not condition, so the agent must infer routing from the chain-wide scope.

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