threenative-asset-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation5/5
Each tool is clearly distinguished by a provider prefix (fab_, polyhaven_, etc.) and a distinct action (search, get, list, download). The only potential overlap is between generic asset_download_file and provider-specific download tools like fab_download_free_asset, but they target different providers and descriptions clarify the scope. No two tools appear to serve the same purpose.
Naming Consistency5/5
All tools follow the consistent pattern provider_verb_noun or asset_verb_noun, using snake_case throughout. Verbs like search, get, list, and download are used predictably across providers. There is no mixing of conventions or unusual names.
Tool Count4/5
With 32 tools, the count is above the typical 15-tool threshold, but it is justified by the number of asset sources (6 major providers plus generic utilities). Each source needs 3-5 tools, and the bundle inspection/extraction tools add necessary functionality. The set earns its place without being excessive.
Completeness5/5
The tool surface covers the full lifecycle for each source: discovery (search), metadata retrieval (get), file listing, and download. It also includes cross-source search, bundle inspection, and direct URL download. No obvious gaps exist for the read-only asset aggregation purpose.
Average 3.8/5 across 32 of 32 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context such as rate limits, pagination behavior, or query syntax, leaving a gap beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the tool's purpose reasonably. However, it is too sparse and could benefit from additional context without becoming verbose. It earns a baseline score for efficiency but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are five parameters with no schema description coverage and no parameter information in the description, the description is incomplete. An output schema exists, which lessens the need to describe return values, but behavioral aspects (e.g., sorting, pagination via cursor) are missing. The description should provide more context for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the five parameters (sort, type, limit, query, cursor). The description does not compensate for the lack of schema descriptions, making it difficult for an agent to understand parameter usage without inspecting the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the resource 'CC0 materials, HDRIs, models, decals, atlases, brushes, terrains, and other ambientCG assets', and is specific enough to distinguish from sibling search tools for other sources (e.g., Poly Haven, Fab).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling search tools (e.g., polyhaven_search_assets, fab_search_assets). There is no mention of preferred use cases, exclusions, or context that would help an agent decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by mentioning what metadata is returned (format, quality, compression, orientation). However, it does not describe pagination behavior or rate limits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it omits critical information. Conciseness should not sacrifice clarity or completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (1 required), many enums, and an output schema, the description fails to explain pagination, filtering, or the relationship between modelId and files. Sibling context suggests this tool is part of a broader ecosystem, but no hints on how it fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 hints at 'format' and 'quality' parameters but does not explain 'cursor', 'limit', 'fileType', 'modelType', or the required 'modelId'. 'Compression' and 'orientation' are not parameters but output fields, adding confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list files) and resource (Smithsonian Open Access files). It mentions specific metadata types, distinguishing it from sibling tools like smithsonian_search_assets and smithsonian_get_asset. However, it does not explicitly differentiate from non-Smithsonian list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like asset_list_sources or polyhaven_list_files. The description does not mention prerequisites, filtering, or pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that free assets are returned by default, which is useful but not extensive. No disclosure of other behaviors like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads purpose. However, for a tool with 19 parameters, it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to provide an overview of filtering capabilities or search behavior. Many sibling tools exist, and this description does not help an agent understand when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the 19 parameters beyond hinting at the 'priceMode' default. It adds negligible semantic value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'public Fab marketplace listings', a specific verb+resource. It distinguishes from sibling tools that search other marketplaces (e.g., polyhaven_search_assets). The note about free assets as default adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like polyhaven_search_assets or sketchfab_search_models. Does not mention prerequisites, when not to use, or other context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, indicating a safe read operation. The description adds context about output content (variant attributes, extensions, etc.) but does not reveal additional behavioral traits like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 12 words, no redundancy. Efficiently communicates the core purpose without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is insufficient for a list tool with 5 parameters. It lacks details on pagination (cursor/limit), required assetId, filtering (extension, attributes), and when to use this tool over alternatives. The agent would struggle to invoke this correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 only hints at 'variant attributes' and 'extensions' but fails to explain the purpose or format of parameters like assetId, limit, cursor, extension, and attributes. This leaves the agent uninformed about how to effectively use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists official CC0 asset archives and specifies the returned fields: variant attributes, extensions, URLs, and byte sizes. It distinguishes from sibling tools like ambientcg_search_assets and ambientcg_get_asset, which focus on searching or getting single assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings (e.g., ambientcg_get_asset for single asset details, or polyhaven_list_files for Poly Haven files). No prerequisites, when-not-to-use, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that results include explicit Poly Haven attribution, a useful behavioral detail for licensing. However, it does not describe pagination, sorting behavior, or error handling beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The description is front-loaded with the action and includes an additional detail about attribution without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an existing output schema, the description lacks explanation of how to use parameters like cursor, limit, and categories. It does not cover result structure, pagination, or typical usage patterns for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides no parameter information beyond hinting at the 'type' parameter (HDRIs, textures, models). Six parameters remain unexplained, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches CC0 HDRIs, textures, and models from Poly Haven. It distinguishes from siblings by specifying the source (Poly Haven) and content type (CC0), and adds a unique detail about attribution in results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like fab_search_assets or ambientcg_search_assets. The description does not provide context for selection based on asset source or licensing needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that it returns metadata and asset counts, which is useful, but lacks details on pagination, errors, or performance. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered. However, the optional 'type' parameter is unexplained, and given siblings, more context on filtering would help. Tool is simple but description could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one optional parameter 'type' with enum, but description does not mention it. With 0% schema description coverage, the description should compensate but fails to explain the parameter's purpose or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('list') and resource ('ambientCG category metadata and asset counts'). It differentiates from sibling tools like polyhaven_list_categories and sketchfab_list_categories by specifying 'ambientCG'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tools offer similar list_categories functions for other sources, but description provides no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by mentioning that a warning identifies 'versioned fallback or stale values,' indicating potential data quality concerns. However, the annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description does not significantly expand on these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose. Every sentence adds value: the first states the main action, the second highlights a notable behavior (warning). No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (not shown), the description does not cover the parameters, leaving a significant gap for a tool with 2 parameters and 0% schema coverage. The warning about stale values adds some depth, but the overall description is slightly incomplete for an agent to understand parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema is not described in the description (0% coverage). The 'kinds' parameter has enum values and 'refresh' is a boolean with default false, but their effects are not explained. The description provides no guidance on how these parameters affect the results, relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'usable public Fab filter labels and slugs,' with a specific verb and resource. It distinguishes itself from sibling tools like fab_search_assets, which search for assets, by focusing solely on filter metadata. The mention of a warning about versioned fallback values adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing Fab filters but does not explicitly state when to use this tool versus alternatives like fab_list_limited_time_free or other filter-related tools. No exclusion criteria or alternative tool references are provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds that the output is a 'normalized summary' but does not elaborate on what normalization entails or disclose other behaviors like rate limits or authentication needs. With rich annotations, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, 12-word sentence that efficiently conveys the core purpose. It is front-loaded with the verb and resource, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description need not detail return values. The description is sufficient for understanding the tool's role among many siblings, but the minimalism leaves some questions about the 'normalized summary' concept. Still, it is largely complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the modelId parameter at all. While the parameter name and requirement are clear, the description fails to compensate for the lack of schema documentation. It should explain what modelId is or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('normalized summary of one Smithsonian Open Access 3D model'). It distinguishes from sibling tools like smithsonian_search_assets (search) and smithsonian_list_files (list files), making the tool's unique purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after searching for a model, but does not explicitly state when to use this tool versus alternatives like smithsonian_search_assets or smithsonian_list_files. No when-not conditions or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds minimal behavioral context beyond the search criteria, which is expected given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of 14 words. It front-loads the purpose and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, 0% schema description coverage) and the existence of an output schema, the description should cover all major filter options. It only covers a subset, leaving out cursor-based pagination, boolean flags, and file type variants. The output schema helps, but the description is still too sparse for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing burden on the description to explain parameters. The description only mentions four categories (text, type, quality, owning unit) but not the other five parameters (limit, cursor, dracoCompressed, gltfOrientationCompliant, and implicit enumeration details). This is insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Smithsonian Open Access 3D models and file variants, with specific filter criteria (text, type, quality, owning unit). It distinguishes itself from sibling tools that search other sources (e.g., fab, polyhaven, sketchfab).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the source (Smithsonian) and search criteria, but does not explicitly state when to use this tool versus alternatives. It lacks when-not-to-use guidance or explicit context for choosing among sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, indicating a safe read operation. The description adds only that it lists separately from general free search, adding minimal behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no superfluous text. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations and an output schema, the description is mostly sufficient. It could mention default limit and behavior when no promotions exist, but the output schema likely covers return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (limit) is fully documented in the schema (type, default, min/max). With 0% schema description coverage, the description does not add parameter meaning, but schema coverage is complete for this single parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists limited-time-free promotions from Fab, distinguishing it from general free search. It uses specific verb 'list' and resource 'promotions', but does not explicitly name the sibling tool for general free search (fab_search_assets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for limited-time-free promotions versus general free search, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds value beyond annotations by specifying exact output fields (download URLs, byte sizes, MD5 hashes, file dependencies) and the presence of filters. This helps the agent understand the response structure without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, immediately followed by key output details and filter capabilities. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (assumed to document return values), the description does not need to detail them. However, it fails to mention pagination parameters ('limit', 'cursor') and only lightly covers filters. For a tool with 6 parameters and 1 required, the description is slightly incomplete but still adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It only mentions two parameters ('format' and 'resolution') as filters, ignoring 'limit', 'cursor', 'assetId', and 'includeDependencies'. The agent gets no explanation of pagination or how to use the required 'assetId'. This is insufficient for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'download URLs, byte sizes, MD5 hashes, and file dependencies' for a Poly Haven asset, with explicit mention of format and resolution filters. This distinguishes it from siblings like polyhaven_get_asset (which likely gets metadata) and ambientcg_list_files (different source). The verb 'list' and specific resource 'Poly Haven asset' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or compare with similar tools like polyhaven_get_asset or asset_list_sources. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds value by detailing returned metadata fields, which goes beyond what annotations convey. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 15 words, front-loaded with purpose and return info. No wasted words, to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Basic purpose and return are covered, but parameter usage is not explained. Output schema may clarify return structure, but for a tool with 9 optional parameters, more guidance is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 9 parameters. Description does not explain any parameter semantics (e.g., query, sortBy, filters). It must compensate but fails, leaving agents to guess parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search public Sketchfab models' with verb+resource, and specifies return fields (license, author, geometry, archive metadata). This distinguishes from siblings like sketchfab_get_model (single model) or sketchfab_list_categories (categories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implied by context but no alternatives named. Sibling list provides context but description lacks usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. The description adds behavioral context by specifying that the output includes 'normalized metadata and CC0 licensing', which is useful beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to detail return values. However, it could benefit from mentioning the scope of metadata fields or any required permissions, but is largely complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its single parameter (assetId). The tool description does not explain what assetId represents, its format, or how to obtain a valid ID. This forces the agent to infer from context, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'normalized metadata and CC0 licensing' for a single ambientCG asset. It uses a specific verb ('Get') and resource ('ambientCG asset'), and distinguishes from sibling search/list tools that operate on collections or different sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for fetching details of a specific asset, but does not explicitly state when to use it versus alternatives like search or list tools. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotent and non-destructive hints. The description adds context on behavior: removes unrelated clips/meshes/materials/textures, reuses cached source entries, and uses range-fetching. These details go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loads the action. However, the phrasing is technical ('range-fetching', 'aggregate source entry') which may reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description covers the core function but omits prerequisites (e.g., listing animations first) and does not describe the output beyond 'standalone GLB'. Adequate but incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It only mentions 'one named animation' but does not explain the required parameters (packId, uploadId, animationName, acceptLicense) or the optional entryPath. The agent must infer mappings from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports one named animation as a standalone GLB from a bundled source. Specific verb 'export' and resource 'animation' distinguish it from sibling tools like asset_download_bundle_entry (downloads full entry) and asset_list_bundle_animations (lists animations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after listing animations ('one named animation') but does not explicitly state when to use vs. alternatives like asset_download_bundle_entry. No exclusions or contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds context about the type of metadata returned (authorship, dimensions, license). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 13 words, front-loaded with verb and resource. Every word is informative; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are defined. The description covers the main output components. However, it could mention that the asset ID comes from a search tool. Still, it is sufficient for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It does not mention 'assetId' or how to obtain it. The parameter is required, yet the description lacks any guidance on its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'one Poly Haven asset', and specifies the returned information: normalized metadata, authorship, dimensions, and CC0 license. It distinguishes this tool from search and list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need metadata for a specific Poly Haven asset, but it does not explicitly mention when not to use it or provide alternatives. Given many sibling tools, more guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by explaining the range-extraction and caching process, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence delivers the core function; the second adds a key default behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return format is handled), the description covers the main behavioral aspects: caching, automatic selection, and the result being named clips. It could clarify that it only lists names (not downloads), but that's inferable from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (low, <50%), so the description should compensate. It only explains entryPath ('omit to select standard non-root-motion GLB'), leaving packId and uploadId unexplained. Without that context, the agent may not infer their roles from names alone, especially since packId has an enum but no guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists animation clips inside a bundled GLB, using specific verbs and the resource. The title reinforces this. The tool is well-differentiated from siblings like asset_download_bundle_animation (download) and asset_list_bundle_entries (list entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on omitting entryPath to automatically select the standard non-root-motion GLB, but does not explicitly state when to use this tool over alternatives, such as when only animation names are needed. It lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions HTTP byte ranges, return of entry paths and sizes, and that signed URLs are never exposed. This complements the readOnlyHint=true annotation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every word adds value. No unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, simple list output), the description covers the key return values (entry paths and sizes) and a security note. The presence of an output schema reduces the need to detail return structure. Minimal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (packId, uploadId) with 0% description coverage. The description does not explain what packId or uploadId represent or how they relate to the 'curated itch.io ZIP,' leaving the agent without parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a curated itch.io ZIP via HTTP byte ranges, listing entry paths and sizes. The verb 'inspect' and resource 'curated itch.io ZIP' align with the title 'List files inside a remote asset bundle,' and the purpose is distinct from sibling tools like download or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for inspecting bundle contents without full download, but it does not explicitly state when to use this tool versus alternatives (e.g., asset_download_bundle_entry). No comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, providing strong behavioral transparency. The description adds the specific context of returning normalized details and per-license prices, but does not disclose behavior for invalid inputs or edge cases. The added value is moderate given the rich annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word provides value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (1 required), a rich set of annotations, and an output schema, the description is largely adequate for selection. It could mention that listingIdOrUrl accepts either an ID or a URL, but overall it provides sufficient context for an agent to decide when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameters. It mentions 'one Fab listing' but does not detail the listingIdOrUrl parameter (e.g., format, what it accepts) or the currency parameter. This leaves the agent with minimal guidance beyond the schema's structural definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get normalized public details and per-license prices for one Fab listing,' specifying the verb (Get), resource (Fab listing), and the type of data returned (details and prices). This distinguishes it from sibling tools like fab_search_assets which perform searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a single Fab listing, and the naming suggests it complements search tools. However, it does not explicitly state when not to use it or provide alternatives, though the sibling set includes similar tools for other sources, making context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: signed URLs are not exposed, the download is streamed to guarded local storage, and license acknowledgement is required. This aligns with annotations (readOnlyHint=false, idempotentHint=true) and adds useful context about side effects and security.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and flow, then clarify a key detail (signed URL exposure). Every sentence adds value, no fluff or repetition of schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core process but lacks guidance on prerequisites (e.g., the need to call itch_list_downloads first), error handling, or what the tool returns. An output schema exists but is not shown; the description does not compensate for missing details on success/failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only acceptLicense has a description). The description adds context that acceptLicense is a required boolean acknowledgement and links to license terms, but provides little additional meaning for packId and uploadId beyond what the schema enum and pattern offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resolve and stream), the resource (itch.io asset pack upload), and the flow (explicit license acknowledgement, signed URLs not exposed). It distinguishes from sibling tools by specifying 'itch.io' and 'curated asset pack', and from other download tools by the unique process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a packId and uploadId and after acknowledging a license, but it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or refer to other tools for comparison. The reference to 'listed upload' hints at a prerequisite but could be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds limited new behavioral insight. It confirms no credential storage and no file downloading, which is useful but not extensive. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no extraneous information. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and output schema, the description covers key aspects: token requirement, temporary URLs, and non-storage. It could mention the modelId's role but is otherwise sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not mention the 'modelId' parameter or its format. This fails to add meaning beyond the schema, which is especially problematic given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves temporary download URLs for a Sketchfab model using the user's API token, providing a specific verb-resource pair. This distinguishes it from sibling tools like sketchfab_search_models or sketchfab_get_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool requires a valid SKETCHFAB_API_TOKEN and clarifies that it does not store credentials or download files, giving context for when to use it. However, it does not explicitly exclude usage scenarios or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying what is returned (public metadata and Creative Commons requirements), beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that instantly conveys the action and target, with no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (covering return values), simple parameters, and the description states the retrieval scope. It is complete enough for this straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not explain the modelId parameter beyond the schema's pattern, missing an opportunity to clarify its meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('public metadata and explicit Creative Commons requirements for one Sketchfab model'), clearly distinguishing from sibling tools like sketchfab_search_models and sketchfab_get_downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single model's metadata and license info, but it lacks explicit when-to-use guidance or comparisons with siblings. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as true/false. The description adds 'public' and 'model category names and slugs' but does not contradict annotations. No additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence provides all necessary information without waste. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no parameters, the description is complete. It specifies the resource and output fields (names and slugs), covering all needed context for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% by default. The description adds no parameter info, but none is needed. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'public Sketchfab model category names and slugs'. It distinguishes the tool from sibling tools like sketchfab_search_models and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, such as other category listing tools (e.g., polyhaven_list_categories) or search tools. No explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context that the tool downloads to a local directory and never performs purchases or library operations, which aligns with annotations. It does not detail file overwrite behavior or other side effects, but the idempotency hint mitigates some concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that convey the core purpose and a key behavioral distinction with no redundant information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (3 required params, output schema exists), the description covers the overall function and important behavioral notes but lacks parameter details. For a download tool, it is adequate but not fully complete without addressing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only acceptFabEula has a description). The description does not elaborate on 'listingIdOrUrl' or 'format', leaving agents to infer meaning from names alone. For low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (download), resource (free Fab file), and location (configured local download directory). It explicitly distinguishes itself from purchasing or adding to a library, which sets it apart from sibling tools like fab_search_assets or fab_get_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool (downloading a free Fab file) and when not to use it (if the intent is to purchase or add to library). However, it does not explicitly mention alternative tools or prerequisites such as requiring a valid listing ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns category labels and asset counts, which is basic behavioral context. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb 'List' and the resource. There is no extraneous information; every word is necessary and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple one-parameter tool and an output schema present, the description adequately indicates what is returned (category labels and asset counts). It could be slightly more detailed but is generally complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description lists the allowed types (HDRIs, textures, models) corresponding to the enum. This adds meaning beyond the schema by explicitly pairing the parameter with the tool's resource types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Poly Haven category labels and asset counts for HDRIs, textures, or models. It distinguishes from sibling tools like polyhaven_search_assets and polyhaven_get_asset by specifying the listing action and resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing categories but provides no explicit guidance on when to use this tool versus alternatives (e.g., polyhaven_list_files) or any exclusions. The context is clear but lacks when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness. The description adds behavioral details: extraction via HTTP byte ranges, local caching, and avoidance of downloading unrelated contents. It also notes the license requirement, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are covered), the description sufficiently explains the core operation and key prerequisite. It could explicitly mention the relationship to sibling tools, but overall it is complete enough for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only acceptLicense has a description). The description does not explain packId, uploadId, or entryPath meanings beyond what the schema provides. It fails to compensate for the low coverage, leaving parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts one selected ZIP entry from a remote asset bundle using HTTP byte ranges, caches it locally, and avoids downloading unrelated contents. This distinctively differentiates it from sibling tools like asset_list_bundle_entries (listing) and asset_download_bundle_animation (animation download).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires explicit license acknowledgement', indicating a prerequisite for use. It implies usage after listing bundle entries, but does not explicitly state when not to use or provide alternatives. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and open-world. The description adds meaningful behavioral context: it explicitly states that no account is required and that signed page tokens are never returned, which addresses a potential security or privacy concern. This goes beyond the annotations and helps the agent understand the tool's safety and access model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded. The first sentence delivers the core purpose and output, and the second sentence adds a critical security note. Every clause earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a single parameter with clear enums, a read-only annotation, and an existing output schema, the description is complete. It covers the action, the resource, the output fields, and the important behavioral note about tokens. No gaps are present for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter packId has an enum list of specific values, which are self-explanatory. Schema description coverage is 0%, but the description does not need to add meaning because the enum values and tool name already convey the parameter's purpose. The description adds 'fresh no-account' context, which is not parameter-specific but useful. A score of 3 is appropriate: the description does not hinder understanding but neither does it enhance the schema significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resolve and list uploads), the resource (itch.io pack download page without account), and the specific information returned (upload IDs, names, sizes, license, filenames). It distinguishes this tool from siblings like itch_download_asset, which performs downloads instead of listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing available downloads from a pack, but it does not explicitly state when to use it versus alternatives like itch_download_asset, nor does it provide prerequisites or exclusions. The context from sibling names helps infer the intended use, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that the tool searches sources and clarifies exclusion behavior (manual sources unless agentReadyOnly=false), which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasteful words. The first sentence announces the core action and filters; the second clarifies the important exclusion rule. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (explaining return values), the description covers the main functionality and filtering options adequately. It mentions the key agentReadyOnly condition. Minor gap: does not explicitly state that it returns sources (not assets), but that is inferred from tool name and category. Overall complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions four out of five parameters (query, category, license, access) and implicitly references agentReadyOnly through the exclusion rule. However, it does not explain each parameter's behavior or constraints in detail, leaving some ambiguity (e.g., what 'access mode' values are available). Partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches 'agent-ready asset sources' with specific filters (category, license, access mode, text query). It distinguishes from other search tools (siblings like fab_search_assets) by specifying the scope and the exclusion of manual/provider-page sources unless agentReadyOnly=false.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for searching agent-ready sources, with a note that manual/provider-page sources are excluded by default. It implies that for non-agent-ready sources one might need to set agentReadyOnly=false or use other tools, but does not explicitly mention sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive; the description reinforces this with 'existing files are never overwritten.' It adds new constraints like URL restrictions to official hosts, which annotations don't cover. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence conveys main purpose and key condition; second adds important behavioral constraints. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown) and annotations cover safety hints, the description adequately explains core behavior, security, and idempotency. Could mention error handling for invalid IDs, but overall complete for a download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context for acceptLicense (required acknowledgement) beyond the schema, but assetId is only described as 'by ID' without extra semantics. Schema provides pattern and maxLength for assetId, so overall value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a catalog asset by ID into a dedicated audio directory, requiring license acknowledgement. It distinguishes from siblings like audio_search_assets (search) and fab_download_free_asset (free assets) by specifying the exact action and conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: requires license acknowledgement, URLs are restricted to official hosts, and files are never overwritten. It implies when to use (after searching with audio_search_assets) but does not explicitly state when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds specific behavioral context about what is listed (libraries, licenses, browse pages, contracts), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's output without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an existing output schema, the description is complete enough for an agent to understand the tool's purpose and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters with 100% schema coverage trivially. The description adds meaning beyond the empty schema by detailing what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported audio libraries, best uses, licensing caveats, browse pages, and contract info, distinguishing it from sibling search/download tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get an overview of audio sources), but does not explicitly state when not to use it or compare it to siblings like audio_search_assets or audio_download_asset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, and the description adds context about stable direct URLs and explicit license metadata, which are non-obvious behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no filler, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the core purpose and primary usage scenario, but lacks explanations for pagination and parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain at least key parameters like query, kind, source, and limit, but it doesn't mention any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a curated catalog of official audio packs with stable URLs and license metadata, and distinguishes itself from the sibling audio_list_sources for broader discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (searching curated catalog) and when to use an alternative (audio_list_sources for broader provider-page discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show mutability (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds critical details: allowlisted hosts, redirect revalidation, byte cap, and no overwrite policy. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling ~70 words, front-loaded with core action and constraints. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers provider scope, license requirement, security measures (allowlist, revalidation, byte cap), and idempotency (no overwrite). Return details are omitted but output schema exists, so complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only acceptLicense has description). Description adds context about license acknowledgement and validation of URL shapes, but does not fully explain each parameter's syntax or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool downloads a file URL from specific providers (Poly Haven, ambientCG, Smithsonian, Game-icons.net/Kenney) with license acknowledgement. Distinct from sibling tools like fab_download_free_asset or audio_download_asset which target different providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when a file URL from those providers is obtained and license must be accepted. Does not explicitly exclude when not to use or provide alternative sibling tools, but context of siblings is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint. The description adds significant context: results have MCP download paths without manual browser/login/paywall, and the broader directory includes package-manager, Git, authenticated sources. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence front-loads the core functionality and key benefit, the second explains the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and full annotations, the description is complete. It explains the two modes, the nature of results, and acknowledges the output schema existence. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining the agentReadyOnly parameter's effect (default true gives agent-ready sources, false gives broader list). This adds crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists asset sources, distinguishing between agent-ready and broader sources. It uses a specific verb ('list') and resource ('asset sources'), and effectively distinguishes itself from sibling tools like asset_search_sources and various asset search/download tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior and how to get broader results via the agentReadyOnly parameter. It implies when to use each mode, but does not explicitly contrast with sibling tools or state when not to use it. Still, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![threenative-asset-mcp MCP server](https://glama.ai/mcp/servers/jonit-dev/threenative-asset-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jonit-dev/threenative-asset-mcp)

Score Badge

Copy to your README.md:

[![threenative-asset-mcp MCP server](https://glama.ai/mcp/servers/jonit-dev/threenative-asset-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jonit-dev/threenative-asset-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jonit-dev/threenative-asset-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server