Radix Wiki

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

Annotations only declare the generic non-read-only, non-destructive, non-idempotent profile; the description adds real context the annotations cannot: authentication mechanism, wallet-holding requirements per tag category, the fact the balance check spends nothing, and the contribution-points side effect. It omits failure behavior for duplicate slugs/titles, which matters for a non-idempotent create.

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

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

Four dense sentences, front-loaded with the action and followed by prerequisites in rough order of execution. Parenthetical category thresholds are a little crammed, but no sentence 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?

For a create tool with a deep nested content schema and no output schema, the description covers auth, sequencing, eligibility and content style. It does not say what the call returns (page id/path) or how conflicts are surfaced, which an agent needs to chain into get_page or edit_page.

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 nested block schema is heavily self-documented, so the baseline is 3. The description still adds value beyond the schema by imposing content conventions (start with an infobox, hyperlink every assertion, no inline styles) and by pointing tagPath at get_categories for valid values.

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 ("Create a new Radix Wiki page") that is unmistakably distinct from the siblings edit_page, delete_page and get_page. It also names the immediate prerequisite tool (get_categories), so an agent can place it in the workflow without opening the schema.

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

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

Gives concrete preconditions: a ROLA bearer token with a linked challenge-sign-verify flow, a call to get_categories first for a valid tagPath, and a per-category wallet balance threshold. It never explicitly says when NOT to use it (e.g. use edit_page to modify an existing page), so it falls short of full when/when-not/alternatives coverage.

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

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

Annotations already mark this destructive and idempotent, but the description adds substantial context beyond them: the authentication requirement, the permission/ownership model, the cascade to history and comments, and the set of pages that cannot be deleted. This is exactly the behavioral detail an agent needs before invoking a destructive operation.

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 dense sentences, each doing distinct work: what is deleted (with cascade), what credentials/permissions are needed, and what cannot be deleted. Front-loaded with the action and its effect; 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 destructive one-parameter tool with no output schema and annotations that only give the safety profile, the description supplies everything an agent needs: auth requirement, permission rules, cascade behavior, and prohibited targets. Nothing material is missing.

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

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

There is a single parameter with 100% schema description coverage ('The page's whole path'), so the schema carries the semantics. The description adds no further detail about the path format or identifiers, making the baseline 3 appropriate.

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

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

The description states a specific verb (delete) and resource (an article/page), and adds scope that the name alone doesn't convey: the page's history and comments go with it. This clearly distinguishes it from edit_page and restore_revision.

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 spells out the conditions for use: a ROLA bearer token is required, the author may delete, and on a shared ideas board anyone meeting the edit bar may delete. It also gives explicit exclusions (locked pages, hub articles, homepage). It stops short of naming an alternative tool for cases where deletion isn't allowed.

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

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

Beyond the annotations, it discloses authentication requirements, wallet balance prerequisites, optimistic concurrency behavior, server-side computation of version/diff/revision, page restrictions, and contribution points. These details materially improve safe invocation. The destructiveHint annotation is consistent with replacing the full block array.

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 dense but front-loaded paragraph: purpose first, then prerequisites, workflow, conflict behavior, restrictions, and side effects. For an 11-parameter mutation tool, every sentence contributes relevant context without 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?

It covers the full complexity of the tool: auth, wallet requirements, read-before-edit workflow, concurrency refusal, server-side effects, rejected page states, and contribution-point side effects. No output schema is present, but the description does not need to explain return values and otherwise leaves no major operational gap.

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

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

Schema coverage is 100%, so the schema already carries most parameter meaning. The description adds useful workflow semantics around `baseVersion` conflict handling and full-array replacement, though several parameter explanations overlap with existing schema descriptions.

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: editing an existing Radix Wiki page. It clearly distinguishes this from reading via get_page and implies the lifecycle distinction from create_page/delete_page, so an agent can identify the tool without opening the schema.

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

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

It gives explicit operational guidance: read the page first with get_page and `blocks: true`, send the full revised block array, and pass `version` as `baseVersion`. It also states when the edit is refused, what to do on conflict, and that locked or author-only pages are rejected.

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 establish read-only, idempotent, closed-world behavior. The description adds valuable return-shape context: each node carries path/name/description/pageCount/pageCountDeep, and tagPaths enumerates every tag path including those absent from the tree. Pagination and auth behavior remain unstated, but the annotation coverage lowers the burden.

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 dense but well-structured sentences front-load purpose and value, then describe the returned node fields and the tagPaths list. Every sentence contributes necessary 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?

No output schema exists, so the description must explain return structure, and it does so through node fields and tagPaths. Combined with annotations that cover safety and the absence of parameters, this is complete enough for an orientation 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 are zero parameters, so the baseline is 4. The description still adds cross-tool semantics by explaining that a node's path is the same tagPath accepted by list_pages and search_wiki, which helps an agent connect this output to sibling tools.

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 resource (category tree of the Radix Wiki) and its role ('orient before searching'), so an agent can tell this lists categories rather than pages. It references list_pages and search_wiki indirectly, but does not explicitly say what it is not, so it is clear but not perfectly differentiated.

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?

States the moment to use it ('before searching') and frames it as the cheapest orientation step, implicitly contrasting with search_wiki. It does not spell out when not to use it or name all alternatives, so it falls short of full when/when-not 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 annotations providing no safety hints and all flags false, the description carries the full burden and does so richly: it discloses single-use behavior, a 5-minute expiry, that the response specifies the exact signing recipe, and that the tool never custodies keys. This goes well beyond what annotations alone convey and does not contradict them.

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 with no wasted words. The core purpose is front-loaded, and each sentence adds a distinct piece of information: the role in the flow, the expiry and response contents, and the key ownership guarantee.

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 tool with no output schema, the description is complete: it explains what the response contains, why the challenge is needed, the expiry constraint, and the security context around key custody. An agent knows exactly what to expect and how to proceed after invocation.

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

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

The schema has zero parameters and 100% coverage, so the baseline is 4. The description explicitly states 'Takes no parameters,' confirming there is no required input, which is fully consistent with the empty schema.

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

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

The description clearly states a specific verb and resource: obtaining a single-use ROLA challenge as 'Step 1 of writing to the wiki.' It distinguishes itself from siblings by explaining exactly what the response contains (the recipe for signing with an Ed25519 key) and what it does not do ('nothing here custodies anything').

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 clearly frames this as the first step in an authentication flow for writing to the wiki, which implies when to use it. It does not explicitly name alternatives or exclusions, but the 'Step 1' framing and mention of your own key give enough contextual guidance.

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

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

Annotations cover only safety (readOnly/idempotent/closed-world), and the description adds the behavior that actually matters for a large dump: page-aligned truncation, truncated/omittedPages/nextSkip resume protocol, skip=nextSkip continuation, and the default/max character budget. That is substantial disclosure beyond structured fields.

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 paragraph that is front-loaded with the resource, then the preflight, then paging/resume, then the alternative. Every clause carries operational information; 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?

With no output schema, the description carries the return-value burden itself, naming truncated, omittedPages, nextSkip and the sizeOnly report fields. For a 4-param, zero-required bulk-read tool, an agent has everything needed for a correct first call and a correct continuation.

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 still adds meaning the schema does not carry, notably what sizeOnly=true actually returns (character count, token estimate, per-branch breakdown, largest pages) and the preflight-then-pull sequencing. It does not add format/syntax detail for skip or tagPath beyond the schema, so it stops short of a 5.

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

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

Specific verb+resource: returns the whole Radix Wiki as one text document for bulk ingestion, which is unambiguous against a sibling list dominated by single-page/browsing tools. It also explicitly contrasts itself with get_pages for small fetches, so an agent can route 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?

Gives an explicit workflow: preflight with sizeOnly=true, then pull with maxChars, or narrow to one branch with tagPath, and use get_pages instead for a handful of pages. When-to-use, when-not, and the alternative are all 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?

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description goes further by disclosing the return structure (status columns and per-card fields), which is behaviorally useful and not present in the structured data.

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 densely informative sentences, front-loaded with the resource identity before the purpose. Every clause earns its place by describing columns, fields, or intent.

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 compensates by describing the returned kanban shape. Annotations cover safety, parameters are fully documented in the schema, and no behavioral gap remains for correctly invoking this read-only board.

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 two filters are already documented. The description adds marginal value by naming working group and category as card attributes, implicitly confirming what the filters operate on, but does not explain filter syntax.

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 (Get) plus a precisely named resource (RADIX Wiki Ideas Pipeline kanban) and scope. It enumerates the status columns and card attributes, so an agent knows exactly what this returns and how it differs from the page-oriented siblings.

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

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

"Use this to follow DAO / project progress" gives clear usage context, and no sibling offers an equivalent kanban view. However, it does not state when-not to use it or name an alternative for narrower page lookups.

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/closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: data provenance (summed from the Gateway transaction stream) and a meaningful coverage limitation ('counts cover user transactions only'), which an agent must know to interpret the numbers correctly.

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

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

Front-loaded with the resource and scope, then the measures, then the narrowing guidance. Dense and largely waste-free, though the trailing sentence about /charts and the CSV download is more contextual pointer than invocation-critical and slightly dilutes the focus.

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

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

With no output schema, the description carries the burden of describing the returned data and does so fully: granularity, coverage window, provenance, and the enumerated columns. Nothing an agent needs to call or interpret this tool 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%, with both `from` and `to` documented in the schema including format (YYYY-MM-DD) and default behavior. The description only restates the filtering action ('Narrow with from/to') and adds no syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource (daily Radix mainnet activity) and then enumerates the exact measures returned (transactions, active/new accounts, components, resources, NFTs, fees, XRD burned, royalties). It also pins the scope precisely: one row per UTC day since Babylon (28 September 2023). An agent knows exactly what this returns without opening the schema.

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

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

Gives clear operative guidance ('Narrow with from/to') and points to sibling artifacts (/charts, /api/charts/activity?format=csv) for the same data. It does not state any when-not condition or name a competing tool, but the surrounding siblings (wiki page tools) make the domain unambiguous.

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

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

Annotations already declare readOnly/idempotent/openWorld=false, but the description adds non-obvious behavior: a miss names the nearest pages (self-correcting in one retry), blocks:true returns the stored block array with ids alongside page id and full metadata, and the returned version is the baseVersion an edit expects. Those editorial/workflow details are not in the annotations.

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

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

Dense but front-loaded: the core purpose leads, then addressing, then sibling routing, then edge behaviors. Nearly every clause carries information, though the middle section (miss behavior, .md markdown, blocks workflow) is tightly packed and could be split slightly for scanning.

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

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

No output schema exists, so the description carries the burden of describing returns (text, version, update date, metadata; block array under blocks:true) and does so. For a read tool with a clear safety profile, nothing an agent needs to call it correctly or use the result (e.g., baseVersion) is missing.

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

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

Schema coverage is 100%, so baseline is 3, and the description goes beyond it: it establishes precedence ('path' preferred, tagPath/slug ignored when set), states the concrete path format ('tag/path/slug'), and explains what blocks:true actually yields and why (pre-edit read). This adds meaning the schema strings alone don't 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+resource (read one page in full: text, version, update date, metadata) and distinguishes itself from siblings by naming get_pages and the collection-vs-single boundary. The addressing modes (path, or tagPath+slug) are spelled out, so an agent can tell it apart from list_pages/search_wiki 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?

Explicit routing rule: 'For 2 to 20 pages call get_pages, one round trip rather than N.' It also warns 'Not a title' and clarifies that a category's own path reads its hub article, plus the edit workflow (read with blocks:true before editing). When-to-use and when-to-use-the-alternative are both covered.

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-openWorld, so the safety profile is covered. The description adds meaningful behavior the annotations do not: newest-first ordering, the exact fields per revision, the limit default/max, and the cross-tool contract that an id feeds a restore.

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 dense sentences with no filler: purpose and ordering first, return shape second, addressing and cross-tool id semantics third, defaults last. Every sentence carries information an agent needs.

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

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

With no output schema, the description compensates by describing return fields and ordering. Combined with 100% schema coverage and read-only annotations, nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so path/slug/tagPath precedence and the limit default/max are already documented in the schema. The description repeats the limit defaults and the addressing convention rather than adding new syntax or format detail, 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?

States a specific verb+resource (a page's revisions in Radix Wiki) plus ordering (newest first) and enumerates the returned fields (id, version, change type, message, date, changed blocks). It also distinguishes itself from get_page by deferring addressing rules to it and from restore_revision by noting the revision id is what a restore takes.

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 context: address the page as get_page does, and the revision id is consumed by restore. It does not explicitly say when to prefer this over get_recent_changes or get_page, so the exclusion side of the guidance 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?

Annotations only cover the safety profile (readOnly, idempotent, not openWorld). The description goes well past that by disclosing partial-failure semantics: nonexistent paths land in `missing` instead of failing, overflow beyond 20 lands in `remaining`, and truncated pages land in `omitted` with sizes. That is exactly the behavior an agent needs to reason about a 3-way partial result.

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 scope, and the trailing clauses about `missing`/`remaining`/`omitted` all carry distinct information. It is dense and slightly run-on, 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?

With no output schema, the description carries the return-shape burden and does so by naming the three outcome buckets (missing, remaining, omitted) and the default char budget. Given only two well-documented parameters and read-only annotations, nothing material is left unexplained.

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 meaning beyond the schema by explaining the consequence of `maxChars` (pages past the cap are surfaced in `omitted` with their sizes) and reinforcing the 1-20 bound on `paths`. It does not restate the min/max numeric bounds, but the semantic effect is documented.

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 (batch read pages of the Radix Wiki) with an explicit scope bound (1 to 20, in full, one call). It also differentiates itself from sibling read paths by naming it as how to read search or listing results.

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

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

It clearly positions itself relative to search_wiki and list_pages output ('which is how to read search or listing results'), telling the agent when to reach for it. It stops short of explicitly naming get_page as the single-page alternative, so the single-vs-batch choice is only implied.

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 readOnly/idempotent/closed-world, so the bar is lower, and the description still adds real behavioral context: ordering (newest first), default values, and the meaning of `truncated: true`. This is the kind of return-signal an agent needs beyond the safety profile.

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 compact paragraph, front-loaded with the core purpose followed by usage framing, defaults, and the truncation caveat. Every sentence carries checkable information with no 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 compensates by disclosing ordering, default/limit bounds, and the `truncated` return signal, plus how to continue (raise limit or page through list_pages). Nothing essential for correct invocation 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 both parameters already document their defaults and maxima. The description largely restates those bounds (days 7/max 30, limit 20/max 50) without adding new semantics, so baseline 3 is appropriate.

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

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

States a specific verb+resource with scope ('Pages of the Radix Wiki edited within the last N days, newest first') and explicitly distinguishes itself from siblings, noting it returns the 'Same rows as list_pages' and serves a polling rather than reading use case. An agent can tell it apart from list_pages and get_page_history 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 clear context for use ('what to poll when you are watching the wiki rather than reading it') and routes to list_pages as the alternative for paging. It stops short of an explicit when-not condition, but the usage framing is concrete and actionable.

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 establish read-only, idempotent, and closed-world behavior, so the bar is lower. The description still adds real context: default ordering (newest first), pagination defaults and the 100 cap, and the result envelope keys (totalPages, hasMore, nextPage) that no output schema documents.

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

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

Four dense sentences, front-loaded with the primary distinguishing mechanism before any parameter detail. No filler, no restating the title or tool name, and every clause carries operational 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 zero-required-parameter listing tool with no output schema, the description covers scope, alternatives, ordering, pagination limits, and the return envelope. An agent has everything needed to call it correctly, and safety is already handled by annotations.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning on top: tagPath matches the branch plus everything beneath it and can be omitted entirely, and sort=title is framed as an A-Z pass over the same data, clarifying the enum's practical effect.

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 ('Browse the Radix Wiki') and pins the mechanism precisely: 'by tag path rather than by keyword', with scope ('every page under a branch'). This distinguishes it cleanly from search_wiki and get_pages 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 the alternative implicitly via 'rather than by keyword' (search_wiki) and gives selection conditions: use tagPath to scope to a branch and descendants, omit it to walk the whole wiki, use sort=title for an A-Z pass. No explicit when-not or hard exclusions, so it falls just 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?

Beyond the annotations, the description adds valuable behavioral context: the token lifetime is 7 days, the proof verification mirrors the human wallet flow, and the token is carried via HTTP header rather than tool arguments. It does not contradict the annotations and provides useful operational detail for an auth tool.

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

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

The description is compact and front-loaded: the first sentence states the action and token duration, and the second explains exactly how to use the result. Every clause earns its place with no repetition or 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 5-required-parameter tool with no output schema, the description adequately covers the auth workflow, token lifetime, and token usage. The only noticeable gap is that it does not describe the exact response shape beyond 'returned token', which could require the agent to infer the token field name.

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 all five parameters thoroughly. The description adds little parameter-specific meaning; 'signed ROLA proof' loosely contextualizes signature/publicKey, but it does not compensate beyond the schema baseline.

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 specific action: exchanging a signed ROLA proof for a 7-day Bearer token. It identifies the tool as 'Step 2' in an authentication flow, distinguishing it from get_challenge (step 1) and from content-oriented siblings like create_page and edit_page.

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 gives clear context by labeling the tool 'Step 2' and by explaining that the returned token must be sent as an Authorization header on later create_page/edit_page calls. It does not explicitly name get_challenge as the required predecessor or state exclusions, so it stops short of full when-to-use/when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the authentication requirement (ROLA bearer token), the permission gates inherited from edit_page, and the important behavioral detail that the restore is recorded as a new revision rather than overwriting history. It could say more about reversibility or failure modes, but this is solid added value.

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 the core action, followed by prerequisites and the pointer to the id source. Every sentence carries information; 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?

With annotations covering the safety profile and full schema coverage on both parameters, the description supplies the remaining essentials: auth, gates, and where to obtain the revision id. There is no output schema and no mention of what the call returns, but for a simple restore operation that omission is minor.

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 both parameters are documented in the schema, including that revisionId comes from get_page_history. The description repeats that provenance but adds no format, syntax, or constraint details beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Make an earlier revision the current page, written as a new revision') and immediately clarifies the mechanism (a new revision is written, not an in-place mutation). Combined with the cross-reference to edit_page and get_page_history, an agent can distinguish this from sibling tools 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?

It gives clear context and prerequisites: a ROLA bearer token is required, the same gates as edit_page apply, and the revision id must be sourced from get_page_history. It does not explicitly state when NOT to use it (e.g., versus edit_page for small corrections), which keeps it just short of a 5.

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

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

Annotations already declare read-only/idempotent safety, but the description adds substantial behavior: a four-tier ranking order, non-semantic matching (one distinctive word beats a sentence), stemming/stopword handling, snippet windowing on the match, and pagination semantics (default 20, max 50, page while hasMore). This is context an agent cannot derive from the annotations.

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

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

Front-loaded with the purpose and routing rule before ranking mechanics and pagination detail. It is dense and multi-clause, but nearly every sentence carries actionable information; only the ranking-tier enumeration is longer than strictly needed.

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

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

No output schema exists, yet the description discloses the row shape (path, chars, match-windowed snippet) and the hasMore flag, so an agent knows both how to call it and what comes back. Complete for a search 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%, so the baseline is 3, but the description adds genuine meaning: tagPath is framed as the narrowing lever for common terms (and sourced from get_categories), and page/pageSize defaults and the 50 cap are restated as operative constraints alongside the hasMore paging loop.

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 ('keyword search across the Radix Wiki') and immediately scopes it ('the first call when you know what you are looking for but not where it lives'). This distinguishes it cleanly from list_pages, get_page and get_pages 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?

Explicit routing guidance: use this first when you lack a location, feed resulting paths to get_pages in one call rather than looping get_page, and narrow with tagPath when a term is common. It names both the trigger condition and the sibling tools to prefer 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?

The description adds substantial behavioral detail beyond the annotations: it discloses the required ROLA token, size limits (3.4 MB pre-encoding, 4.5 MB request), accepted formats (JPEG, PNG, GIF, WebP, AVIF), that format is detected from bytes rather than contentType or filename, and that the stored image is converted to WebP at most 1600px wide with metadata stripped. The annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) are consistent with a non-destructive write operation, and the description enriches this without contradiction.

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 dense but well-organized, front-loading the tool's purpose and output usage before moving to prerequisites, size limits, accepted formats, and storage behavior. Every sentence contributes essential context without redundancy.

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

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

With no output schema, the description compensates by explaining what is returned ('the URL the editor stores') and how to use it. It also covers auth, size constraints, format handling, and post-upload transformation, leaving no major gap for an agent to invoke 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 100%, so the baseline is 3, but the description adds critical semantics: data must be base64-encoded with a 3.4 MB pre-encoding ceiling, and the format is read from the bytes rather than from contentType or filename. This clarifies that contentType and filename do not control format detection, which is meaningful for correct invocation.

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: 'Upload an image and get back the URL the editor stores.' It distinguishes the tool by explaining how the returned URL is consumed (content block, create_page, edit_page), leaving no ambiguity about its role relative to sibling page-manipulation tools.

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

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

It tells the agent exactly where to use the output—'put it in a content block as `<img src="…" alt="…">`, or pass it to create_page or edit_page as bannerImage'—which clarifies the tool's place in the workflow. It also names the required auth method ('Requires a ROLA bearer token, as create_page does'), though it stops short of stating when not to use this tool.

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