NEARpedia

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

With no annotations, the description carries the burden and does well: it discloses that results include the replacement plus the source and date of the claim, that only one file is analyzed, and which file types are accepted. It does not state whether the tool is read-only/network-backed or what happens on unsupported or empty input, but for an obviously non-mutating analysis tool this is a minor gap.

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 is front-loaded and the progression from what it finds, to accepted input, to when to use it, to the sibling alternative is logical. The opening sentence is overloaded with parallel lists ('removed, deprecated, changed or superseded' plus a parenthetical enumeration) that could be tightened, but no sentence is truly 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?

There is no output schema, and the description compensates by explaining that each finding comes with its replacement and the source and date of the claim. Combined with the input constraints, the NEAR-only scope and the routing to check_deprecation, an agent has everything needed to call this 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%, so filename, language and code are already documented, including that filename picks the language. The description echoes the accepted file types and the single-file constraint, adding modest reinforcement but no syntax or format detail beyond the schema. 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 concrete verb (check/find) and a precisely scoped resource: lines that import, depend on, call or configure entities removed, deprecated, changed or superseded in NEAR, plus yanked dependencies and breaking lines. The parenthetical enumerates the exact categories (archived SDKs, removed protocol actions, deprecated RPC methods, retired endpoints), and it explicitly contrasts itself with the sibling check_deprecation, so an agent can distinguish the two without opening either schema.

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

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

Gives explicit when-to-use conditions ('on code written from memory, or when reviewing NEAR code'), an explicit scope exclusion ('NEAR only'), an input constraint (one file), and a named alternative with the discriminator ('For one name rather than a file use check_deprecation'). Nothing about selection 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?

With no annotations, the description carries the disclosure burden and usefully states that every claim includes a source and date, plus replacement guidance. It also scopes the tool to NEAR. It does not explicitly state read-only behavior, rate limits, or no-match/error semantics, but the check-style operation and provenance details cover the main behavioral expectations.

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, followed by concrete examples, a usage trigger, and a scope restriction. Every sentence contributes useful selection or formatting information, and there is 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 tool with no output schema and no annotations, the description explains what kind of answer to expect: deprecation/removal/change status, replacement guidance, and source/date provenance. It could say more about output shape or no-result behavior, but it is complete enough for an agent to call the tool 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 already 100%, so the baseline is 3. The description adds meaningful semantics by explaining that the name should be passed exactly as code or config uses it, with concrete examples covering scoped npm packages, crates, identifiers, RPC methods, repositories, and hosts. The limit parameter is left to the schema.

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

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

The description states a specific verb and target: check whether a named NEAR package, crate, repository, RPC method, protocol feature, config key, or hosted service is deprecated, removed, or changed, and what replaces it. It also adds source/date provenance, making the tool's purpose more precise than a generic search or changelog tool.

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

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

It gives a clear usage trigger: use before writing or reviewing NEAR code that names a package or API from memory. It also gives an exclusion: NEAR only, and packages from other chains should use their own tools. It does not explicitly route between sibling tools such as get_breaking_changes or resolve_package.

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 disclosure burden and does well: it reveals the answer's provenance (curated catalog validated against docs.near.org each sync, deprecation entries, forum threads, GitHub issues quoting the same error). It does not state what happens on an unmatched error or any rate/limit behavior, so it falls short of full transparency.

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 verb and outcome before the source list, and every clause adds information about where the explanation comes from. The single long sentence is dense and slightly run-on, which costs it a point.

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

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

For a one-parameter, read-only lookup with no output schema, the description covers inputs, evidence sources, and the shape of the answer. It omits the fallback behavior when no catalog match exists, which is the main remaining gap for an error-lookup 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 100% and the single parameter is self-documented, so the baseline is 3. The description earns above baseline by characterizing what counts as valid input (RPC responses, panics, CLI output) and stressing that the raw error text itself is required, which the schema's "as printed" note only partly conveys.

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 ("explain a NEAR error") plus the concrete payoff ("cause and fix"). The parenthetical enumerates accepted inputs (RPC response, transaction failure, contract panic, CLI output), which distinguishes it from siblings like check_code, find_known_issues, or semantic_search without opening any schema.

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

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

Usage is clear from the enumerated input types and the prerequisite "Needs the error text itself," making the trigger condition obvious. However, it never names an alternative tool or a when-not case (e.g., what to use when you only have a package name rather than error text).

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 real work: it discloses that every code block is run through check_code first, that live-API examples rank ahead of stale ones, and that deprecated blocks are returned with an indication of what is stale. It omits return-shape details (e.g. whether source URLs or the check_code verdict are included), which keeps it from a 5.

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

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

Two sentences with no filler and the source scope front-loaded. The first sentence is overloaded, stacking the check_code pipeline and the ranking rule into one long clause chain, which makes it slower to parse than it needs to be.

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 lookup with no output schema and no annotations, the description covers sources, validation, ordering, and stale markup — enough for an agent to call it correctly and interpret ordering. Minor gap: it does not say what a returned example looks like beyond the ordering rule.

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 both parameters are already documented, and the description adds only indirect guidance via its quoted topic phrasings. The limit parameter and its interaction with filtering (are stale examples counted toward the limit?) are not addressed at all.

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 ('find code examples') plus the exact corpora searched (docs.near.org and gov.near.org), which distinguishes it from the generic search/semantic_search/get_doc siblings. It also names check_code as an internal validation step, so an agent knows this is a curated-example tool, not a raw search.

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?

Quoted example queries ('show me how to call a contract from near-api-js', 'cross-contract call in Rust') make the intended use case concrete and easy to match against a user request. It stops short of explicit exclusions — it never says to use get_doc or semantic_search instead when the user wants prose rather than runnable code.

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 supplied, the description carries the full behavioral burden and does most of it well: it names the two upstream sources, declares that unresolved/open status is the filter, and warns that no match yields nothing. What is missing is the shape of a returned row and whether results are ranked or capped beyond the limit parameter, so the agent cannot fully predict output structure.

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

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

Front-loaded with the core action and sources, then exclusions and the alternative route, which is the right ordering for an agent scanning for relevance. It is dense with clauses and slightly repetitive on the fixes/how-to exclusion, but nearly every sentence adds routing or scope information.

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

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

For a two-parameter read tool with no output schema and no annotations, the description covers scope, sources, empty-result behavior, and sibling routing, which is enough to call it correctly. The remaining gap is return-value structure, which the absent output schema leaves entirely to inference.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the limit bounds and the hint that error messages belong to explain_error. The description restates "free-text description" and the error-message routing but adds no new syntax, length, or formatting guidance, 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 ("Surface known UNRESOLVED problems") and enumerates the exact data sources: forum threads with zero replies but high views plus open GitHub issues. It also frames the user question it answers ("is anyone else hitting this?"), which lets an agent distinguish it from diagnostic siblings like explain_error or semantic_search without opening any schema.

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

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

Explicitly gives the when-to-use case, the when-not-to-use case ("Does NOT return fixes, solutions, config, or how-to steps"), and names the alternative path for the excluded case ("use semantic_search (then get_doc) instead"). It also notes the empty-result condition, so the agent knows a null return is not a failure.

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 well: it discloses the underlying dataset and size (NEAR Catalog, 340), the fields returned, and edge-case behavior (empty query returns top-TVL projects; unknown category returns the category list). It omits anything about ranking for text queries, pagination beyond limit, or error/permission behavior, which keeps it short of 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?

Purpose and scope are front-loaded, followed by returnable facets, then behavioral edge cases, then example prompts. The middle facet list is dense and slightly enumerative, but every element maps to something an agent needs to judge relevance; nothing is 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?

No output schema exists, and the description compensates by listing the per-project fields an agent will get back, plus default-limit behavior (5, up to 50 for a full category). It is near-complete for a 3-parameter read tool, with only result ordering for text queries and truncation behavior left unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that an empty query is a listing mode ordered by TVL, that category alone can enumerate a whole vertical ('Wallet', 'DEX', 'Validator'), and that query accepts natural-language descriptions of what a project does. That goes beyond the schema's terse field notes and helps the agent choose parameter combinations.

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 opens with a specific verb and resource ('Find NEAR ecosystem projects in NEAR Catalog (340)') and immediately scopes what can be searched (name, function, category). It enumerates the returned facets (category, phase, website, GitHub, tokens with NEAR contract, TVL, security incidents, partner status), which clearly separates it from generic siblings like search or semantic_search.

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?

Concrete trigger examples ('what is Rhea Finance', 'which wallets can I use on NEAR', 'has Meta Pool been hacked') and the empty-query / whole-category behavior give clear guidance on when to reach for this tool. It never explicitly names a sibling such as search or get_contract_info as the alternative, so the routing to other tools is left implicit.

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 load and does real work: it discloses that NEAR articles, news and press releases come back in full while reprints and partner press come back as an excerpt with a source link, mirroring website behavior. It also explains the truncated-read/offset-continuation model, though it says nothing about error handling or any access constraints.

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

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

Purpose and the field list are front-loaded in the first sentence, and each subsequent clause adds usable information about full-vs-excerpt content and pagination. A few phrases ('the same as the website') are chattier than needed, and the colon-heavy first sentence is slightly awkward.

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 three-parameter read tool with no annotations and no output schema, the description covers the essentials: what is returned, why some posts are truncated to excerpts, and how to page through long text. The main omission is what happens for an invalid or unpublished id.

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

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

Schema coverage is 100%, so the baseline is 3, but the prose adds a reading model beyond the field docs: it frames offset as continuing a long post past the first part. That complements rather than repeats the schema's character-position wording, and the id's provenance is reinforced.

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 ('Get one blog post by the id') and immediately names the return fields (title, kind, author, date, text). It also distinguishes itself from siblings by tying the id to 'list_blog_posts or search', so an agent can tell how this differs from the listing tool.

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

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

The description explicitly tells the agent where the required id comes from ('list_blog_posts or search gave') and when to use offset ('to keep reading a long post past the first part'). It does not state exclusions or failure conditions (e.g., unknown id), so it falls just short of a full when/when-not treatment.

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 burden and does disclose the return payload: all intermediate releases, deprecation/removal markup, breaking tags, and nearcore flags, which tells the agent the result is aggregated rather than a single diff. It omits edge-case behavior such as what happens for unknown products, unavailable versions, or non-existent ranges, so the disclosure is rich but not 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?

Front-loaded with the outcome, then scope, then the usage example, with no filler sentences. The enumerated product list duplicates the schema's own enumeration, which is mildly redundant but short enough not to crowd out the substantive content.

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 three-required-parameter read tool with no annotations and no output schema, the description covers purpose, supported inputs, what is returned, and the motivating scenario. What is missing is failure/empty-result behavior and the provenance of the breaking-change data, which matters for a tool whose value rests on completeness of intermediate releases.

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

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

Schema description coverage is 100%, so product, from_version and to_version are already documented in the schema, including the GitHub-repo alias form and prerelease semantics. The description mostly repeats the product list and only adds value through the worked example that shows valid version values; 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 (breaking changes between two versions of one NEAR product) and enumerates exactly what comes back: every intermediate release, removals/deprecations from notes, breaking-marked lines, and nearcore's CODE_COLOR, PROTOCOL_UPGRADE and SECURITY_UPGRADE flags. This is clearly distinct from a general changelog tool like get_recent_changes because of the explicit between-versions, breaking-only 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?

Provides a concrete when-to-use trigger ("Use when upgrading") plus a real example question mapping a migration from 5.1.0 to 7.4.0. It does not name a sibling alternative or state when not to use it (e.g. for a single release's full notes), so it stops short of full routing 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?

With no annotations, the description carries the full burden. It usefully discloses that data is read live from RPC (not cached/curated), which tells the agent results reflect current chain state. It does not cover failure modes (unknown account, EOA with no code), rate limits, or response shape beyond the field list.

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 front-loaded sentence that puts the verb and resource first, then the payload. It is dense but every enumerated item is return-value information that substitutes for the missing output schema, so little is wasted; the one-sentence enumeration does hurt scanability slightly.

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 2-parameter read tool with no output schema, the description substantially covers what comes back (balance, storage, code hash/size, exported methods, NEP-330 metadata, standards, FT/NFT metadata, partner/catalog/deprecation flags), which is the main completeness risk here. Remaining gaps are error/edge-case behavior, not core capability.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the mainnet default for network. The description adds no syntax or format detail for account_id and no meaning for network beyond what the schema states; 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?

Names a specific verb+resource ('What is deployed on a NEAR account, read live from RPC') and enumerates the returned fields, so the agent knows it is a full account/contract profile rather than a single-fact lookup. It doesn't explicitly distinguish itself from overlapping siblings like check_code, get_standard, or get_partner, but the breadth of the enumeration makes the scope recognizable.

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 only implied: the enumerated payload suggests 'use this when you need a comprehensive profile of an account in one call.' There is no explicit when-to-use versus check_code/get_partner, and no stated exclusions or prerequisites (e.g., whether the account must be a deployed contract).

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 supplied, the description carries the full burden and does disclose the key operational traits: posts come back in order, 15 at a time, and a URL ending in a post number starts reading there. It says nothing about authentication, rate limits, failure behavior on a bad topic id, or whether thread metadata (title, category) is included in the response.

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 front-loaded sentences: scope first, then input provenance and return/pagination behavior. The content-type list is the only expansion and it earns its place by telling the agent what a thread contains.

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 tool this is close, but with no output schema the agent gets no picture of a post's shape (author, timestamp, body, nesting) or of what else the response carries. Error handling for an unresolvable topic id is also unaddressed.

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 both parameters are already documented, and the description largely restates the accepted input formats rather than adding new ones. The one genuinely additive fact is the page size of 15, which frames from_post as a pagination cursor — a modest but real gain over the schema.

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

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

"Read a gov.near.org forum thread in full" gives a specific verb and resource, and the example list (proposal debate, validator threads, incident write-ups) scopes the content types well. It implies but never states the boundary against get_proposal or list_proposals, so an agent must infer that this returns the surrounding discussion rather than the proposal record itself.

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 workflow cue: use the topic number or URL produced by search, semantic_search, or get_proposal, which tells the agent this is a follow-up/expansion step after a discovery tool. It stops short of an explicit exclusion (e.g. "use get_proposal for the proposal text alone"), leaving that comparison 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?

With no annotations, the description carries the full burden, and it does disclose that this is a read of full untruncated content including exact commands, flags, and whole sections, which implies read-only behavior and potential large payloads. It stops short of stating what happens with an invalid or stale id, or any size/response limits for very long pages.

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

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

Three tight sentences, front-loaded with the verb and resource, then value proposition, then scope and prerequisite. Every clause adds a constraint or routing cue; nothing is redundant with the title or schema.

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

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

For a one-parameter retrieval tool with no output schema, the description covers what is returned (full page text with commands, flags, sections), the domain boundary, and how to obtain the id. The only meaningful gap is the absence of any note on response size or failure behavior for an invalid id.

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 already documented, so the baseline would be 3. The description adds genuine value by specifying the provenance of the id ('from search or semantic_search first') and narrowing the accepted domain to NEAR doc page ids, which the schema does not convey.

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 ('Read the FULL text of one indexed NEAR documentation page by id') plus the content domain (NEAR node and developer docs plus partner docs). It explicitly distinguishes itself from the retrieval siblings by contrasting full text against 'a search snippet truncates'.

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 positive selection rule ('Best for NEAR operational/how-to questions'), explicit exclusions ('NEAR docs only, not the docs of other projects or the web'), and a prerequisite workflow ('Get the id from search or semantic_search first'). An agent knows both when to call it and what must happen before calling it.

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 supplied, so the description carries the burden; it does convey that this is a read that returns the full record including a third-party (DefiLlama) description field. It does not mention behavior on an unknown/expired id, error semantics, or whether the payload is cached or paginated, leaving meaningful gaps 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 front-loaded sentence that identifies the resource, its scope, its payload content, and its id provenance with no filler. The inline example earns its space by pinning down the id format.

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 one required parameter at full schema coverage and no output schema, the description does the necessary work by sketching the return content ('in full, with DefiLlama's description'). Only failure-mode behavior for a bad id is left unstated, which is a minor omission for this complexity level.

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 already 100% and the schema documents the id parameter, but the description adds real value beyond it by giving a concrete format example ("llama-1546-2026-04-16") and naming the authoritative source of valid ids. That exceeds the baseline of 3 for a fully documented 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 precisely what is returned — a single NEAR ecosystem security incident 'in full, with DefiLlama's description' — and implicitly scopes it against the sibling list_incidents by requiring an id from that list. An agent can distinguish this from list_incidents without opening either 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?

The phrase 'by the id list_incidents prints' establishes a clear prerequisite workflow: call list_incidents first, then fetch a single record here. It stops short of explicit when-not guidance (e.g. don't call for bulk retrieval or with ids from other sources), so it falls short of a 5.

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

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

No annotations are supplied, so the description carries the burden; it discloses the upstream sources (CoinGecko, mainnet RPC), the live/read-only nature of the call, and temporal scoping ('24-hour change', 'this epoch'). It does not mention caching, latency, rate limits, or what happens when an upstream source fails, which are the remaining behavioral gaps for a live-fanout 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?

Front-loaded with the timeframe and read mode, then the payload, then the routing sentence — no filler. The payload enumeration is dense and the opening is a grammatical fragment ('NEAR right now, read live'), but 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 and no annotations, the description must communicate both what comes back and how it is safe to call; it does the former via the field enumeration and the latter via 'read live' and the source disclosure. Only failure/degradation behavior for the external price and RPC dependencies is left unstated.

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?

Zero parameters, so the baseline is 4; the description confirms this with 'No arguments,' leaving nothing for an agent to infer about 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?

Specific verb+resource ('read live' NEAR state) with an enumerated payload: price/market cap/24h change from CoinGecko plus block height, protocol/node version, total supply and stake distribution from mainnet RPC. It explicitly distinguishes itself from get_validators and get_protocol_status, so an agent can route 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?

Names both alternatives and the condition that selects each: 'For who the validators are, use get_validators; for the protocol upgrade vote, get_protocol_status.' It also states 'No arguments,' removing any invocation ambiguity.

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 supplied, so the description carries the full disclosure burden, and it does substantial work by listing the exact sections returned, including derived fields like how much of the partner's docs search and semantic_search cover. It does not say what happens for an unknown partner id, whether the result can be partial, or how large the payload is, which are the main remaining behavioral gaps.

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 content is front-loaded around a single framing sentence followed by the accepted-value list, and nearly every clause maps to something the tool returns. Slightly wasteful phrasing ('What an agent needs to build on a NEAR partner') and the length of the id enumeration cost it a point.

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

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

With one parameter, no annotations, and no output schema, the description must explain the return shape, and it does so in detail. Missing only error/not-found behavior and any indication of response size or nesting for a tool that clearly aggregates many sources.

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's own parameter description already states that id, name, contract account, or catalog slug are accepted, so the description's trailing sentence largely restates it. The one genuine addition beyond the schema is the explicit enumeration of valid partner ids, which helps the agent avoid guessing.

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 clear resource (a NEAR partner profile) and enumerates exactly what the response bundles: identity, mainnet contract accounts, GitHub, docs/llms.txt, doc-coverage stats, Catalog entry with TVL, and security incidents. It is specific enough that an agent can predict the payload, but it never names a sibling it is distinct from (e.g. find_project or get_contract_info), so full credit for sibling differentiation is not earned.

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 implied usage is clear from 'what an agent needs to build on a NEAR partner', and the trailing note clarifies the accepted key forms (contract account like "intents.near" or a catalog slug). However, there is no explicit when-to-use/when-not guidance and no alternative tool is named for cases where the agent only wants a single artifact such as contract info or a doc search.

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 supplied, so the description carries the full disclosure burden, and it does a solid job by spelling out exactly what the response contains (status, timeline, quorum/approval arithmetic, on-chain and gov.near.org links, proposal text). It omits error behavior — e.g. what happens when an id does not resolve — and says nothing about access or caching, which keeps 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?

Two sentences, front-loaded with the payload description before the input instruction, and no filler. The first sentence is a long multi-clause list, but each clause adds a distinct returned field 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 return values and does so thoroughly for this read tool. The remaining gap is failure handling for malformed or unresolved proposal identifiers, which is a minor but real omission for a lookup 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 100% and the schema already lists both accepted forms ('27', '#27', 'HSP-027', 'HSP 27'), so the description's restatement of those examples adds no new meaning. Baseline 3 is appropriate; nothing about the parameter's constraints or edge cases is added.

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 (a single NEAR House of Stake proposal) and enumerates its contents — status, timeline, vote/quorum arithmetic, chain and forum links, proposal text. The singular 'One ... proposal in full' plus the field list cleanly separates it from list_proposals without needing to name the 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?

Usage is only implied: fetching one proposal by id is obviously the use case, but the description never says when to prefer this over list_proposals or search/semantic_search, nor any exclusions. The input guidance ('Pass the on-chain id or the HSP number') is the only concrete instruction.

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 burden and does well: 'Live' signals a read of current state, and the parenthetical about 'how much of the stake it was read from' discloses a data-quality caveat an agent would otherwise miss. It does not state permissions, freshness/latency, or caching behavior, which keeps it short of 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?

Two sentences, front-loaded with what is returned and backed by a concrete use case. The first sentence is dense with a long comma-separated field list, but each listed item is informative rather than 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 tool with a rich, multi-field return and no output schema, the description enumerates the return contents thoroughly enough that an agent knows what it will get. It stops short of describing the response shape or units (e.g., how stake weight is expressed), a minor gap for a single-optional-parameter read 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 100%, including the enum and the 'both when omitted' default, so the schema already does the work. The description implies both networks are reported by default but adds no format or selection guidance beyond that, which matches the baseline 3 for high-coverage schemas.

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 (live NEAR protocol state for mainnet and testnet) and enumerates the exact payload: protocol versions, nearcore version, epoch progress, stake-weighted upgrade vote, threshold, vote start, and pending deprecations. That level of detail separates it cleanly from siblings such as get_network_state, get_validators, and check_deprecation.

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 when-to-use triggers, naming two real questions (whether DelegateV2 removal or the gas rebate is live, and when the next upgrade lands). It does not explicitly say when a sibling like check_deprecation or get_network_state would be the better call, so routing is clear but not fully exclusive.

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 supplied, so the description carries the full burden. It does disclose genuinely useful behavior: resolved items are excluded, security incidents are capped at 30 days, voting items persist only "until they close" or until the network upgrades, and each alert carries a deadline, expiry date, affected audience and source link. What it omits is any statement of cost, rate limits, freshness/caching, or what an empty result means — the description also never explicitly frames the call as a safe read.

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?

Dense but well ordered: identity and inclusion/exclusion rule first, then the enumerated sources, then the per-alert shape, then the filter, then concrete use queries. Every clause carries information; nothing is 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 and no annotations, the description does the necessary work by describing the per-alert fields (deadline, expiry, affected party, source link) and the freshness/liveness rules. Paging behavior is left to the schema, which documents it fully, so completeness is nearly there — only the response envelope shape and any cost/latency expectations are unaddressed.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the level enum's severity-floor semantics and limit/offset paging. The description's "Filter by level (critical/important/ecosystem/all)" merely restates the enum and says nothing about limit or offset, so it adds no meaning beyond the schema — 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 ("Get the NEAR Radar") and then enumerates the exact contents — protocol upgrades with validator votes, CODE_RED/security nearcore releases, House of Stake votes and timelocks, HSP drafts, 30-day security incidents, dated events. The inclusion criteria ("what is changing on NEAR now and needs action, and nothing that has already resolved") distinguish it clearly from sibling feeds such as get_breaking_changes, list_incidents or list_proposals.

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 trigger phrases ("what is about to change or break on NEAR", "is there a protocol upgrade", "what is House of Stake voting on") plus a negative condition (nothing already resolved), which is real usage guidance. It stops short of naming the overlapping siblings (get_breaking_changes, get_protocol_status, list_proposals) to say when those should be preferred instead.

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 ordering ('newest first') and per-item payload ('each item with its date and source'), plus the topical scope boundary. It omits anything about result volume or truncation behavior, which matters for a feed-style tool with a default limit of 50.

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 front-loaded with the core question and the scope disclaimer sits at the end where it does the most boundary-setting work. The middle enumeration is long but each listed category adds real coverage, so the density is justified rather than padded.

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, no-output-schema aggregator the description covers what kinds of things come back and in what order, which is the main risk area. Its gap is behavioral: nothing about the limit parameter, the 90-day ceiling, or what happens when more changes exist than fit in a response.

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

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

Schema coverage is 0%, so the description must compensate. It gives meaning to the time window ('last N days'), but says nothing about the undocumented 'limit' parameter, its default of 50, or the 1–90 day cap enforced by the schema, leaving the agent to infer truncation behavior.

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 opens with a specific verb+resource ('What changed on NEAR in the last N days'), then enumerates the concrete change types covered (archived repos, deprecated packages, protocol upgrades, House of Stake proposals, incidents, forum threads, radar alerts). The closing contrast 'NEAR activity only, not general crypto news' sharpens the boundary against non-sibling sources.

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 scope statement implies this is a broad recent-activity aggregator, which implicitly distinguishes it from narrow lookups like get_incident or list_proposals. However, it never explicitly says when to reach for this instead of siblings such as list_incidents, list_proposals, or get_breaking_changes, nor when not to use it.

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 well: it discloses that number lookups return the full text plus status, category, requirements, and replacement/supersession links, and that keyword lookups return a candidate standard. Gaps remain on what happens when nothing matches and on the remote-fetch nature of the call.

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

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

One dense sentence built on semicolons; the resource is front-loaded and the two modes are separated cleanly. It borders on run-on and could be split, but no sentence is 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 one-parameter read lookup with full schema coverage and no output schema, the description is nearly sufficient: it explains both input modes and sketches the return content. Only edge-case behavior (unknown NEP, empty search) is left unspecified.

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

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

Schema description coverage is 100%, so the schema already documents the single "nep" parameter and its dual number/word behavior. The description reinforces this with example queries ("fungible token", "storage"), but adds no format or matching semantics beyond what the schema states; 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?

Names the specific resource (a NEAR NEP standard from github.com/near/NEPs) and the two retrieval modes (lookup by number, or by keywords). A reader knows it retrieves the full text of a standard, which is clearly distinct from siblings like get_doc or get_proposal, though the verb itself is only implied by the leading noun phrase.

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 when implementing FT, NFT, storage management, events, source metadata or wallet standards" gives concrete triggering contexts. It also clarifies which mode to pick (number for full text, words to find one). No explicit when-not-to-use or named alternative (e.g. get_doc vs get_standard) 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, the description carries the full behavioral burden and does disclose that data is live ('right now'), sourced from RPC, and mainnet-only, plus that it reaches back to the last epoch for ejections. It says nothing about rate limits, caching/staleness, failure modes, or cost of the call. So it adds meaningful context but leaves operational behavior undisclosed.

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 resource is front-loaded and the returned fields are grouped logically, which is good structure. But the second sentence drifts into marketing cadence ('what someone choosing where to stake wants to know') and the semicolon-chained clauses make it denser than needed. Tightening would improve scanability without losing information.

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

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

For a two-parameter read tool with no output schema and no annotations, the description does the heavy lifting by enumerating the returned fields and the two operating modes. An agent knows what it will get in each case. The only gap is behavioral detail around freshness and limits, which is secondary here.

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 both parameters are already documented, warranting the baseline 3. The description does contribute framing the schema lacks: that `account` switches the tool into a single-pool mode returning rank, work, fee and vote, and that `limit` selects by stake ranking. That is value on top of the schema, but no format or edge-case detail beyond it.

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 (NEAR mainnet validators from RPC) and enumerates what it returns: stake share, epoch work done, protocol version, and last-epoch ejections with reasons. It also distinguishes the two modes (list vs. single pool lookup), so an agent can tell what it gets. It stops short of explicitly naming a sibling it should be preferred over, e.g. get_network_state or get_protocol_status.

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

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

There is an implied rule: pass a pool account for per-validator detail, omit it for the list, reinforced by the framing 'what someone choosing where to stake wants to know'. That is a real use-case cue. However, there is no explicit when-not-to-use guidance and no comparison against adjacent tools like get_network_state, leaving routing to inference.

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

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

With no annotations, the description carries the burden and does well: it discloses that only metadata is returned (id, title, kind, author, date), that full content requires a second call, and that release notes live elsewhere. It does not mention ordering, permissions, or rate limits, though the query parameter's schema note covers best-match ordering.

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

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

Five short sentences, each carrying a distinct fact (scope, default filter, search, return shape, exclusion), with the return-shape caveat front-loaded before the sibling call. The phrase "in tabs of their own partner press and third-party reprints" is slightly convoluted but still parseable.

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, and the description compensates by naming the returned fields and pointing to get_blog_post for the full record. Combined with the schema's paging and enum documentation, an agent has everything needed to call this correctly on the first try.

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 limit, offset, query, and source are already fully documented in the input schema. The description restates the source-omission behavior and query semantics but adds no syntax, defaults, or edge-case detail beyond what the schema provides, so 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?

Opens with a specific verb and resource ("List the blog posts nearpedia holds") and immediately enumerates the content kinds it covers (articles, news, press releases, partner press, third-party reprints). It is clearly distinguished from get_blog_post, which it names as the single-post reader.

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 routing rules: omit source for the All view, pass query to search titles and text, call get_blog_post with an id to read one, and look under /releases for release notes instead. Both the when-to-use alternative and a hard exclusion are stated.

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 well: it discloses ordering (newest first), the upstream data source (DefiLlama hacks dataset), and the fields returned. It also flags a real classification quirk — NEAR Intents is filed under BSC by DefiLlama but counted here — which is exactly the kind of caveat annotations would otherwise cover. It omits any statement about read-only safety, rate limits, or pagination 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?

The scope, output fields, and filter semantics are front-loaded in the first sentence, with the use cases closing it out. It is dense but every clause adds information; the parenthetical example is slightly long but justifies itself by explaining an upstream data quirk.

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 4-parameter, optional-only read tool with no output schema, the description covers what is returned, how results are ordered, and what the filters mean. Missing only the collection-vs-single-item routing relative to get_incident and any note on default/maximum result counts.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by defining the semantics of the relevance enum beyond the schema's terse 'Default near' — 'near' means hacks on NEAR/Aurora/NEAR protocols, 'related' means NEAR Catalog projects hacked on another chain. That distinction is not derivable from the schema alone.

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

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

The description names a specific verb and resource — security incidents from DefiLlama's hacks dataset — and enumerates the returned fields (date, amount lost and returned, technique, chains, source). That is far more specific than a tautology, but it never contrasts itself with the sibling get_incident, so an agent must infer that 'list' returns a collection while 'get_incident' returns one.

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 two concrete triggering scenarios: 'before integrating a protocol' and answering 'has X been exploited'. There is no when-not guidance and no explicit routing to get_incident for a single known incident, which keeps it 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?

No annotations are supplied, so the description carries the behavioral burden, and it does disclose ordering, that status output calls out lapsed deadlines, that vote standing is reported against quorum and approval thresholds, and that a gov.near.org thread is included. It does not state read-only nature explicitly, auth requirements, or whether status/query filters combine with AND or OR, leaving some behavioral inference to the agent.

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

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

Two sentences, front-loaded with the verb and resource, with the alternative tool named last where an agent would look for it. The middle return-field enumeration is dense but justified because there is no output schema; a slight trim of the field list would make it tighter.

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

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

With no output schema, the description correctly spends words on what comes back, and all three optional parameters are covered by the schema. The remaining gap is the absence of any statement about how multiple filters compose and what an empty result means, which matters for a filtered list 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 100%, so all three parameters are already documented and the description only restates that filtering is possible by status or by text in title/description. It adds no syntax hints, no note on interaction between query and status (intersection vs union), and no guidance on using the 50-item ceiling, 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?

The description opens with a specific verb and resource ("List NEAR House of Stake governance proposals"), names the source contract (vote.dao), states ordering (newest first), and enumerates the returned fields. It also distinguishes itself from the sibling get_proposal, so an agent can tell the two apart without opening either 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 concrete triggering questions ("what is NEAR governance voting on", "did HSP-027 pass") and an explicit alternative for the other mode of use ("For one proposal in full use get_proposal"). The when-to-use and when-to-use-something-else conditions are both stated outright.

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 the ordering implied by "newest videos" and the truncated return content ("the start of its description"), which the input schema cannot convey. It stops short of stating pagination behavior for offset/limit or whether a total count is returned, which is the main remaining gap for a read-only listing 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?

Two sentences: the first front-loads scope and return contents, the second covers filtering and the alternative routing. No filler, no repetition of the tool name, and the disambiguation comes last where it is most useful.

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 listing tool with four optional parameters and no output schema, the description covers purpose, filterable dimensions, returned fields, and siblings well enough to call it correctly. The omission of limit/offset paging behavior is the only meaningful hole.

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 description maps to only two of the four parameters (channel and date via "Filter by channel or date"), while limit and offset remain undocumented in both description and schema. With 50% schema coverage, the description partially compensates but leaves paging semantics unexplained.

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 ("newest videos of the NEAR Protocol, NEAR DevHub and NEAR AI YouTube channels"), enumerates the content types (talks, interviews, livestreams, workshops), and describes what each item carries (date, start of description). This makes it immediately distinguishable from search and semantic_search.

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 names what the tool is for (browsing newest videos, filtered by channel or date) and routes subject-based queries to named alternatives: "use search with type youtube, or semantic_search." The selection condition between browsing and searching is stated, not 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?

With no annotations, the description carries the full burden and does well: it enumerates the returned facts — latest and latest stable version, yanked/deprecated status, count of newer stable versions, registry deprecation message, and the replacement target. The read-only nature is implicit in "look up," and no error behavior for unknown packages is described, which keeps it short of 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?

Two sentences: the payload is front-loaded on the verb and the usage rule is isolated at the end where it is easy to find. The first sentence is a long comma-separated list of return fields, which reads as a run-on but every clause carries distinct information.

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

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

For a single-parameter lookup with no output schema and no annotations, the description supplies the return shape, the registry scope, and the staleness use case — enough to call it correctly. What is missing is failure behavior (nonexistent package, ambiguous registry) and an explicit statement that the call is side-effect free.

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 property description already gives the accepted forms, so the baseline is 3. The description adds one meaningful semantic the schema does not spell out: when no version is supplied the tool resolves to latest, and the registry prefix (npm:/crates:) selects 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?

Opens with a specific verb+resource: "Look up one NEAR npm or crates.io package, optionally at a version." That is far more precise than the sibling names (check_deprecation, get_breaking_changes) and the registry scope is explicit. It stops short of naming which sibling to use instead, so an agent must infer the boundary with check_deprecation itself.

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?

Ends with a concrete trigger: "Use before adding or upgrading a dependency," which tells the agent the workflow moment this tool belongs to. No exclusions or alternatives are stated, so an agent comparing it against check_deprecation or find_known_issues gets no routing rule.

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 provided, the description carries the burden and does disclose the scope of the index, the NEAR-only boundary, and that results carry page ids that feed into get_doc. It stops short of describing ranking behavior, result shape, or how the corpus is partitioned across result types, which matters for a search 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 front-loaded sentences with no filler; scope, exclusions, and alternatives arrive in that order. The long parenthetical source list is dense but every entry is informative, so little is 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?

With no output schema, the description still signals that results are page-level with ids. The main remaining gap is that the 'type' and 'limit' parameters are never explained, but overall an agent has enough to call 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 only 33%: 'query' is described as merely 'Search query' and 'limit' is undocumented. The source enumeration in the description loosely maps onto the 'type' enum values (doc, discussion, blog, github, youtube), but the mapping is left implicit and 'limit' gets no mention at all, so the description only partially compensates.

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 verb ('Keyword/full-text search') and enumerates the exact corpus it covers: docs.near.org, partner docs, gov.near.org, release notes, blog and GitHub issues. It also names the sibling tools it is not (semantic_search, get_doc), so an agent can route 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?

Gives explicit when-to-use ('exact-term or name lookups'), explicit when-not ('NEAR only: not for other blockchains, the general web or local files'), and names two alternatives with the conditions that select them ('semantic_search for conceptual how-does-X-work questions', 'get_doc to read a full page once you have its id').

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 supplied, the description carries the full disclosure burden, and it does the important part: it defines corpus scope and hard limits on what will be searched. It also implies results carry ids (since get_doc consumes them), but never describes result shape, ranking behavior, or what happens when a query matches nothing. A minor gap, not a misleading one.

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

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

Three sentences, front-loaded with purpose, then boundary, then routing. The source enumeration is long but earns its space by telling the agent exactly what corpus it will hit. No filler or restatement of the name.

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 3-parameter read tool with no output schema, the description covers purpose, scope, and sibling routing thoroughly. The remaining omissions — result format and the meaning of limit — are modest, since there is no output schema to explain returns and the schema covers two of three parameters.

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 67% — query and source_types are documented in-schema, while limit (default 6, max 15) is undocumented anywhere. The description adds no parameter-level meaning at all: it never mentions source_types filtering or result count. Baseline 3 is appropriate since the schema does most of the work, but the description misses an easy chance to explain narrowing by source type.

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

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

States a specific verb and resource ('Semantic (meaning-based) search over the NEAR knowledge base') and enumerates the corpora covered (docs.near.org, gov.near.org, release notes, blog, ecosystem catalog, GitHub issues). It also draws a hard boundary ('NEAR only: not for other blockchains, the general web or local files'), which lets an agent separate it from the generic 'search' sibling without opening either schema.

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

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

Gives explicit when-to-use ('conceptual how-does-X-work questions') and names two alternatives with the condition selecting each: 'search' for exact-term or name lookups, and 'get_doc' to read a full page once an id is known. Exclusions for non-NEAR content are stated outright, so routing decisions require no inference.

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