Verified Aperture Wallet product, security, network, release, and Journal knowledge.
Scored across 12 tools
Each tool targets a distinct resource or action: product facts, security model, features, articles, networks, app screens, entry points, release, search, and source fetch. The search/fetch relationship is explicitly defined, and get_* vs list_* pairs are clearly separated.
The dominant patterns get_<singular> and list_<plural> are applied consistently across detail and collection tools. The one-word exceptions 'search' and 'fetch' are understandable and conventional, but they break the strict verb_noun pattern.
12 tools is well within the ideal range for a specialized knowledge server. Each tool covers a meaningful aspect of the domain without redundancy or unnecessary bloat.
The tool set covers all apparent knowledge areas: product identity, security model, features, journal articles, supported networks, app screens, entry points, and release information. As a read-only knowledge server, search and fetch plus per-domain get/list tools provide full coverage with no obvious dead ends.
Fetch one canonical public source returned by search. The response includes citation-ready title, URL, text, and metadata. It never returns user wallet data or wallet credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A source ID returned by search, such as product or article:article-slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds concrete behavioral details: the response includes citation-ready title, URL, text, and metadata, and it never returns wallet data or credentials. This goes beyond the annotations without contradicting 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?
The description is two economical sentences with no filler. It front-loads the core action and scope, then adds return-value context and a privacy guarantee. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only, idempotent tool with no output schema, the description is complete enough. It explains where IDs come from, what the response contains, and what the tool will never return. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that id is a source ID returned by search with format examples like 'product or article:article-slug'. The description adds no further parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fetch one canonical public source returned by search.' It clearly distinguishes itself from sibling getters like get_article and get_product by emphasizing it is the generic fetch for search results, not a typed accessor.
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 usage context: use it for source IDs returned by search. It also explicitly warns that it never returns user wallet data or credentials, which is useful for routing agents away from misuse. However, it doesn't name sibling alternatives or state when one should prefer get_article or get_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a non-secret semantic description of an important Aperture screen, its purpose, entry points, sensitivity, and safe agent actions. This does not inspect a user device or wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| screen_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those annotations by stating the result is 'non-secret' and that the tool 'does not inspect a user device or wallet,' which clarifies privacy and safety expectations for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with no filler. The primary return value and scope are front-loaded, and the safety clarification is placed at the end without adding unnecessary length.
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-only tool with no output schema, the description covers what is returned and what the tool does not do. It is slightly incomplete only in that it does not tell the agent how to obtain or format a valid screen_id, which is the sole input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented screen_id parameter. It does not describe how screen_id should be sourced, what it represents beyond 'screen,' or how it relates to sibling tools such as list_app_entry_points. The regex pattern in the schema provides format but not semantic meaning.
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 uses the specific verb 'Return' and identifies the resource as 'a non-secret semantic description of an important Aperture screen.' It also enumerates the content of the result (purpose, entry points, sensitivity, safe agent actions), which makes the tool's function unambiguous and distinct from sibling get_* and list_* 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?
The intended use is implied by the description: call this when you need a semantic screen description rather than raw data. However, it does not explicitly state when to prefer this over siblings like list_app_entry_points or get_feature, and it names no alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete citation-ready Markdown representation of one published Aperture Journal article by slug and optional language tag, including canonical URL, dates, topics, body text, and public images.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| locale | No | Published article language, such as en, es, ar, or zh-Hans. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral detail beyond those annotations: the returned content is Markdown, citation-ready, and includes canonical URL, dates, topics, body text, and only public images. It does not mention error behavior, but this is not a critical omission given 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?
A single, dense sentence that leads with the core action and output format, then enumerates the included content without elaboration. Every phrase earns its place and there is no redundant 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?
The tool has only two parameters and no output schema, so the description needs to convey the shape of the return value. It does so with a solid enumeration (canonical URL, dates, topics, body text, public images). It could note behavior for invalid/unpublished slugs, but the description is sufficient for a competent agent to select and 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 description coverage is 50%, with slug having no description. The description compensates partially by explaining that slug identifies the article and locale is the optional language tag. It also reveals that the output is language-dependent ('optional language tag'), adding meaning beyond the raw schema. The pattern/default details are already in the schema, so no need to repeat them.
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 ('Return') and resource ('one published Aperture Journal article') with the key identifier (slug) and optional locale. The phrase 'citation-ready Markdown representation' adds a clear, distinct deliverable that separates it from list_articles and other get_* 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?
The context is clear: use this to retrieve a single article by slug, optionally in a specific language. It does not explicitly mention when to prefer list_articles or fetch, but the singular-article-by-slug framing strongly implies the intended use case, with no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one documented Aperture Wallet feature by its stable feature ID, including summary, availability, primary source, and safety notes.
| Name | Required | Description | Default |
|---|---|---|---|
| feature_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by specifying what the tool returns (summary, availability, primary source, safety notes) and that it targets only documented features. It does not mention not-found/error behavior, but for a simple read-only getter this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler, front-loaded with the verb and object. Every element contributes meaning: the resource, the ID type, and the returned content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only, idempotent tool, the description is largely complete: it names the input and the output content. The only notable omission is behavior when the feature ID does not exist, but this is not critical for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that feature_id is a 'stable feature ID' tied to documented features, which gives some meaning beyond the schema pattern, but it does not explain how to find valid IDs or relate it to list_features.
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 ('Return'), a resource ('one documented Aperture Wallet feature'), and a scope ('by its stable feature ID'), and lists the returned content fields. This clearly distinguishes it from siblings like list_features or get_article.
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 implies the tool is for fetching a single feature when its stable ID is known, and the inclusion of 'one documented feature' contrasts with list_features. However, it does not explicitly name an alternative or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the latest public App Store release snapshot and the primary Apple source used to verify it. Use the source when exact current version information matters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds useful behavior beyond that: the result includes both a release snapshot and the verification source, and the source is the more authoritative component for exact version details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences fully convey the tool's purpose and the key usage nuance. There is no fluff or repetition of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with rich annotations, the description covers what is returned and when the source should be used. No output schema exists, but the description adequately explains the return contents.
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 and schema coverage is 100%, so there are no parameter semantics to clarify. The baseline of 4 applies for a parameterless tool.
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 uses a specific verb ('Return') and names the exact resource: the latest public App Store release snapshot plus the primary Apple source used to verify it. This clearly distinguishes the tool from the content-focused siblings like get_article and get_feature.
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 provides a clear conditional use case: use the returned source when exact current version information matters. While it does not explicitly compare against alternative tools, there are no obvious release-related siblings, so the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical identity, platform, App Store, custody-model, recommendation-fit, official-link, and product-boundary facts for Aperture Wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about 'canonical' and 'product-boundary' facts but does not disclose additional behavioral traits such as response details, caching, or rate limits. No contradiction with 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?
The description is a single, well-structured sentence that immediately states the action and resource. The enumerated fact categories are valuable and compact, with no filler or redundant wording.
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, a read-only and idempotent annotation set, and an explicit list of returned fact categories, the description is complete for an agent to understand what this tool does and invoke it correctly. No output schema exists, but the description enumerates the return scope sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameter meaning, and the empty input schema confirms no arguments are required.
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 uses a specific verb ('Return') and clearly identifies the resource ('canonical ... facts for Aperture Wallet') along with the exact categories of facts included. This distinguishes it from sibling tools like get_feature, get_security_model, and get_latest_release.
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 about what kind of facts the tool returns, and 'canonical' implies it is the authoritative source for product-level facts. However, it does not explicitly state when to choose this tool over siblings like get_security_model, get_latest_release, or search, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Aperture Wallet self-custody storage, network, recovery, access-control, responsible-disclosure, and agent-safety boundaries. Never use this tool to request or process wallet credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds meaningful beyond annotations: it clarifies the exact categories of boundaries returned and attaches a credential-safety guardrail that prevents misuse of an agent-facing security tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the entire tool contract: the first defines scope and output topics, the second adds a critical safety restriction. There is no filler or repetition of the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description is complete enough: it names the information domain, lists constituent boundary categories, and includes the only practical misuse warning. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4 and the description does not need to add parameter-level context. The no-parameter contract is fully represented by an empty schema with additionalProperties false.
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 ('Return') and a precise resource ('Aperture Wallet self-custody storage, network, recovery, access-control, responsible-disclosure, and agent-safety boundaries'), enumerating the topics it covers. This clearly distinguishes it from content-focused siblings like get_article, get_feature, and list_articles.
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 implies when to use the tool: whenever Aperture security boundaries are needed, and it gives an explicit exclusion by warning never to request or process wallet credentials. It does not name alternative tools or contrast them, but no sibling appears to cover security boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical navigation-only app entry points, their App Intent names, source and public-release status, web fallbacks, and safety effects. These links only open visible UI and never inspect a wallet, bypass app lock, sign, broadcast, import, export, or delete anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description explicitly spells out what the tool does not do: inspect a wallet, bypass app lock, sign, broadcast, import, export, or delete anything. It also adds that links only open visible UI, which is valuable behavioral context not present in 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?
The description is two sentences with no filler. It front-loads the core purpose and then adds a concise safety clarification. Every sentence 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?
Given there are no parameters, no output schema, and strong annotations, the description is fully sufficient. It tells the agent what will be returned, what the tool is safe to do, and what it will never do, leaving no important gap for invocation or selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty input schema is fully complete. The description does not need to explain parameter semantics, and the baseline for a zero-parameter tool is appropriately strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb, 'Return', and a specific resource, 'canonical navigation-only app entry points', and lists the exact fields returned. This clearly separates it from the sibling tools, especially get_app_screen, by emphasizing 'navigation-only' and 'entry points'.
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 provides clear context for when to use this tool: when the agent needs canonical, navigation-only app entry points with metadata and safety guarantees. It does not explicitly name alternatives or state exclusions, but the purpose is clear enough to avoid obvious misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published Aperture Journal articles with canonical HTML and Markdown URLs. Optionally filter by category and set a bounded result limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description only needs to add context. It does so by specifying that only published articles are returned, that results include canonical HTML and Markdown URLs, and that the result count is bounded. Minor gaps like ordering and pagination are not addressed, but they are secondary to the safety profile already covered by 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?
The description is a single sentence with no filler. It front-loads the resource and output, then states the two optional behaviors concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional parameters and no nested objects, the description covers the resource, output URLs, filtering, and bounded limit. Exact output field details are absent, but they are not necessary to invoke the tool correctly, and the annotations handle side-effect and safety expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare parameter names. It does this by explaining that 'category' is a filter and 'limit' sets a bounded result count. It does not enumerate possible category values, but the schema already provides limit's numeric range and default.
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 'List' and a specific resource, 'published Aperture Journal articles', and names the key output detail (canonical HTML and Markdown URLs). This clearly distinguishes it from siblings such as get_article, which implies single-article retrieval.
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: this is a bulk list operation over published articles, with optional category filtering and a bounded limit. It does not explicitly mention alternatives like get_article or search, but the list-versus-single distinction is evident and no exclusion guidance is critical here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documented Aperture Wallet features with canonical article links and safety notes. Optionally filter by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional exact feature category such as security, recovery, transactions, bitcoin, or utility. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by noting the output includes 'canonical article links and safety notes,' which is beyond what annotations provide.
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 sentence that states the purpose and the optional filter. Every word earns its place, and it is front-loaded with the core function.
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?
The tool has a simple schema with one optional parameter, annotations covering safety, and no output schema. The description explains what is returned (links and safety notes) and the optional filter, which is sufficient for an agent to call it correctly. It does not mention how results are ordered or paginated, but these are minor gaps for such a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, category, is clearly described with examples of valid values. The description's mention of filtering by category reinforces the schema without adding much new information, but the coverage is complete.
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: list documented Aperture Wallet features, with canonical article links and safety notes. It does not explicitly distinguish itself from sibling tools like search or fetch, but the mention of 'canonical article links and safety notes' gives some differentiation.
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 implies an optional filter by category, which offers some usage context. However, it does not state when to use this tool versus alternatives like search or fetch, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the mainnet account and network catalog documented from the current Aperture source tree. Do not treat a matching ticker as proof of cross-network compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Optional exact family filter such as evm, bitcoin-utxo, solana, move, or stellar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call read-only, idempotent, and non-destructive; the description adds that the catalog is sourced from the current Aperture source tree and cautions that matching tickers are not evidence of cross-network compatibility. This gives an agent important context about the data source and interpretation beyond the annotation flags.
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 concise sentences; the first front-loads the primary purpose and the second delivers a valuable caution without padding. Every sentence 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 simple read-only list tool with one optional, fully documented parameter and no output schema, the description covers the input, the source of data, and one key interpretation caveat. It does not enumerate the return shape, but the catalog object is adequately identified for a low-plexity operation.
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 only parameter, family, is already fully documented in the schema with an exact filter and examples (evm, bitcoin-utxo, solana, move, stellar). With 100% schema description coverage, the description does not need to add parameter detail, 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 uses a specific verb ('Return') and names an exact resource: the mainnet account and network catalog documented from the current Aperture source tree. This clearly distinguishes the tool from sibling list operations like list_features or list_articles; even without naming an alternative, the object is unambiguous.
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 implies its use: querying the curated mainnet catalog for Aperture networks, and the warning adds a constraint on how to interpret results. It does not explicitly state when to prefer it over sibling tools or identify alternatives, so usage guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search canonical public Aperture Wallet product facts, security guidance, supported-mainnet metadata, app-screen semantics, and Journal articles. Use this before answering an Aperture-specific question. This tool never searches user wallets or private account data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Natural-language Aperture topic or question. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: it restricts the search to canonical public knowledge and explicitly states it never searches private account data. This is a meaningful privacy/scope disclosure that the annotations alone do not convey.
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, each earning its place: what the tool searches, when to use it, and what it will not search. The key scope is front-loaded, and there is no redundant filler or restating of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a broad search tool with only two parameters, an output schema, and safety-carrying annotations, the description is complete. It covers scope, usage timing, and a critical privacy boundary; anything else needed for invocation, such as response shape, is covered by the output schema.
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 already describes query as a natural-language Aperture topic, and the description reinforces this by listing the exact content categories and advising use before Aperture-specific questions. The limit parameter has no prose description, but its name, default, min, and max make its purpose inferable, so the coverage gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search') and resource ('canonical public Aperture Wallet product facts'), then enumerates the covered content domains: security guidance, supported-mainnet metadata, app-screen semantics, and Journal articles. This clearly differentiates it from the targeted sibling getters and listers by presenting it as a cross-cutting knowledge search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use directive ('Use this before answering an Aperture-specific question') and a clear exclusion ('never searches user wallets or private account data'). It does not explicitly name alternative sibling tools for targeted lookups, but the usage context is strong enough that an agent can decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_article1 field changedInput schema / properties / localeAdded value: +{
+ "default": "en",
+ "description": "Published article language, such as en, es, ar, or zh-Hans.",
+ "pattern": "^[a-z]{2,3}(?:-[A-Za-z0-9]{2,8})*$",
+ "type": "string"
+}fetchget_app_screenget_articleget_featureget_latest_releaseget_productget_security_modellist_app_entry_pointslist_articleslist_featureslist_supported_networkssearchVerified memory for AI agents. Signed assertions, billing attestation, session continuity.
Privacy-first document verification anchored to the public ledger.
Tenzro Ledger MCP: wallet, identity, payments, inference, staking, bridges, verification, agents.
Verified registry of third-party-system knowledge — the external-dependency layer for agent memory.
Add one secure layer between your agents and this server.
