Crovia — verifiable silence (TACET) and Crovia Seal

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: it is a point-in-time snapshot ('Live totals at this moment') and it 'Reads published files only,' disclosing the data source and that no mutation or private state is touched. It does not mention pagination or size limits, but for a zero-arg status read that is minor.

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

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

The description is short and front-loads the payload ('Live totals at this moment: ...') before the exclusions. The standalone sentence 'No parameters' is slightly redundant with an empty input schema, and the negation list is dense, but overall it is tight and every clause carries routing or content 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 carries the burden of describing return values and it does so by enumerating the six content areas, including a pointer to the longest verifiable silence. For a simple zero-param read this is sufficient; only the exact shape/format of the returned fields is left unspecified, which is a small 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?

The tool takes zero parameters and the description confirms 'No parameters,' so there is no parameter semantics to explain. Baseline for a parameterless tool is 4, and nothing here misrepresents the empty input schema.

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

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

The description names a concrete resource (live TACET totals) and enumerates the exact payload an agent gets back: epochs closed, epochs anchored in Bitcoin, models on the map, snapshot counts, signed silence proofs, and a pointer to the longest verifiable silence. It also differentiates itself from three siblings by negation (not a weekly Silence Report, not one model's record, not a proof bundle), so an agent can route correctly 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?

Explicit exclusions are given: 'This is not a weekly Silence Report, not one model's record, and not a proof bundle,' which effectively steers the agent away from silence_report, lookup_model, and get_silence_proof. It does not name those alternatives as tool IDs, so the routing is implied rather than spelled out, but the when-not guidance is clear.

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 read-only, closed-world profile, so the bar is low. The description still adds real context by stating it 'Reads no catalog,' signalling deterministic, side-effect-free output that does not touch live data. It does not describe the response shape, keeping it just short of 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?

Five short sentences, front-loaded with the identity mapping and the usage rule, with no padding. The telegraphic fragments ('No parameters. Reads no catalog.') read abruptly, and the parameter note restates the schema, so it is efficient rather than exemplary.

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 static, zero-parameter comparison tool with no output schema, the description tells the agent what it will learn and when to reach for it. The only minor gap is that it does not hint at the return format of the comparison.

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, which is the baseline-4 case. The explicit 'No parameters' statement is redundant with an empty schema object but consistent and harmless.

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 the specific subject (the distinction between Crovia and Causari) and defines each product's role — Crovia for training-data disclosure, Causari for code provenance — so an agent knows exactly what question this answers. It falls short of 5 because the opening fragment 'Which product is which' is terse and the true purpose only emerges in the following two sentences.

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 routing rule: 'Use this, not explain and not crovia_status, when the question is the difference between the two.' Both the alternative tools and the selecting condition are named, 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds behavioral detail beyond them: the invalid-input path returns an error that lists allowed terms and does not return definitions, and blank strings are treated as whole-set lookups. That error/edge-case disclosure is the valuable part.

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 the purpose, then the allowed-value domain, then the two edge-case branches, then the sibling routing. Nothing is padded or buried; the term list is the only mild duplication of the schema.

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-optional-parameter, read-only lookup with no output schema, the description covers input domain, defaults, and error behavior adequately. The only gap is a rough sense of the returned shape (one definition text versus an all-definitions payload), which is minor given there is no output schema to lean on.

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

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

Schema coverage is 100% and the schema property already documents the allowed values, omission, empty string, and unknown-term error. The description only marginally exceeds this by adding 'blank' (whitespace) handling and stating that the error path withholds definitions, so the baseline 3 applies.

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

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

The description names the exact resource (a Crovia term definition) and enumerates the closed set of allowed terms, so an agent knows precisely what comes back. It also distinguishes itself from sibling crovia_vs_causari by name and purpose, which is the key disambiguation in this toolset.

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 when-to-use (look up a single term), explicit fallback (omit the term or pass empty/blank to get every definition), explicit failure mode (any other value errors out), and explicit alternative routing (use crovia_vs_causari for product comparison). All conditions are stated rather than inferred.

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 and openWorldHint=false, so the safety profile is covered. The description adds real context on top: 'Reads published files only' (static published artifacts, not live data) and that include_bundle 'does nothing on the index' — a non-obvious no-op an agent would otherwise have to discover.

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 with no filler; the payload list leads and the scoping/exclusion clauses follow. Slightly dense and run-on, but every sentence carries information an 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?

There is no output schema, so the description carries the return-value burden and does it well by enumerating the returned fields and the verification affordance, while also covering the index-vs-bundle branching. Nothing needed 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?

Schema description coverage is 100%, so the schema already documents both parameters and their default/empty-string semantics. The description restates the same behavior (model omitted returns index, include_bundle default false) without adding syntax, format, or edge-case detail 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?

The description names a specific verb+resource (the published silence proof for one model) and enumerates the payload it returns: silence_days, observed window, epochs, seal id, URL, verification steps. It also distinguishes itself from siblings by explicitly ruling out 'the live totals' and 'the weekly report', which maps to crovia_status and silence_report.

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 clearly states the index fallback condition (model omitted or empty) and the include_bundle behavior, plus two explicit exclusions. It stops short of naming the alternative tools to use for live totals or the weekly report, so routing is implied rather than spelled out.

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 read-only and closed-world behavior, and the description adds meaningful context: it reads published files only, empty input is an error, exact IDs take precedence, substring fallback is case-insensitive, and multiple matches return candidates rather than a verdict. These are important behavioral traits 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?

The description is front-loaded with the returned observation fields and then covers matching behavior and exclusions. It is dense and generally efficient, though it repeats some parameter information already present in the schema.

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 must explain return values; it lists the key observation components an agent should expect. Combined with the matching semantics and read scope, it is complete enough 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?

Schema coverage is 100%, so the required Hugging Face id format, example, and empty-error condition are already documented. The description adds matching semantics—exact-id precedence, case-insensitive substring fallback, and candidate fallback on multiple matches—which is genuinely useful 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?

The description names a specific resource—one model's observation—and enumerates what it returns: latest verdict, negative snapshots, anchored epochs, silence proof pointer, archive silence, badge, and record URL. It also distinguishes the tool from catalog, weekly-report, and seal-byte operations, so an agent can tell it apart from siblings.

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 states that an exact id is used, substring matching is accepted, and multiple matches return candidates instead of a verdict, plus it explicitly excludes catalog/weekly-report/seal-byte use cases. However, it does not name the specific alternative tools to use for those excluded cases, leaving some routing 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 only declare readOnlyHint/openWorldHint; the description goes well beyond them by disclosing the limit coercion rules (falsy -> 25, clamp into 1..100, unparseable -> hard error with no search performed), the catalog-vs-match ordering, and the read scope ('published files only'). This is exactly the kind of behavioral detail annotations cannot carry.

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 purpose is front-loaded, but the middle of the description is a dense run-on chain of return-field disambiguations and defensive restatements ('count is not the match count, and total_records is not the match count. This is not a verdict and not a proof.'). Several sentences repeat the same caveat rather than adding 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 correctly spends its budget documenting return fields (returned/count, matched, catalog_total/total_records, limit) and the limit failure mode. It is nearly complete for a two-parameter search, though it omits how to page past the first result set and gives no sibling routing.

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's limit and query sentences largely restate the schema text verbatim rather than adding syntax or format meaning. It adds no parameter information the schema does not already contain.

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

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

The opening sentence names the resource (observed model ids), the matching rule (case-insensitive substring on id) and the ordering (catalog order, not a ranking), which is enough to distinguish this from a scoring/verdict tool. It stops short of naming the obvious alternative (lookup_model) for exact-id retrieval, so sibling differentiation is only partial.

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 tells the agent what the tool is not ('not a ranking', 'not a verdict and not a proof') and that it 'Reads published files only', but never states when to choose this over lookup_model or the other siblings, nor any prerequisites. Usage has to be inferred entirely from the matching semantics.

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

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

With readOnlyHint=true and openWorldHint=false already given, the description still adds useful behavior: it reads published files only, invalid formats error, and a week with no published file errors while naming the index (the agent learns the failure mode is informative, not silent). No auth, rate, or cost details are offered.

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 outcome, then the parameter rule, then the error cases, then the scope exclusions — a sensible order. The fragment style is dense and mostly earns its place, though the week format and empty-string rule are each stated twice in slightly different words.

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 read tool with no output schema, the description covers what is returned (one week's report versus the latest index), what selects each mode, and how failures surface. Combined with annotations covering the safety profile, nothing material 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 100% and the single parameter already documents the YYYY-Www format with an example, so the baseline is 3. The description goes beyond the schema by defining the error semantics tied to the value ('a week that is not YYYY-Www is an error') and by confirming empty-string handling.

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 ('One published weekly Silence Report, or the latest report index') and immediately bounds the scope. It also rules out adjacent resources ('not the live status and not one model's proof'), letting an agent separate it from crovia_status and get_silence_proof without opening schemas.

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 concrete selection rules: omit week or pass an empty string for the latest index, supply YYYY-Www for one week's facts, and it explicitly excludes live status and single-model proof. It stops short of naming the sibling tools that cover those excluded cases, so the routing is described rather than spelled out.

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 and openWorldHint, and the description adds substance beyond them: url fetching goes out over the network, check_anchors=true triggers drand round and Bitcoin anchor checks over the network, and a seal-only check stays local to that object. The closing statement that the tool is 'not a closed-world call' directly reinforces and elaborates the openWorld annotation rather than repeating it.

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-loads what is verified, then handles inputs, then network behavior. Efficient overall, but the network caveat is stated three times ('fetches that URL over the network', 'over the network' for anchors, 'can reach the network'), which is one repetition more than needed.

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?

Inputs and network behavior are fully covered for a zero-required-parameter verification tool. The one gap is that with no output schema, the description never says what a verification call returns (e.g. a pass/fail verdict or per-check results), which an agent would want before calling.

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, but the description adds a cross-parameter constraint the schema cannot express: exactly one of seal or url must be supplied or the call errors, and a seal object alone is verified without network access. It also restates the host restriction and default in terms of consequences.

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) applied to a specific resource (a crovia.seal.v1 object or wrapped TACET silence proof) and enumerates what is verified: signature, canonical bytes, bindings, and per-epoch non-inclusion paths. That is far more precise than the title, though it does not name any sibling tool to differentiate itself from get_silence_proof or crovia_status.

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 invocation conditions: pass seal (object or string) or url, and explicitly states that with neither the call is an error. It also explains when check_anchors changes behavior. It never compares itself to alternatives, so it stops short of explicit when-not/alternative guidance.

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