Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

See what concepts are explained

onchain_agent_list_wiki_pages
Read-onlyIdempotent

USE WHEN you need the slug for a crypto-agent explainer before calling onchain_agent_get_wiki_page, or want to see which concepts have a sourced page you can cite. NOT FOR reading a page (use onchain_agent_get_wiki_page instead) or finding projects (use onchain_agent_search_resources).

RETURNS (json): { total, pages: [...] }, every Onchain Agent wiki page with slug, title, keyword, summary and last_updated. Read-only.

Example: {}

Input Schema

NameRequiredDescriptionDefault
response_formatNoText format; structuredContent is JSON either way.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: 'markdown' (human-readable, default) or 'json' (machine-readable)."New value: +"Text format; structuredContent is JSON either way."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered structurally. The description adds the enumeration of returned fields (slug, title, keyword, summary, last_updated) and confirms read-only, which is useful context beyond the annotations, though it doesn't discuss caching or pagination behavior.

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

Conciseness5/5

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

Three tight, front-loaded blocks (USE WHEN, NOT FOR, RETURNS) with no filler sentences. The routing information precedes the return-shape detail, which is the right ordering for selection.

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

Completeness5/5

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 listing the aggregate shape { total, pages: [...] } and per-page fields. Nothing needed to select or invoke this zero-required-parameter list tool is missing.

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

Parameters3/5

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

There is a single optional parameter whose schema description already covers the markdown/json enum at 100% coverage, so the schema does the heavy lifting. The description only contributes an empty Example: {} to signal no arguments are needed, which is a marginal addition. Baseline 3 is appropriate.

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

Purpose5/5

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

The description names a specific verb+resource (list every Onchain Agent wiki page) and states the concrete value: obtaining slugs/titles for sourced explainer pages. It explicitly differentiates itself from onchain_agent_get_wiki_page and onchain_agent_search_resources, so an agent can distinguish it from siblings without opening schemas.

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

Usage Guidelines5/5

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

Contains explicit USE WHEN and NOT FOR clauses with named alternatives (get_wiki_page for reading, search_resources for finding projects) plus the triggering condition of needing a slug first. Both when-to-use and when-not-to-use are spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.