Retrieve the current canonical version number for any asset by providing its ID, enabling accurate version checks and consistent art asset management.
Get the canonical (current) version number of an asset.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | Asset identifier |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. The one-liner is nearly a restatement of the name '+ asset' and only clarifies that the return value is the version number, not the wrapped resource. It stops short of describing what happens for missing/invalid assets, whether the return is a plain value versus a structured object, or how 'current' interacts with archive/deprecate state. It isn't a tautology, but it does the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly scoped sentence, front-loaded with the verb, zero filler. Every word earns its place, and the key qualifier 'canonical (current)' is placed where it's most visible. This is exactly how a tool at this complexity level should be written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial 1-parameter read with no output schema, the contract 'asset_id in, version number out' is marginally adequate. The main gap is the return type (a bare number vs. '1.4.2' vs. an object with metadata), which becomes agent-visible ambiguity. Given the untapped opportunity in the sibling graph, this stops just short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% ('Asset identifier' is self-explanatory for asset_id). The description adds no parameter detail and doesn't need to. The baseline-3 applies: the structured field fully documents the parameter, and no additional semantics (formats, allowed values, side effects on the resource) are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Get the canonical (current) version number of an asset" uses a specific verb and resource. The qualification "canonical (current)" meaningfully narrows the scope to the version number rather than the asset object. However, it doesn't distinguish itself from the dense sibling cluster (art.asset.get, art.asset.inspect_version, art.asset.history), so an agent still has to guess how this differs from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is offered at all. With 60+ siblings and at least 4-5 plausible alternatives in the same namespace (get, inspect_version, exists, history, compare), the description should say when this read-most-likely-cheap call is preferred over art.asset.get, which returns the full asset. No alternative or exclusion is mentioned, forcing the agent to infer scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.