CryptoDecentral Sovereign MCP

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: results are bounded to a top-5 TVL table plus a DEX-category volume table and an overview 24h figure, and it flags the educational/no-advice framing that should shape how the agent presents the output. It does not mention data freshness or refresh cadence.

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 the tool returns before the exclusions. The triple negation ('not prices, not a trade ranking, not a swap') and the restated 'Educational'/'Education only' are slightly redundant, costing a little tightness but reinforcing scope.

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 zero parameters and no output schema, the description carries the burden of describing return content, and it does so concretely (which tables, what the overview figure is). Only the data recency/source-currency question is left unanswered, which is a minor gap for a read-only snapshot 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate at the input layer. The description correctly spends its words on output scope instead.

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 (DefiLlama DEX pulse) and enumerates its contents: top 5 TVL table, DEX-category volume table, and an overview 24h volume figure. It also fences off adjacent concepts ('not prices, not a trade ranking, not a swap'). It stops short of naming a sibling to contrast with, but no sibling tool overlaps this data anyway.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for a high-level DEX activity snapshot, and the three 'not X' clauses rule out price lookup, ranking, and swap use cases. There is no explicit 'use this when...' sentence and no named alternative among the content/listing siblings, so the agent must infer the trigger condition.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description adds the useful fact that the content is canonical/static and legally framed, but says nothing about caching, size, or response shape beyond 'legal URLs'.

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

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

Two short sentences, front-loaded with what is returned and followed by the compliance caveat. No redundant restatement of the title and nothing that could be cut.

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

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

For a simple, parameterless static-content tool with no output schema, the description tells the agent what it gets back (disclaimer text plus legal URLs) and its legal posture, which is sufficient to call it correctly. Only minor detail about the response structure is absent.

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

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

The tool takes zero parameters, so the schema alone is complete and there is nothing for the description to disambiguate. Baseline for a no-parameter tool is applied, with no added or subtracted value from the description.

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

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

States a specific verb and resource ('Return CryptoDecentral's canonical educational fence and legal URLs'), so an agent knows this yields static compliance text rather than content from get_guide or get_site_posture. The term 'fence' is slightly jargon-like, but the second sentence clarifies the substance.

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 'Education only, not financial advice' line implies this is the disclosure tool to call when presenting educational output, but it never explicitly says when to call it or which siblings to pair it with. Usage is inferable rather than 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds genuine value by disclosing the returned fields and the content nature ('Education only, not financial advice'), but says nothing about failure behavior for unknown slugs or body length.

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

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

Two short sentences with zero waste; the lookup key and return shape come first and the content caveat follows. Nothing is padded or repeated.

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 steps in and names the six returned fields, which is the key gap it needed to fill for a single-record fetch. What remains thin is edge behavior (missing slug, truncated body) for a tool whose annotations already cover the safety profile.

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 slug parameter is documented with an example value plus its source tool, so the schema carries the burden. The description only restates that lookup is by slug, adding no format or validation detail beyond what is already structured.

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 guide by slug') and enumerates exactly what comes back (title, description, publishedAt, readingTime, url, plain-text body). The singular 'one guide' implicitly contrasts with the sibling list_guides, but that sibling is never named, so the differentiation is inferred rather than stated.

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

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

There is no explicit when-to-use or when-not-to-use guidance in the description itself; the usage condition is only implied, and the retrieval workflow is documented in the schema's slug property ('Guide slug from list_guides'), which points the agent at the right prerequisite. Adequate but relying on the schema rather than the description to route the agent.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description adds only the 'Education only, not financial advice' caveat about content nature, and says nothing about what a listing contains or how misses are handled. Useful but thin beyond 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?

Two short sentences, front-loaded with the core action. The trailing disclaimer is somewhat boilerplate but does convey domain context, so it earns a marginal place.

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

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

For a single-parameter read this is close to adequate, but with no output schema the description could say what a listing record contains (e.g. name, description, resources). The disclaimer carries more weight than the substantive content explanation.

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 id parameter already documents its origin and example format, so the description's 'by id' adds no information beyond the schema. Baseline 3 applies.

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

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

The description gives a specific verb and resource ('Get a single directory listing by id'), and the word 'single' plus 'by id' implicitly separates it from list_directory and search_directory. It stops short of naming those siblings explicitly, so an agent must infer the distinction.

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

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

Usage is only implied: 'by id' suggests this follows a list_directory or search_directory call. There is no explicit statement of when to choose this over the list/search alternatives, and no note that the id must come from an earlier lookup (though the schema hints at 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds essentially nothing beyond that: it restates the two variants already explained in the schema and appends a legal disclaimer, and it says nothing about payload size (llms-full.txt could be very large) or pagination.

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

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

Two short sentences with the core behavior front-loaded and no wasted phrasing. The trailing 'Education only, not financial advice' line is boilerplate but plausibly a required legal notice, so it is only a minor drag on conciseness.

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

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

For a simple zero-required-param read tool with no output schema, the description covers the essentials. However it omits any hint about expected output volume or format (especially for the 'full' variant), which is the main thing an agent needs to choose wisely.

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 enum parameter is fully documented in the schema, so the baseline is 3. The description's paraphrase ('short' / 'full') adds no format, size, or default information beyond what the schema already provides.

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 with both variants named (llms.txt map vs llms-full.txt), which distinguishes it from content-listing siblings like list_directory or get_guide. It does not explicitly say how it differs from those siblings, keeping it short of a 5.

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

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

No guidance on when to call this instead of get_guide, get_disclaimer, list_directory, or search_content. The only 'when' signal is the variant toggle, which is already documented in the schema, and the 'Education only' line is a legal disclaimer rather than usage direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered and the description correctly doesn't restate it. What the description adds is modest: it implies an external Tor/Nostr network read (consistent with openWorld), but it never says whether results are cached, how fresh the snapshot is, or what happens if an upstream source fails. A 3 reflects useful scope context rather than rich behavioral disclosure.

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

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

It is short and front-loaded, but a large share of the two sentences is disclaimer boilerplate ('Education only, not financial advice') that duplicates what a dedicated get_disclaimer sibling presumably exists for. The parenthetical metric list is efficient; the trailing legal line is not earning its place inside a tool description.

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

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

For a no-arg, read-only tool with annotations covering safety, the description is nearly sufficient because it lists what the payload contains. But with no output schema, the agent gets no sense of return shape — single object vs. list of samples, units for difficulty, what the 'Nostr sample' field actually holds. That is a real gap for a data-retrieval 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?

With zero parameters, there is nothing to disambiguate and the baseline is a 4. The description appropriately spends no words on inputs and instead characterizes the output payload, which is the only semantic work left for a no-arg tool lacking an output 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?

Names a specific resource (public network metrics snapshot) and enumerates the contents: mempool fees in sat/vB, difficulty, Tor, Nostr sample. That is concrete enough for an agent to know what data comes back. It loses a point because 'Educational' and the negative framing ('No asset prices') are doing marketing rather than describing scope, and it doesn't distinguish itself from siblings like get_dex_pulse beyond the negation.

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

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

There is no when-to-use guidance at all: no mention of when a snapshot is preferable to get_dex_pulse, and no note that it takes no parameters and returns a point-in-time sample. The 'No asset prices or trading signals' line is the closest thing to routing, but it only says what data is absent, not which alternative to call for 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile needs no restatement. The description adds value beyond them by disclosing what the response contains, notably that the body is plain text and that audio url and sources are included — meaningful since no output schema exists. It stops short of noting failure behavior (e.g., unknown slug) or size/length characteristics of the body.

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 core sentence is front-loaded with the verb and resource and packs the return-field list efficiently with no filler. The second sentence is a short compliance disclaimer that serves a domain purpose but is not about tool selection or invocation.

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 read tool with full annotation coverage and a fully documented schema, the definition is nearly sufficient; listing the returned fields compensates for the absent output schema. The remaining minor gap is that an agent is not told what happens when the slug does not exist or how to obtain a slug other than via the schema's mention of list_notes.

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 slug parameter is documented with a concrete example (xpub-is-not-a-public-key) plus provenance (from list_notes). The description only repeats "by slug" and adds no format, case-sensitivity, or validation detail. Baseline 3 applies when the schema carries the parameter documentation.

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?

"Get one note by slug" states a specific verb (get) and resource (note) with single-item scope, and enumerates the returned fields (title, description, publishedAt, tags, url, audio url, sources, body). It implicitly contrasts with list_notes/search_content through the word "one," but never names those siblings explicitly, so differentiation is inferred rather than stated.

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

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

Usage is only implied: an agent can infer this is the retrieval step after list_notes or search_content surfaces a slug. There is no explicit when-to-use, when-not-to-use, or named alternative such as list_notes for enumeration. The trailing "Education only, not financial advice" line is a content disclaimer, not invocation 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without prose. The description adds one piece of non-annotation context — the educational, non-advice nature of the content — which is genuinely useful for how the agent frames results, but says nothing about payload shape or error behavior for a missing slug.

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

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

Two short sentences with the retrieval scope front-loaded in the first clause and zero filler. Nothing is repeated from the annotations or schema, and no sentence could be removed 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 one-parameter, read-only lookup with full schema coverage, rich annotations, and no output schema, the definition covers the essentials. The only shortfall is that it never indicates what a pillar contains or how to handle an unknown slug, which would matter for a first-time caller.

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 id property already explains 'Pillar slug from list_pillars, e.g. privacy, deai, nostr.' The description's '(slug)' merely echoes that, adding no format, casing, or resolution detail beyond the structured field, 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: 'Get one pillar by id (slug)' tells the agent exactly what is returned — a single pillar record keyed by slug. The resource name 'pillar' is distinct from siblings like get_guide, get_note, and get_listing, though the description never explicitly contrasts itself with those or with list_pillars.

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

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

There is no when-to-use guidance: nothing says to call this after list_pillars or to prefer search_content when the slug is unknown. The one qualifier present, 'Education only, not financial advice,' is a content disclaimer rather than usage routing, so the agent must infer that list_pillars is the discovery entry point from the schema alone.

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

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

Annotations already declare this to be a safe, read-only, idempotent, non-destructive operation. The description adds useful context about the content's scope and limitations (no custody, swaps, or advice), but it does not describe the return shape or whether the posture is static or structured.

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

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

The description is a single compact, front-loaded sentence with no wasted preamble. It is slightly redundant because "no advice" and "not financial advice" express the same exclusion.

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

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

For a simple zero-parameter read tool, the content scope is stated adequately. However, the description does not specify output format and does not clarify how this posture statement differs from the sibling get_disclaimer, leaving an agent to guess.

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

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

The tool takes zero parameters, so the baseline is 4 and there are no parameter semantics for the description to clarify.

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

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

The description identifies a specific resource ("site posture") and lists what the content covers: what CryptoDecentral is and is not, including no custody, swaps, or advice. However, "posture" remains vague and the description does not distinguish this tool from the sibling get_disclaimer.

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

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

No guidance is given on when to call this tool versus alternatives such as get_disclaimer or get_guide. The statement "Education only, not financial advice" is a content disclaimer, not usage routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no behavior of its own beyond a schema-version tag and a compliance disclaimer; it says nothing about result ordering, pagination or volume limits for an unbounded list 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 short, front-loaded fragments with no filler; the resource is stated before the filters. The trailing "Education only, not financial advice" is a compliance note rather than tool guidance, but it is brief enough not to obscure the operative 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?

With zero required parameters, full schema coverage and rich annotations, the essentials are present. However, there is no output schema, so the description would ideally sketch what a listing record contains and whether the list is bounded or paginated — neither is addressed.

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 each parameter documented including matching semantics and the "omit for all" default. The description only repeats the three parameter names (q, category, tag) without adding matching or format detail, so the schema does the work and 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 ("List curated directory listings") and names the filterable fields, so the agent knows exactly what is returned. It does not, however, differentiate itself from the nearby search_directory sibling, which reads similarly at a glance.

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?

Mentioning the optional filters implies the two usage modes (omit everything to enumerate, supply filters to narrow), but nothing is said about when this should be chosen over search_directory or search_content. Usage is inferable rather than 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the returned field set and a content caveat ("Education only, not financial advice"), but says nothing about ordering, pagination, or result volume for a listing 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?

Two short sentences, front-loaded with the verb and resource before the field list. Nothing is padded, though the trailing disclaimer is editorial framing rather than 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?

With no parameters, no annotations gap, and no output schema, the description does the one thing it must: it names the fields returned, standing in for the missing output schema. A note on result size or on when to follow up with get_guide would make it complete.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning to compensate for. The description usefully spends its words instead on naming the fields each guide carries.

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?

"List educational guides" pairs a specific verb with a specific resource, and the parenthetical enumerates the returned fields. It reads clearly against singular siblings like get_guide and against list_notes/list_pillars, though it never explicitly says how it differs from get_guide.

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: an agent can infer this is the bulk-retrieval tool and that get_guide fetches a single item. There is no explicit when-to-use, no statement that it takes no filters, and no pointer to the sibling to use for full detail.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine value by naming the returned fields (slug, title, description, tags, url), which matters because there is no output schema. It says nothing about ordering, pagination, or result volume, leaving those behavioral traits 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?

Two short sentences, front-loaded with the operation and the payload shape, with no wasted phrasing. The trailing 'Education only, not financial advice' is compliance framing rather than tool mechanics; it is brief enough not to be harmful but only marginally earns its place.

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

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

For a zero-parameter, read-only listing tool with full annotation coverage, the definition supplies the one thing structured fields do not: the shape of each returned note, compensating for the absent output schema. It falls short of complete only in not indicating result size, ordering, or whether all notes are returned at once.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline for a parameterless tool 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 ('List educational notes') and even enumerates the item fields returned, so the agent knows exactly what it gets back. It does not, however, distinguish itself from nearby siblings such as get_note, list_guides, or list_pillars, which an agent must infer.

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

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

There is no when-to-use guidance, no mention of when to prefer this over get_note (single note) or list_guides/list_pillars, and no stated prerequisites. The only added sentence is a compliance disclaimer, not selection guidance, so the agent is left to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful nature-of-content context (educational, non-advice) and that entries include summaries, but says nothing about ordering, pagination, or total size of the pillar set.

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

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

Two short sentences, front-loaded with the action and resource, then the content caveat. Nothing is padded and no sentence is redundant.

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 parameterless read-only listing with full annotation coverage, the definition is nearly sufficient: it names the resource, gives examples, and signals the per-item payload (summaries). The only gap is how this list relates to get_pillar and whether the listing is exhaustive.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to explain. The description correctly implies an unfiltered full listing with summaries.

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 ("List educational pillars") and enumerates concrete examples (privacy, wallets, deai, nostr), so an agent knows exactly what comes back. It only implicitly distinguishes itself from the sibling get_pillar via "with summaries" versus detail, rather than naming the sibling and the selection rule.

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?

"Education only, not financial advice" is a content disclaimer, not usage guidance—it does not tell the agent when to call this versus get_pillar, list_guides, or search_content. No prerequisites or exclusions are given; the agent must infer that this is the broad catalog and get_pillar is the drill-down.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that matching is limited to titles and summaries, not body text — plus a content-domain caveat (education only). It says nothing about result caps, ordering, or pagination, which matter 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?

Two compact sentences with the core purpose front-loaded and no filler. The telegrammatic phrasing ('type optional: notes|guides|pillars|all') duplicates the enum already in the schema, which is the only wasted element.

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

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

For a simple two-parameter, non-destructive read tool with rich annotations and no output schema, the essentials are present. Missing is anything about result volume, ranking, or what a returned item looks like, which an agent would need to decide whether to paginate or follow up with get_note.

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%, with both parameters fully documented including the enum and default, so the schema carries the load. The description restates the type enum and adds only marginal nuance by clarifying the match fields for q; this is the baseline case where the schema does the heavy lifting.

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 (search) plus the exact resource set (notes, guides, pillars) and the match targets (title/summary). This clearly separates it from get_note/get_guide/get_pillar, which fetch single items, but it never mentions the closer sibling search_directory, so sibling differentiation is incomplete.

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: matching against titles/summaries suggests this is the discovery step before calling get_note or get_guide, but that handoff is never stated. There are no when-not-to-use conditions and no guidance on choosing between this and search_directory or the list_* siblings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description adds two real behavioral facts beyond them: matches are "unranked" (no relevance ordering, so result order should not be trusted) and the corpus is educational only rather than financial advice. It still says nothing about result volume, pagination, or truncation, which limits how completely an agent can plan a 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?

Two short clauses, front-loaded with the action and the filter dimensions, with no filler. The "Education only, not financial advice" caveat earns its place as scope framing, though it is closer to boilerplate than operational guidance.

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-optional-parameter read tool with no output schema, the description covers what is searched and roughly what comes back, but leaves out result ordering, expected result size, and how multiple filters compose. Those gaps matter for an agent deciding between this tool and list_directory.

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 already explains matching targets, case-insensitivity, exact-tag/category behavior, and omission semantics. The description merely echoes the parameter names without adding syntax or interaction details (e.g., whether q combines with tag/category as AND), 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?

"Search directory listings by query/category/tag" gives a specific verb (search) plus resource (directory listings) and names the filter dimensions, so an agent knows exactly what this retrieves. It does not distinguish itself from siblings like list_directory or search_content, which is the only thing missing.

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 presence of q/tag/category filters suggests this is the tool to reach for when narrowing the directory. There is no explicit statement of when to prefer it over list_directory (unfiltered browse) or search_content (non-directory content), and no exclusions or prerequisites.

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