SweetAI — On-chain AI Agent Intelligence

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

With no annotations, the description carries the full burden, and it does disclose behavioral context by naming the data provenance (on-chain registration + indexed transactions) and the result categories. It omits anything about data freshness, caching, permissions, or failure modes, which an agent would want for a 1-param lookup with no 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?

Three short, front-loaded clauses: what it returns, where data comes from, and what it is not. No filler, though the terse style borders on under-specification rather than pure conciseness.

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?

An output schema exists, so return values need not be explained, and the description covers purpose, data source, and non-goals for a simple single-parameter tool. It is otherwise complete, though written in Czech while sibling tooling is English, which slightly raises comprehension risk for the calling agent.

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

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

Schema description coverage is 0%, so the description should compensate, but it says nothing about the 'address' parameter (expected format, chain, checksum, etc.). The single param name is largely self-evident, keeping this at baseline rather than lower.

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 resource (address reputation/risk) and enumerates the exact output levels (LOW/MEDIUM/HIGH/UNKNOWN), so an agent knows what it gets back. It also rules out the sibling get_agent_sla by stating 'Ne SLA' and disclaims trade success rate, aiding disambiguation. It lacks a clear action verb and a plain statement of 'checks a wallet address', but the intent is unambiguous.

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

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

It gives explicit negative routing guidance ('Ne SLA, ne úspěšnost obchodu'), steering the agent away from the SLA and trade-performance tools. However, it never states positively when this tool should be preferred (e.g., before trusting an address), so the condition that selects it must be 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond subject matter. It does not state that this is a read-only analytics query, does not explain the time window semantics (window_hours default 720) or result freshness, and does not mention the row cap implied by limit=50. The one useful interpretive hint — that hubs are 'infra nodes' — is domain framing rather than behavior.

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 that front-loads the subject (A2A payment graph) and then lists the three output categories in a scannable parenthetical structure. Nothing is padded, though the lack of an explicit verb makes the opening slightly less immediately actionable.

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?

An output schema exists, so return-value documentation is not required, and the description does convey what the graph is composed of. However, with zero annotation coverage and both parameters undocumented, an agent still lacks the usage and parameter context needed to call this correctly, leaving the definition adequate but incomplete.

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

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

Schema description coverage is 0% for both limit and window_hours, so the schema contributes nothing and the description must compensate. It never mentions either parameter or what a window or limit means for the returned graph, so the agent has no basis for choosing values beyond the bare defaults.

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 and enumerates the concrete outputs an agent will get: top edges (who→whom, USDC), recurrent payments, and hub detection. That is far more specific than the sibling names like get_signals or get_trending_agents, and it clearly scopes the tool to the A2A payment graph rather than reputation, liveness, or SLA. The verb is only implied by the tool name, so it stops short of a 5.

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

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

There is no when-to-use statement, no condition that distinguishes this from get_trust_forensics, get_reputation_summary, or the other graph-adjacent siblings, and no prerequisites or exclusions. The agent must infer from the noun phrase 'A2A payment graph' alone that this is the tool for machine-to-machine payment flow analysis.

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?

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral fact — statuses are derived from real on-chain activity rather than self-reported state — which helps an agent trust the output. However, it says nothing about refresh cadence, staleness of the underlying data, or what 'dormant' vs 'stale' actually mean operationally.

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

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

A single tight sentence with the resource front-loaded and the status vocabulary enumerated compactly. Nothing is wasted, though the dash-clause structure packs two ideas into one line and could be slightly clearer.

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?

An output schema exists, so return values need not be explained, and the description adequately conveys what the tool reports. The gaps are the undocumented `limit` parameter and the absence of any routing guidance among ten sibling tools, which leaves it minimally viable rather than 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% for the single `limit` parameter, and the description never mentions it. The only clue is the schema default of 100, so an agent gets no guidance on whether limit caps agents returned, pagination size, or something else.

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 (agent liveness) and enumerates the exact classification vocabulary it returns: alive/dormant/stale/dead/unknown. It also grounds the classification in a data source (actual on-chain activity). It does not explicitly contrast itself with siblings like get_agent_sla or get_reputation_summary, so it stops short of a 5.

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

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

There is no statement of when to reach for this tool versus check_wallet_reputation, get_agent_sla, or the other health-oriented siblings. The usage is only implied by the purpose statement, and no prerequisites, exclusions, or alternatives are offered.

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

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

With no annotations, the description carries the full burden, and it does add real context: metrics come from synthetic probing of endpoints and history only grows from prober start, which warns the agent about limited historical depth. It says nothing about permissions, rate limits, or error behavior, so coverage is partial rather than complete.

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

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

A single sentence that front-loads the metric inventory (uptime, p50/p95, flaps) before the probing caveat. No filler, though the parenthetical caveat is slightly compressed for a mixed-language audience.

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?

An output schema exists so return values need no explanation, and the description does name the returned metrics. However, the unexplained window_days parameter and the unresolved overlap with get_agent_liveness leave gaps an agent must guess at.

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 both parameters are undocumented in the schema. The phrase 'jednoho agenta' loosely implies the required agent_id, but window_days (default 7) — the parameter that controls the aggregation period for all reported metrics — is never explained, and the description 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 resource and metric set: SLA for a single agent, enumerating uptime %, p50/p95 latency, and flaps from synthetic endpoint probing. An agent knows what it returns, but the description does not distinguish it from the sibling get_agent_liveness, which is a real confusion risk given the overlapping 'liveness' framing.

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

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

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over get_agent_liveness or get_execution_health. The probing note is behavioral context, not usage direction, so the agent must infer selection criteria entirely on its own.

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

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

With no annotations, the description must carry the behavioral load. It usefully discloses that no API key is required and that subnet data is out of scope, but says nothing about caching, freshness, rate limits, or failure behavior. Output schema exists, so return-shape disclosure is not expected.

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 fragments, zero filler, with the scope statement front-loaded. It is terse to the point of being cryptic, and mixing Czech with English technical terms adds a small comprehension cost.

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

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

For a zero-parameter read tool with an output schema, the essentials are present: what it returns, the no-key requirement, and the subnet-data exclusion. It stops short of stating read-only/non-destructive behavior and freshness expectations, which the absent annotations would otherwise have to cover.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a 0-param tool applies. Schema description coverage is 100%.

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 and scope: Bittensor network liveness, and enumerates what it surfaces (peers, head block). That is more concrete than the bare tool name. It does not, however, differentiate itself from health-adjacent siblings such as get_execution_health or get_agent_liveness.

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?

"Bez klíče — žádná subnety data" implies a credential-free call and excludes subnet-level data, which gives the agent some routing signal. It never names an alternative tool or states positively when this tool should be chosen over the sibling health/reputation tools.

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?

No annotations are provided, so the description carries the full behavioral burden. It mentions what data is returned (rank, incentive, stake, roles, endpoints) but doesn't state whether it's read-only, if there are rate limits, authentication requirements, or how the trust ranking is computed or sorted.

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

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

A single sentence that is front-loaded and efficient, though the use of non-English term 'řazení' (sorting/ranking) may cause confusion for an English-speaking agent.

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

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

Given the complexity of a subnet trust tool with no annotations, no schema descriptions, and an output schema that exists but isn't referenced, the description is incomplete. It doesn't explain the output structure, parameter meanings, or operational context.

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?

With schema description coverage at 0%, the description should compensate but doesn't explain the netuid or limit parameters. Baseline for 2 parameters is 4, but the lack of param details in the description reduces this to 3 as it adds only marginal value beyond the schema's type information.

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 it returns neuron trust ranking in a subnet (rank × incentive × stake, validator/miner, endpoint), naming a specific resource. However, it's written in partially non-English text (řazení) and doesn't explicitly differentiate from sibling tools like get_bittensor_trust_overview or get_bittensor_network_health.

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

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

No guidance on when to use this tool versus alternatives such as get_bittensor_trust_overview or get_bittensor_network_health. The agent must infer usage context from the name and description alone.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: no read-only confirmation, data freshness, rate limits, or ordering behavior. It only hints at the trust proxy composition (activity, net flows), which is minimal.

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

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

It is short and front-loaded, but the mixed-language phrasing undermines clarity, so its brevity reflects under-specification rather than disciplined conciseness.

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?

An output schema exists so return values needn't be explained, but for a ranking/overview tool with an undocumented parameter and no annotations, the description leaves too much unspecified about what the overview actually returns and how to invoke it.

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

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

Schema description coverage is 0% for the single parameter top_n. The description only repeats 'Top N default 20,' which is already in the schema, and adds no meaning about what the ranking is by or how the cutoff affects 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?

The description conveys the topic (Bittensor subnets ranked by emissions plus a trust proxy built from activity and net flows), which loosely distinguishes it from siblings like get_bittensor_subnet_trust or get_bittensor_network_health. However, it lacks a clear verb and is written in a garbled Czech/English mix ('subnety dle emisí'), making the exact operation ambiguous.

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

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

There is no indication of when to use this tool versus the many related siblings (get_bittensor_subnet_trust, get_bittensor_network_health, get_trust_forensics). No prerequisites, exclusions, or alternative-routing guidance 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?

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral limit: Base's public RPC has no mempool, so no pending-transaction data will be returned. That is genuinely useful context beyond the schema, but it says nothing about freshness, caching, or rate limits on the call itself.

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

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

Two tight sentences with no filler, and the metric list is front-loaded before the caveat. Minor deduction for mixing Czech phrasing ('na Base', 'nemá mempool') into an otherwise English surface, which slightly muddies readability.

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?

An output schema exists, so return-value structure need not be explained, and the zero-parameter schema needs no elaboration. What remains missing is any sense of call frequency or what distinguishes this health check from the sibling network-health tools.

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; the baseline for a no-arg tool applies. The metric list does signal what the call's scope is, which is a small bonus.

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

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

Names a specific resource (execution health on Base) and enumerates the three metrics returned: RPC latency, agent activity, and gas trend. It is clearly distinguishable from siblings like get_bittensor_network_health or get_agent_liveness, though it never explicitly contrasts itself with them.

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

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

There is no statement of when to reach for this tool versus alternatives such as get_bittensor_network_health or get_agent_sla. The second sentence is a data-availability caveat rather than usage guidance, so an agent must infer that this is the general-purpose Base health probe.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only lists output fields. It does not confirm the operation is a read-only aggregation, mention scope (global registry vs. filtered), or describe any behavioral traits; the 'get' prefix implies a safe read but nothing is disclosed explicitly.

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 compact sentence with the data source front-loaded, and no filler. However, it is written in Czech while the tool name and all sibling names are English, which adds a small parsing burden and is a structural inconsistency for an agent.

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?

An output schema exists, so the return values do not need explaining, yet the description spends its whole budget restating those return values instead. For a zero-parameter read tool this is minimally sufficient, but no usage context or scope information is provided.

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. The description correctly implies the summary is unfiltered and registry-wide, consistent with an empty argument object, and there are no parameter semantics to clarify.

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

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

The description identifies the data source (ERC-8004 ReputationRegistry) and enumerates the metrics the summary contains (feedback count, agents with reputation, unique clients, average score), but it never states a verb or that it aggregates the registry into a summary view. It is a noun phrase listing outputs rather than a clear statement of what the tool does, and it does not distinguish itself from check_wallet_reputation beyond the word 'summary'.

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

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

There is no when-to-use guidance, no prerequisites, and no reference to any alternative. With siblings like check_wallet_reputation and get_trust_forensics present, an agent receives no signal about when the registry-wide summary is preferred over a per-wallet reputation check.

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

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: a public delay is enforced, data is in raw token units, and USD applies only to USDC. It omits pagination, rate limits, ordering, and auth requirements, so it is useful but incomplete for a no-annotation 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?

Three short fragments with no filler, so it is compact. The structure is fragmentary and mixes purpose, data units, and a cross-reference rather than front-loading a clean purpose statement, which slightly hurts scanability.

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?

An output schema exists, so return values need not be explained, but the definition still leaves the two input parameters undefined and provides no usage context. For a tool with zero annotation and zero schema-description coverage, the description does not supply enough to call it confidently.

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

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

Schema description coverage is 0% for both limit and min_confidence, so the schema itself gives no meaning. The description says nothing about either parameter, leaving their units, ranges, and effect on results completely undocumented.

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

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

The name and the phrase 'Veřejně publikované signály' identify the resource (signals) and scope (publicly published, with public delay enforced), which is enough to distinguish it from non-public data. However, it never states the verb operation (list/fetch) or what a 'signal' actually is, so the purpose is only implied.

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 points to verify_signal_proof for verifying signatures, which is a useful related-tool pointer, but it gives no when-to-use or when-not-to-use guidance and does not explain how this differs from sibling tools like get_reputation_summary or get_trending_agents.

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?

No annotations are provided, so the description carries the full burden. It discloses the ranking basis and the default-all tier behavior, but says nothing about ordering direction, result count, pagination, or that this is a read-only query — gaps that matter for a no-annotation 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?

A single tightly packed clause with no wasted words, and the scope/ordering is front-loaded. Its terseness borders on under-specification, but judged purely on size and structure it is efficient.

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?

An output schema exists so return values need not be described, but with zero annotations and zero schema descriptions the definition leaves the agent without usage context, limit semantics, or ordering direction. For a 2-parameter query tool with no structured documentation anywhere, this is too thin.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by explaining the 'tier >= filter, default all' comparison semantics and the tier default of -1, which is genuinely useful. It says nothing at all about 'limit' (default 20), leaving half the parameters undocumented.

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

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

The fragment names a resource (Solana 8004 agents) and an ordering criterion (ATOM trust quality), which does distinguish it from the Bittensor-focused siblings. But '8004 agents' and 'ATOM trust quality' are unexplained jargon, so the agent cannot be fully certain what entity is being returned or what the ranking means.

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

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

There is no when-to-use guidance and no named alternative, despite many plausible siblings (get_solana_trust_summary, get_trending_agents, get_agent_sla). Nothing tells the agent when this list is preferable to the trust summary or the trending list.

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?

No annotations are provided, so the description carries the full burden. It implies a read operation but says nothing about permissions, rate limits, whether this is a pure read or triggers analysis, or what the flags mean. The only behavioral hint is the list of metric names.

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

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

It is a single terse fragment that is well front-loaded, but the brevity here reflects under-specification rather than tight conciseness. It reads more like a label than a usable definition.

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?

An output schema exists, so return-value shape need not be described. However, with no annotations, 0% parameter coverage, and no usage or behavioral context, the definition leaves too much unresolved for an agent to invoke it confidently.

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

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

Schema description coverage is 0% and neither parameter is mentioned in the description. 'limit' is self-evident, but 'risk' is an untyped free-form string with no enum, no default meaning, and no documentation anywhere, leaving an agent unable to populate it correctly.

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 domain (Solana sybil forensics) and enumerates the exact signals it surfaces: reviewer concentration, ghost ratio, burst, and flags. This differentiates it from siblings like get_solana_trust_summary and get_solana_agents. The typo 'forensika' and the absence of a clean verb ('retrieve/analyze') keep it just short of a 5.

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

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

There is no statement of when to reach for this tool versus the many sibling trust/forensics tools, nor any prerequisite or exclusion. An agent must infer usage purely from the metric names. No alternative routing guidance is 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?

With no annotations and an output schema present, the description adds little behavioral context. It does not state that the operation is read-only, whether authentication is required, how fresh the data is, or any rate-limit behavior. It only restates output content that the output schema already covers.

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

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

A single, front-loaded sentence that includes the chain, network, and data dimensions. It contains no filler or redundant phrasing, making it appropriately sized.

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 no-parameter summary with an output schema, the basic coverage is acceptable, but the description omits when to choose it over the many related summary tools (e.g., get_reputation_summary, get_trust_forensics). Given the crowded sibling space, this gap matters for correct tool selection.

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 score is 4. There is no parameter syntax or filtering behavior to clarify beyond the empty 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 the specific resource (8004-Solana mainnet trust summary) and enumerates its contents (agents, feedbacks, trust tier distribution), making the tool's output clear. It does not, however, distinguish itself from close siblings like get_solana_agents or get_reputation_summary, so an agent still has to infer the difference.

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

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

No when-to-use guidance, no alternatives, no prerequisites. The description is a noun phrase with no indication of the scenarios that select this summary over similar sibling tools. It remains merely implied that it is a broad overview.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the sort order (volume then transaction count) and the hard cap of 20 results, which are behavioral traits not present in the schema. It does not state that this is a read-only operation, nor does it mention data freshness, auth requirements, or rate limits.

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 zero filler; the resource and ranking criteria come first, followed by the limit constraint. Every clause 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?

An output schema exists, so return values need not be explained. For a simple one-parameter read tool, the description covers what is returned, how it is ranked, and the result cap, which is sufficient to call it correctly; only permission/read-only context 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 0% for the single 'limit' parameter, so the description must compensate, and it does add a real constraint ('max 20') that is absent from the schema (no maximum is defined). It does not restate the default of 5, but the added bound is the more important piece of information.

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 (on-chain autonomous agents on Base) and states the ranking criteria (USDC transaction volume and transaction count), which is a clear verb+resource statement. It does not explicitly differentiate itself from siblings like get_agent_liveness or get_reputation_summary, but the resource is distinct enough that an agent can distinguish it.

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 term 'trending/most active' implies a discovery use case, and the ranking criteria hint at what the result is good for. However, there is no explicit when-to-use guidance, no mention of when not to use it, and no pointer to alternatives such as get_reputation_summary or get_agent_liveness.

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?

No annotations exist, so the description carries the full behavioral burden. It does disclose the analytical nature of the operation (forensic scoring, concentration metrics, burst detection), but says nothing about whether it is read-only, what data scope it queries, latency, or rate limits. It goes beyond a bare name but falls short of the operational transparency a no-annotation tool requires.

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?

One dense sentence front-loads the forensic scope and the analytic outputs, followed by the filter note. Every clause earns its place, though the terse enumeration makes it slightly harder to skim.

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?

An output schema exists, so return values need not be described, and the risk filter values are given. However, the undocumented 'limit' parameter and the absence of any usage/routing guidance leave the definition only minimally complete for a no-annotation analytics 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 0%, so the description carries the burden. It documents the valid values for 'risk' (high|medium|low), which usefully compensates for that parameter, but the 'limit' parameter (default 50) is left entirely unexplained in both schema and description.

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

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

States a specific verb+resource (Sybil forensics over ERC-8004 feedbacks) and enumerates the analytic outputs: risk distribution, per-agent Herfindahl reviewer concentration, ghost-reviewer ratio, burst detection, and miner-vouch vs earned segmentation. This clearly separates it from siblings like get_reputation_summary or check_wallet_reputation, though it never explicitly names a sibling to route away from.

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

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

No when-to-use or when-not-to-use guidance is given; it never says whether to call this before or after generating a signal, or how it differs from check_wallet_reputation. The only hint is a filter value list, which is a parameter detail rather than usage 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether verification is read-only, whether it requires auth, how failures (invalid signature) are surfaced, or what 'key info' actually contains. Only the return hint 'valid + key info' adds anything beyond the name.

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

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

Two short sentences, front-loaded with the action and followed by the return hint. It is efficiently sized, though the terseness borders on under-specification given the undocumented nested payload.

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?

An output schema exists, so return values need not be described, but the required nested signed_payload is entirely undocumented in both schema and description, and there is no annotation coverage. For a tool whose only input is a structured proof object, that is a substantial gap.

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

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

Schema description coverage is 0% and the single parameter is a nested object with additionalProperties=true, so the agent gets no idea what fields the signed_payload must contain (signature, public key, message?). The description does not compensate at all, leaving a real invocation risk.

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 and resource: it verifies a Proof-of-Signal (ed25519) signature against a payload, and it states what it returns (valid + key info). That is far more specific than a tautology, though it offers no differentiation from sibling verification/reputation 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?

There is no indication of when to reach for this tool versus the ten siblings (get_trust_forensics, check_wallet_reputation, etc.), nor any prerequisites or when-not-to-use guidance. Usage must be inferred entirely from the name.

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