Scienter

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior; the description goes well beyond by disclosing the data path (own warehouse first, then a budgeted live provider), the deliberately partial registry, the `truncated: true` lower-bound semantics, and the three distinct outcomes. That is exactly the caveat context an agent needs to report results without overclaiming.

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 purpose and only mildly repetitive in restating the coverage caveat twice. Every sentence, including the outcomes list and the truncation note, carries operational meaning, so the length is largely earned.

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 nonetheless specifies payload contents, the coverage caveat shipped with results, the truncation flag, and scope limits. An agent has enough to call it and to restate the result correctly.

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

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

Schema coverage is 100% and the parameter is already typed and described, so the schema carries most of the load. The description still adds real meaning by stating that a base58 Solana address yields an out-of-scope answer rather than a clear one, which changes how the argument's failure mode is interpreted.

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 first sentence names a specific verb (trace) and resource (cross-chain bridge transfers) and enumerates exactly what comes back: bridge contract, destination chain, amount, transaction hash. Nothing about it can be confused with cex_attribution, wallet_score, or ofac_check.

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?

Explains when a result is meaningful versus a bounded negative and when nothing may be inferred, and sets a hard scope boundary (EVM only, Solana out of scope). It stops short of naming which sibling to use instead for related questions, so routing is implied rather than explicit.

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

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

Beyond the readOnly/idempotent annotations it discloses real behavioural context: the table's small size (tens of addresses), its provenance (public block-explorer labels, activity-checked on chain), the activity.checked field indicating whether a transfer read ran, and the clusterable flag constraint on how results may be restated. That is unusually rich disclosure of limits and result semantics.

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 core capability and the caveats are front-loaded and each paragraph carries real content, but the prose is dense and the instruction about repeating the clusterable flag is an odd meta-directive that could be tightened.

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 explaining returns and does so: row contents, activity.checked, the clusterable flag, and hit/miss interpretation. It is nearly complete, though the full set of returned fields is not enumerated.

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 only one parameter and schema coverage is 100%, so the schema already documents the accepted address formats. The description restates the same formats and adds nothing further (it even omits the schema's 'case is preserved' note), so the baseline of 3 applies.

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

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

States a specific verb and resource: whether an address is a labelled centralised-exchange wallet in Scienter's published table, plus clustered-address and exchange-activity reads. This is clearly distinguishable from siblings like ofac_check or wallet_score, which target different label sets.

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 strong interpretation guidance: a miss means no label is held, not that the address is unaffiliated, and a hit on an exchange hot/cold wallet means nothing about linkage between two funders. It does not explicitly route the agent to or away from named sibling tools, 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 read-only, idempotent, open-world, non-destructive, and the description does not contradict them. Beyond that it discloses the three-state outcome model (match / no-match / not-screened), the meaning of proximity_checked being true or false, the two-hop and node-budget bounds, and the list-scope caveats (SDN only, as of a stated date) — exactly the behavioral context 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 in the first sentence and the outcome taxonomy is scannable, but the text runs long for a one-parameter tool and includes instructions aimed at how the agent should phrase its answer ('Limits to repeat whenever the result is restated') rather than at tool selection or invocation. Useful content, but the volume and the meta-reporting directives dilute it.

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 full burden of describing return values, and it does: entity, type, sanctions programs and chain for a hit; explicit not-screened state; proximity found/not, hop count, path and depth. For a single-address screening tool the agent has everything needed to call it and to interpret the result honestly.

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 is fully documented in the schema, including address formats and case preservation, which the description restates rather than extends. Nothing new is added about the parameter itself (no validation rules, no failure modes for malformed input), so the 3 baseline 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 opening sentence names the exact verb, resource and scope: screen one blockchain address against the OFAC SDN list, direct match plus two-hop proximity walk. The three direct-match outcomes and the distinction between designation and graph proximity make it unmistakable what this tool produces versus any other sibling.

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 a clear positive trigger ('Call this when a user asks about sanctions exposure, designation, or OFAC status for an address') and a hard negative directive ('never report not-screened as clear; point the user at sanctionssearch.ofac.treas.gov'). It does not name any sibling tool or say when another tool (e.g. wallet_score, cex_attribution) would be the better choice, so it stops short of full alternatives coverage.

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 (readOnly, idempotent, openWorld), and the description goes well beyond them: corpus size (tens of receipts), draft-withholding behavior with a separate count, and the crucial negative-result caveat. These are exactly the behavioral traits an agent needs to interpret an empty result correctly.

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?

Purpose and the negative-result caveat are front-loaded in the first two sentences, which is the right order. The trailing 'Args:' block duplicates schema descriptions that are already 100% covered, making it slightly longer than necessary.

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 exists, so the description compensates by naming the returned fields and the human-openable URLs. Combined with the corpus-size and no-match caveats, an agent has everything needed to call it and to interpret both hit and miss results.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds genuine semantics by stating what happens when neither filter is supplied (most recent published receipts) and clarifying that address matches subject or deployer containment. The rest largely restates schema text, keeping it below a 5.

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 (search) and resource (Scienter's published forensic receipts) plus the match modes (address or free text) and the return shape (titles, dates, subjects, public URLs). It is clearly distinguished from siblings like bridge_trace, cex_attribution or wallet_score, which are analytical rather than publication lookups.

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 real interpretive guidance: no match is normal and is not evidence of nothing happening, unverified drafts are withheld, and omitting both filters lists most recent receipts. It does not, however, route the agent toward or away from specific sibling tools, so it stops short of full when/when-not/alternatives 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 only cover read-only/idempotent/open-world safety, and the description adds far more: the three-way outcome semantics, the explicit warning that 'no record' reflects coverage and not conduct, the prospective-census data origin with a start date, and the empirical hit rates with intervals. This is exactly the behavioral context an agent needs to avoid misreporting results.

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 definition, then cleanly sectioned into outcomes, evidentiary value, negative-screen disclaimer, and case rule. It is longer than most descriptions, but nearly every sentence carries substantive meaning; the phrasing 'and whether every one of them did' is slightly awkward filler.

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

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

With no output schema, the description carries the full burden of explaining return semantics, and it does so completely — the three outcomes, what each means, and the trap of misreading 'no record'. An agent can report results correctly from this text alone.

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 description's case-sensitivity note largely restates the schema's own 'exact case' warning. It reinforces the consequence but does not add new parameter semantics beyond what the schema already documents, so baseline 3 is appropriate.

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

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

The opening sentence names a specific subject (what the deployer wallet has done across past launches) and even explains why it can answer a deployer question rather than a token question, which separates it from the sibling solana_token. The three-outcome taxonomy makes the exact deliverable concrete.

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 explicit trigger conditions ('who made a Solana token', 'whether a deployer has a history', 'whether a launch's creator has ever had one survive') and explicit exclusions ('never restate it as a recommendation, a risk score, or a safety verdict'). Usage boundaries are unambiguous.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it specifies that a thin record of one or two settled launches is reported as unreadable, that the funder rule's verdict is quoted verbatim with its scoring date, and that no record is not a clean record. It also states the base58 case-sensitivity failure mode, which is genuine behavioral disclosure an agent cannot infer.

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 caveat block (negative screen, not a score, survival is a low bar, thin records) earns its place, but the first sentence is a single run-on spanning roughly a hundred words, and the case-sensitivity warning appears twice in the description and again in the schema. Useful content, poor structure and noticeable 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 carries the return burden itself and does: it enumerates each section of the record, states how the funder verdict is quoted, and flags the thin-record edge case. An agent has enough to call it correctly and to set a user's expectations about interpretation.

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 already states "base58 Solana wallet address, exact case" plus the lowercasing consequence. The description's case paragraph repeats that same information rather than adding syntax, format, or validation detail beyond the schema, 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 opening names the resource (a Solana token creator wallet) and enumerates the record's contents: settled launches, indexed launches newest-first, launch cadence, and the first-transaction funder. It references the sibling solana_deployer but only as "the same screen ... with the same measured worth," which tells an agent they overlap without clarifying how they differ, so the 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?

The "Call this when a user asks..." sentence gives four concrete trigger conditions covering launches, activity level, volume-launching, and funder provenance. There is no explicit when-not or a clear routing rule against solana_deployer, which keeps it out of 5 territory.

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?

Despite readOnly and idempotent annotations, the description adds extensive behavioral context beyond structured fields: the prospective census coverage since 2026-09-08, the distinction between token-level and wallet-level counts, the three non-collapsible outcomes, the measured flag performance, and the explicit negative-screen framing. This is unusually complete disclosure for a read-only tool.

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

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

The description is front-loaded with purpose and structured with clear bullets for the three outcomes. It is long, but the length is largely justified by the interpretive stakes; however, it repeats the case-sensitivity warning already present in the schema and uses several emphatic warnings that could be tightened.

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-only, no-output-schema tool with high interpretive risk, the description covers purpose, alternatives, outcomes, coverage limitations, scoring evidence, and prohibited restatements. An agent has enough context to invoke and interpret it correctly.

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

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

Schema coverage is 100%, and the schema itself already documents that mint must be a base58 Solana mint address with exact case. The description reinforces the case-sensitivity point and frames the mint as the identifier a user actually has, but it does not add syntax or validation semantics beyond what the schema provides.

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 precise verb and resource: resolving the creator wallet of a Solana mint and reporting that wallet's other launch history. It clearly distinguishes itself from solana_deployer, which is for when a deployer wallet is already known.

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 when to call this tool (specific token, who made it, creator history) and names the alternative (solana_deployer) with the condition that selects it. It also explains the three possible outcomes and how they must be interpreted, leaving very little 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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely load-bearing behavior the annotations cannot: no calibrated risk number will ever be emitted, and a silent engine produces a distinguishable failure state. That is exactly the kind of caveat that prevents misreading results.

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, then the important negative constraint, then args — a sensible ordering with no filler sentences. The middle paragraph is a bit repetitive in phrasing ('publishes no calibrated wallet-risk model' / 'will never emit a number') but the redundancy reinforces a critical caveat.

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 burden of describing returns — and it does, by naming each returned component and explaining the findings_checked flag semantics. For a single-parameter read tool, nothing an agent needs to call and interpret 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?

Only one required parameter with 100% schema description coverage, so the schema already carries the semantics. The description restates the accepted address formats but adds nothing the schema doesn't (the schema even notes case preservation, which the description omits). Baseline 3 is appropriate.

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

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

States a specific verb and resource — a forensic read on one blockchain address — and enumerates exactly what comes back (explorer facts, exchange label, cluster entity, itemised findings with citations). It also states the negative case explicitly ('This does NOT return a risk score'), which an agent can use to separate it from scoring or attribution 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?

Gives clear contextual guidance: it is an evidence-gathering tool, and an empty findings list with findings_checked=false signals the engine did not answer rather than a clean result. It does not, however, name when to prefer it over siblings like ofac_check or cex_attribution, so the agent must infer the routing.

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