Registrai Arc data

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing the payload contents, which matters because there is no output schema.

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

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

One tightly packed sentence with the resource stated first and details trailing. The parenthetical is slightly dense but every clause carries information, with no filler.

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

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

For a read-only, single-parameter detail tool with no output schema, the description covers input format, source of ids, and return contents. The only gap is the lack of differentiation from the arc_app_history siblings.

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

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

Schema description coverage is 0% and the single 'id' parameter is undocumented in the schema. The description compensates well by giving concrete id formats ('domain:archery.wtf, integration:uniswap') and pointing to arc_apps as the source.

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 (one Arc app) with its identifier form and lists the exact data returned (24h stats, contract count, verified status, 7 days of hourly rows). The parenthetical 'ids come from arc_apps' distinguishes it from the listing sibling, though no explicit verb (get/fetch) is stated.

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

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

The phrase 'ids come from arc_apps' implies the retrieval workflow and prerequisite, which is useful. However, it gives no guidance on when to prefer this over the overlapping arc_app_history or arc_app_history_deep siblings, which also surface hourly rows.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds two genuine behavioral facts beyond that: results are ordered oldest first and all metrics live in a single index/response. It says nothing about result caps, pagination, or empty-range behavior, so it does not go beyond the minimum.

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 with the resource, granularity, metric list and ordering all front-loaded and no filler. Every clause 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?

With no output schema, the description usefully enumerates the returned metrics and the sort order, which is the key return-value information. It leaves out result-volume limits, pagination, and how to interpret an empty history, so it is nearly but not fully complete for a 4-parameter time-series 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 description coverage is 75%: 'from' and 'to' document their ISO-hour-close format and inclusivity, and 'index' spells out the abi/aii/aei enum meanings. The description adds no parameter meaning at all, and 'id' remains undocumented in both places. With the schema doing most of the work, 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 gives a specific verb-like outcome (hourly points and activity) scoped to a single Arc app and names the concrete metrics returned (payments, paying wallets, new payers, USD). It is clear what the tool produces, but it never names the sibling it is distinct from (arc_app, arc_app_history_deep, arc_index_history), so the agent must infer the hourly-vs-deep distinction.

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

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

Usage is implied rather than stated: 'hourly' and 'oldest first' suggest this is the time-series view for one app, as opposed to the summary arc_app or the deeper arc_app_history_deep. There is no explicit when-to-use/when-not-to-use statement or mention of any alternative tool.

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, closed-world). Beyond that, the description adds real behavioral context: a fixed 24-hour observation window and the specific currencies and fields covered, which tells the agent exactly what freshness to expect. No pagination or return-shape detail is given.

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

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

Three tight sentences: payload first, then usage triggers, then exclusions. No filler, and the scope-defining content is front-loaded.

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

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

With no output schema, the description usefully enumerates what comes back and the time window, which is enough to call the tool for a listing. The only real omission is any meaning for the sort parameter, leaving a small gap for a single-parameter 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?

There is one parameter (sort) with 0% schema description coverage and an unexplained enum value ('points' is never mentioned in the description). The description lists output fields but says nothing about what sort controls or how the four enum modes differ, so it fails to 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?

The description names the resource ('every app on Arc in the indices') and enumerates the exact payload (24h stablecoin payments in USDC/EURC, USD volume, verified status, first-seen hour). This implicitly separates it from siblings like arc_new_apps or arc_verified, though no sibling is named outright.

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 positive triggers ('which apps use USDC on Arc, or which are most used') plus explicit exclusions ('Not for token prices, DeFi TVL or chains other than Arc'). It stops short of naming a concrete alternative sibling tool, so it is clear context rather than full when/when-not/alternative routing.

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

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

Annotations already cover safety traits (read-only, non-destructive, idempotent, closed-world), so the description only needs to add context. It does so by explaining the ranking metric and that results include when each app was first seen in the index, but it stops short of mentioning result size, freshness limits, or other operational caveats.

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 a single efficient sentence followed by a targeted usage sentence. The ranking basis is front-loaded and no words are wasted.

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

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

For a zero-parameter, read-only tool with no output schema, the description gives enough detail to understand what is returned: ranked apps with payment metrics and first-seen timing. It does not clarify result count or pagination, but that is a minor gap rather than a blocker.

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 has zero parameters, so there are no parameter semantics to document. Per the rubric, this baseline is 4.

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 clearly states the resource (apps on Arc), the time window (last 7 days), and the ranking basis (stablecoin payments received with USD, payments, and new paying wallets). It is specific enough to separate this from generic app-listing siblings, though it does not explicitly name or contrast with tools like arc_new_apps.

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 concrete user intents: 'which apps on Arc are most used,' 'which accept USDC,' and 'what is new on Arc.' This is clear usage context, but it does not explicitly state when not to use it or name an alternative tool for overlapping questions.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds scope context — that results span apps, wallets, exchanges, banks, infrastructure and partners, each tagged with a status — but says nothing about result volume, pagination, or how the directory is kept current.

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

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

Three short sentences, front-loaded with what the tool returns, then usage, then exclusion. The trailing 'Not for token prices' exclusion is somewhat wasted since no token-price sibling exists, but overall the text is tight.

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, but the description adequately conveys the return shape (projects with category and status). For a zero-required-parameter read tool whose safety traits are already annotated, the remaining gap is minor: no hint about result size or paging.

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

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

Schema description coverage is only 33%: 'q' is described as 'Name contains' while status and category rely purely on their enums. The description never mentions that these filters exist or how they interact (e.g., whether filters combine with AND), so it does not compensate for the coverage gap.

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

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

States a concrete resource — the Arc ecosystem directory — and enumerates the entity types and status values it covers, so an agent knows exactly what it retrieves. It does not differentiate itself from close siblings like arc_apps or arc_entity, which also appear to return project-level data.

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

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

Gives explicit triggering questions (what exists on Arc, which projects are in a category, whether a company is on Arc) and one exclusion (token prices). However, it never names the alternative sibling tools to use instead for those adjacent questions, so routing between arc_apps, arc_entity, and this directory is left 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 readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds value by enumerating what the response contains (summary, status with evidence, links, contracts on Arc, sources), which matters since there is no output schema. It says nothing about unknown-slug behavior or completeness of coverage, keeping it below a 5.

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

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

A single dense sentence that front-loads the resource and lookup key, then projects the returned content. No filler, no restatement of the title.

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

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

With no output schema and full annotation coverage, the description supplies what an agent needs: what the identifier is, where to get it, and roughly what comes back. It omits edge behavior (invalid/missing slug, whether the record can be stale) but nothing essential to a correct call 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 slug parameter, so the description must carry the meaning — and it does, explaining that the slug identifies a project and that valid slugs originate from arc_ecosystem. No format example is given, but the origin guidance is the practically useful detail.

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 (one project in the Arc ecosystem directory) and the exact lookup key (slug), which clearly separates it from the list-style siblings (arc_apps, arc_ecosystem, arc_verified). The phrase 'by slug' signals a single-item detail fetch rather than a search or enumeration.

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 a concrete precondition for use: slugs come from arc_ecosystem, which tells the agent to obtain valid input from that sibling first. It does not state when NOT to use this tool or contrast it with arc_app/arc_app_history, so it falls short of a full routing guide.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds return ordering and the size ceiling, but never says what happens when the requested window exceeds 31 days (error, truncation, or silent clamp) or how to page past 744 hours — a real gap given the limit is stated.

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

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

Two tight sentences with the resource and its cardinality front-loaded, followed immediately by the use case. No filler or restatement of the title.

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

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

For a simple read-only, single-index time-series fetch with full schema descriptions and safety annotations, the description covers what the tool is and when to reach for it. The only meaningful omissions are window-overflow behavior and how to retrieve more than 31 days, both minor but not zero-cost for an agent planning a long-range chart.

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%: from/to carry ISO hour examples and the index enum is documented field-by-field. The description adds no syntax, timezone, or defaulting detail beyond what the schema already states, 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?

States a specific verb and resource — 'Hourly closes of one Arc index' — plus the ordering ('oldest first') and a hard cap ('at most 744 hours per call'). It does not, however, differentiate itself from the nearest sibling arc_index_history_deep, so an agent must infer which of the two to pick from the description alone.

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 intended context: 'Use this for charts or changes over a window of up to 31 days.' That is a usable when-to-use signal, and the 744-hour cap implicitly bounds the tool. It stops short of naming the alternative (arc_index_history_deep) for longer windows, so the exclusion side is left 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 the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is low. The description adds value by disclosing what the payload contains (index closes plus 24 h change base and decay parameters), though it says nothing about refresh cadence, staleness, or pagination.

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

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

Two sentences, no filler, and the most decision-relevant information (which indices and what timestamp granularity) is front-loaded before the usage cue.

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

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

For a zero-parameter, read-only snapshot tool with no output schema, the description supplies enough about the returned content (three indices, 24 h change, decay parameters) to call it correctly. The domain jargon ('24 h change base', 'decay parameters') is left unexplained, which is the only real 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, so there is nothing to document and the baseline is 4. The description correctly implies a no-argument snapshot call rather than a query requiring inputs.

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

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

The description names the exact resource and scope: the hourly close of the Arc Builders, Integrations and Ecosystem indices (ABI, AII, AEI), with explicit abbreviations. 'Latest' cleanly separates it from the arc_index_history / arc_index_history_deep siblings, so an agent can pick it without opening a schema.

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

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

It gives a concrete trigger: 'Use this when asked how Arc app activity is trending overall.' That is clear context, but it names no alternatives or exclusions (e.g. when to prefer arc_index_history for trends over time or arc_app for single-app detail).

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that — no ordering, result caps, or pagination guidance for what could be a large set of 'new' apps. With rich annotations the bar is lower, so this is minimum-viable rather than deficient.

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

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

Two short sentences with no filler; the scoping definition is front-loaded and the usage cue follows immediately. Every clause earns its place.

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

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

For a two-parameter, read-only, fully documented schema with no output schema, the description supplies enough to call the tool correctly. It could be marginally richer about the shape of results (e.g., ordering or limits), but nothing essential 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% and the enum values (abi/aii/aei) are already explained in the schema, so the schema carries the parameter burden. The description only restates the temporal window ('after a given hour') without adding format or boundary semantics beyond the schema's ISO-hour note. 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 states a specific resource and scope: Arc apps 'first seen in an index after a given hour.' This distinguishes it from the broader arc_apps sibling, though it never names that sibling or arc_app_history explicitly. An agent can infer the difference from 'first seen ... after a given hour' alone.

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?

'Use this when asked what is new on Arc' gives a clear triggering context for invocation. It stops short of naming alternatives (arc_apps, arc_app_history) or stating when not to use it, but the usage context is 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavioral context beyond that: figures are sourced from DefiLlama and each value carries its own source and date, which tells the agent the response is attributed and time-stamped rather than live-updating.

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

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

Two sentences, zero filler, with the data inventory front-loaded and the usage triggers following. The middle enumeration is long but every listed item is a selection signal, so density is justified rather than padding.

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

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

With no output schema, the description must describe the return payload, and it does so by enumerating the metrics and noting each has a source and date. Coverage is adequate for a zero-parameter read tool; only the exact response shape (nesting, per-metric units) is left unspecified, which is a minor 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 no parameters, so the schema carries nothing to interpret and the baseline is 4. Nothing in the description contradicts or needs to compensate for 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?

States a specific resource ('Chain-level Arc numbers') and enumerates exactly what it aggregates: USDC/EURC supply, stablecoins, TVL, volume, apps/projects, index closes, timeline. That scope reliably distinguishes it from the per-entity siblings (arc_app, arc_contract, arc_entity), though it never names a sibling explicitly and the 'index closes and a dated timeline' phrasing partially overlaps arc_indices.

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 invocation triggers — 'how big is Arc', 'how much USDC is on Arc', 'Arc's TVL or volume' — which map cleanly to real user phrasings. It stops short of any when-not guidance or explicit alternative (e.g. use arc_apps for a project list), so routing is aided but not fully resolved.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description contributes real domain context by defining what 'verified' means (builder proof validating against the Arc mainnet builder registry), but says nothing about result volume, pagination, or whether verification is re-checked live.

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

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

A single tight sentence with no filler, and the distinguishing criterion is placed immediately. It is under-specified rather than verbose, so the brevity costs it little here.

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

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

For a zero-parameter read-only filter tool with no output schema, the description conveys the selection rule but not the return shape (list of projects? names? addresses?) or ordering. Adequate but leaves an agent guessing about what it will actually receive.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description does not need to compensate for any schema gap.

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

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

The description names a specific selection criterion — projects whose builder proof validates against the Arc mainnet builder registry — which is more than a restatement of the title. However it is a bare noun phrase with no verb, so it never states whether the tool lists projects, returns a count, or returns a boolean, and it draws no boundary against the many sibling listing tools (arc_apps, arc_new_apps, arc_project_scope).

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 mention of alternatives, and no indication of how this differs from arc_apps or arc_project_scope. The agent must infer from the name alone that this is the filtered 'verified builders' variant.

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