Verified Aperture Wallet product, security, network, release, and Journal knowledge.
Average 4.3/5 across 12 of 12 tools scored.
Most tools target distinct resource types (product, security, features, articles, networks, release, screens, entry points), with get_/list_ pairs clearly separating single-item retrieval from collection listing. The only mild ambiguity is between get_app_screen and list_app_entry_points, since both describe UI navigation surfaces, though their descriptions keep screen semantics vs entry-point catalogs separate.
The dominant get_<singular> and list_<plural> pattern is clear and predictable for 10 of 12 tools. 'search' and 'fetch' break the noun-oriented pattern and are less descriptive of their distinct roles, but they are common enough verbs that the overall set remains readable.
With 12 tools, the server is well-scoped for a wallet knowledge base: each get tool corresponds to a distinct knowledge category and list tools cover discoverability. No tool feels redundant, and the count is squarely in the appropriate range.
The surface covers the major knowledge domains an agent needs: product identity, security model, features, articles, supported networks, release info, app screens, and entry points, plus search/fetch for open-ended lookup. Minor asymmetries exist (e.g., get_app_screen has no listing counterpart, and list_app_entry_points has no single-item get), but these are workable through search.
fetchFetch an Aperture sourceAFetch 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.
get_app_screenGet an Aperture app screen descriptionAReturn 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.
get_articleGet an Aperture Journal articleAReturn the complete citation-ready Markdown representation of one published Aperture Journal article by slug, including canonical URL, dates, topics, body text, and public images.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying the exact return shape ('citation-ready Markdown' with canonical URL, dates, topics, body text, and public images), which is especially valuable because no output schema exists. It does not describe error or not-found behavior, but the main safety-relevant behavior is already covered by 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?
The description is a single sentence that starts with the action and expected outcome, then packs the key inclusions with no filler or repetition of schema details. 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?
Given only one parameter, strong read-only/idempotent annotations, and no output schema, the description is complete: it names the input, the article scope, and the exact return components. Nothing critical is missing for selecting and invoking the 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 schema's slug property has no attached description (0% coverage), so the description must carry semantic weight. It tells the agent that the slug addresses 'one published Aperture Journal article' and that the result is full Markdown, but it does not explain how to obtain or construct a slug beyond what the regex pattern already encodes. This is adequate for a single well-defined parameter, but not rich.
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 resource ('one published Aperture Journal article by slug'), and it enumerates the output contents: canonical URL, dates, topics, body text, and public images. This clearly differentiates it from list_articles, which would return multiple or summary results, even though it does not name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes the context: call this when you already have an article slug and want the full article. It does not explicitly point to alternatives such as list_articles for cases where the slug is not known, so it stops short of fully prescribing 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.
get_featureGet an Aperture featureAReturn 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.
get_latest_releaseGet the latest public Aperture release snapshotAReturn 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.
get_productGet Aperture product factsAReturn 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.
get_security_modelGet Aperture security boundariesAReturn 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.
list_app_entry_pointsList safe Aperture app entry pointsAReturn 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_articlesList Aperture Journal articlesAList 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_featuresList Aperture featuresAList 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.
list_supported_networksList Aperture mainnetsAReturn 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.
searchSearch Aperture public knowledgeASearch 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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Verified 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.
