game-art-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Tools are grouped by domain prefixes (art.asset, art.memory, art.qa, art.provider, art.production), which helps, but within groups many operations overlap (e.g., art.asset.archive vs archive_version, art.asset.deprecate vs archive, art.asset.update vs promote/rollback). Some tools like art.get_style, art.get_style_rules, art.validate_style, art.memory.explain_style could be confused regarding their exact roles.
Naming Consistency4/5Naming is mostly consistent with a dotted domain prefix followed by verb_object (e.g., art.asset.get, art.provider.cancel). Minor deviations occur: 'art.get_palette' vs 'art.asset.get' (missing domain prefix), 'art.qa.asset' (verb after domain but no object), and 'art.asset.approval.request' uses a noun path instead of a verb_asset pattern. Overall predictable.
Tool Count2/567 tools is excessive for a single server, even with multiple domains (assets, memory, QA, providers, production). Many tools are overly granular (e.g., separate approval.request, approve, reject, request_changes, promote, rollback) and could be consolidated. The count exceeds the typical well-scoped range, making agent selection harder.
Completeness4/5The tool surface covers a comprehensive lifecycle for art assets, including registration, versioning, QA, approval, production, and memory. There are minor gaps like no explicit update for styles or providers beyond listing, and no style deletion or cloning. But the core workflows appear complete.
Average 3.2/5 across 63 of 67 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on
- 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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations or descriptions of side effects, return format, or error behavior. The tool is named 'resolve' but it is unclear whether it performs any mutations, caches results, or is purely read-only. The statement 'Returns categorized results' is too generic to convey the actual output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main verb and object. It avoids fluff and directly states the input (context) and output (categorized results). However, the brevity contributes to ambiguity, which slightly reduces the score, but structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks critical contextual details: no output schema is provided, no examples, no explanation of how the parameters affect the results, and no mention of which categories are returned. Given the existence of more specific memory tools, this generic description leaves the agent incompletely informed about the tool's full capability and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter has a brief description (e.g., 'Asset type filter', 'Style ID (defaults to latest)'), but their relationship to the resolution process is not explained. For instance, how do 'type' and 'category' interact? What does 'dimensions to match' mean in the context of resolving references and anchors? The descriptions are skeletal and do not clarify the parameter roles beyond generic filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: 'resolve relevant references, anchors, decisions, and rejections' does not clearly define the action or distinguish it from the existing find_* sibling tools (e.g., find_references, find_anchors, find_decisions, find_rejections). The term 'relevant' and 'given context' are ambiguous, and the parameters (type, category, style_id, dimensions) are not explicitly tied to that context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this combined resolver versus the dedicated find functions for each memory type. The description does not mention preferred scenarios, fallback logic, or differences from the alternatives, leaving the agent without clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain what 'approved' means as a filter default, whether the search returns partial matches, how results are ordered, or what happens when no filters are provided (does it return all references?). It also doesn't describe the return format or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is too under-specified to be truly useful. It does not front-load any key differentiators or important constraints. It might earn a 4 for brevity but lacks substance, so a 3 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters, no annotations, no output schema, and a complex domain (art references with multiple roles and statuses), the description is inadequate. It does not explain what type of references are being searched (style, character, etc.) despite the schema listing roles. An agent would need to infer the full context from the schema alone, which is possible but not ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a basic description ('Filter by role', 'Filter by status', etc.). The description adds minimal value beyond the schema, just using the word 'optional filters' which is already implied by required parameters being 0. It does not clarify the meaning of 'approved' as a status vs. a filter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for approved references with optional filters' clearly states the action (search) and resource (references), but it does not specify what kind of references (e.g., art references) or how it differs from sibling tools like art.memory.find_anchors or art.memory.resolve_references. The word 'approved' might imply a default status filter, but it's ambiguous whether it's a default or a filter option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that it's for searching art references specifically, nor does it differentiate from other search tools like art.asset.find or art.memory.find_rejections. An agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Mark an asset as deprecated', which implies a state change but does not explain consequences (e.g., whether it affects references, is reversible, requires permissions, or returns a confirmation). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, and it is front-loaded with the action. It is appropriately brief for a simple operation, though it might be considered under-specified. It earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and only a terse description, it is incomplete. An agent cannot tell when to use deprecate over sibling tools like archive or update, nor what the behavioral outcome will be. The output schema is absent, so the response format is unknown. This is a substantial deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'id' fully, so the baseline is 3. The description does not add any extra meaning beyond what the schema provides, such as format, constraints, or examples. It neither improves nor degrades the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Mark an asset as deprecated' with a specific resource. It is unambiguous, but it does not differentiate from similar sibling tools like art.asset.archive or art.asset.update, which could also change an asset's state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, side effects, or conditions like 'use this instead of archive when the asset is no longer in use but should remain discoverable'. The description only states the action without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to cover safety or behavior, so the description carries the full burden. It only states that filters are optional; it does not disclose what the search returns (list? counts?), pagination behavior, or any constraints (e.g., requires a style context). This is a significant gap for a search tool with five filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence without wasted words. It is appropriately front-loaded with the verb and resource. However, it is minimal to the point of lacking substance, which prevents a 5—it is not verbose, but it also doesn't earn its place by adding value beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the sole source of context. It is inadequate for a five-parameter search tool: it does not explain what a 'style anchor' is, what the result format looks like, whether results are paginated, or how this relates to other memory tools. A complete description would need to mention these aspects or rely on a richer schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a 'Filter by ...' description. The tool description adds nothing beyond the schema—it merely says 'optional filters,' which is already implied by having zero required parameters. Given the high schema coverage, a baseline of 3 is appropriate; the description does not enhance or clarify parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search') and resource ('style anchors'), so the purpose is evident. However, it does not distinguish this tool from sibling search tools like art.memory.find_references, art.memory.find_rejections, or art.asset.find, all of which likely have overlapping functionality. A 5 requires explicit differentiation, which is absent; a 4 would need some differentiating context, which is also missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply says 'Search for style anchors' with no mention of scenarios, prerequisites, or why one would prefer this over other search tools in the memory namespace. The agent is left to infer usage from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that this action mutates the job's state, whether it requires prior planning, what happens if the job is already running, or whether it is idempotent. For a state-changing operation with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no wasted words. The content is minimal, but for a single-line description it is appropriately compact and front-loaded with the action. It is not padded with filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing operation with no annotations, no output schema, and a single required parameter. The description is too minimal to guide the agent: it does not define what 'start' means (versus resume/create), what conditions must hold, what the expected side effects are, or what a successful call returns. Given the tool has many distinguishing siblings, this level of detail is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema declaration coverage is 100%, and the sole parameter job_id is described in the schema as 'Production job ID'. The description adds no meaning beyond this — it does not clarify whether the ID must refer to a planned, queued, or draft job, or what type of job ID (UUID, numeric, etc.) is expected. Baseline 3 holds because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a clear purpose: it starts a production job. However, 'production job' is vague and the description does not specify what 'start' entails relative to siblings like 'resume', 'plan', or 'create'. It lists a clear verb and resource but lacks the specificity to fully distinguish itself from closely related production actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus close siblings like art.production.resume or art.production.create. The agent is left to infer that 'start' may be the initial execution trigger, but there is no wording describing prerequisites, sequencing, or when an alternative (e.g., resume) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not mention side effects (e.g., whether the operation is destructive), required permissions, error behaviors if the asset does not exist, or any return value. The user is left completely uninformed about the tool's behavior beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no redundant words. It is well-structured and easy to read, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: no mention of return values, error cases, or how it relates to sibling tools. As a mutation operation without an output schema, the description should at least hint at what the caller can expect, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (id and patch) with 100% coverage. The description merely restates these ('Provide the asset ID and a patch object with fields to change') without adding deeper semantics, such as constraints on the patch fields or interaction between parameters. Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'asset', which distinguishes it from creation or deletion operations. However, it does not explicitly differentiate from other update-like operations such as archive_version or promote, though the context makes it clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a basic instruction but lacks guidance on when to use this tool versus alternatives like art.asset.register (for creation) or art.asset.archive (for archival). No conditions or prerequisites 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 are absent, so the description must carry the burden for behavioral disclosure. While it states the action ('Add a new decision record'), it does not disclose side effects, such as whether the decision is immutable, whether it verifies referenced decisions/relationships, or what the response format is. For a write operation with potential consequences (relationships, provenance), this is a notable gap. The description adds no behavioral insight beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no structure. It is under-specified: for a tool with 10 parameters, it offers no structured overview of parameters or their relationships. It is minimal but not adequately concise in the sense of covering key points—it's just terse without being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters (6 required) and no annotations. The description plus schema collectively make it usable: the schema defines required fields and constraints. However, missing context like error conditions, mutability, duplicates (e.g., what happens if the same ID already exists), or integration with related tools limits completeness. It's adequate for basic invocation but lacks deeper contextual safeguards.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for each field, so the description itself adds very little. The description mentions 'art decision record' but does not map to specific parameters or explain the required 'style' object vs. optional fields. The goal 'such as' style may make sense intuitively, but an agent would rely on the schema likely enough; the description contributes no high-level semantic guidance or parameter rationale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Add a new art decision record'), which identifies what the tool does. However, it does not distinguish this from sibling tools like art.memory.add_reference or art.memory.add_rejection, leaving some ambiguity about the specific scope. The term 'art' and 'decision' are clear enough, but the lack of differentiation from similar memory-add tools lowers the score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about prerequisites (e.g., must reference an existing style), no mention of when not to use it, and no comparison to siblings like find_decisions or add_anchor. This leaves the agent to infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it only says 'execute.' It does not state whether execution is asynchronous (the existence of art.provider.cancel hints it may be), what side effects occur (asset creation, file writes, registration), or what the dry_run parameter does. The description is not misleading, but it adds almost no behavioral context beyond the bare verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single nine-word sentence with zero filler and the core verb front-loaded. It is well structured, though the brevity borders on under-specification for a tool of this complexity; the structure earns credit, but the length limits the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 0% schema coverage, no annotations, no output schema, and over 70 siblings, a one-sentence description is far from complete. Missing context includes return values, async versus sync behavior, side effects, parameter semantics for most fields, and any required setup steps. An agent would need to inspect other tools or probe to use this safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implicitly sheds light on provider_id and operation. The other eight parameters — including the required nested style object, output, references, asset_id, asset_type, and dry_run — receive no semantic clarification in either the schema or the description. This is a substantial gap for a 10-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('execute'), a resource ('art generation operation'), and a qualifier ('via a provider'), so an agent can tell this is the run action rather than an introspection tool like art.provider.list or art.provider.capabilities. It does not, however, clarify how it differs from the similarly named sibling art.provider.operation, leaving some potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the sibling list includes closely related provider tools (art.provider.get, art.provider.capabilities, art.provider.operation, art.provider.cancel), an agent gets no hints about prerequisites such as checking capabilities first, selecting a provider, or validating a style before executing. No exclusions or alternative routing are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. The phrase 'Approve a candidate asset' merely restates the tool's function without revealing side effects, reversibility, permissions required, or downstream consequences. This is a tautological description that adds no behavioral information beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words, which is appropriately concise. It is front-loaded with the core action, but its brevity borders on under-specification; still, for what it does state, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a potentially impactful approval action, the description is severely incomplete. It fails to mention what happens upon approval, whether the asset is promoted, if subsequent steps are triggered, or any conditions that should gate the call. The one-line description leaves the agent without essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter (actor, reason, approval_id) already has a description in the schema, so the description does not need to repeat them. The description adds no extra meaning about parameter usage, but the high coverage justifies a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Approve') and a specific resource ('a candidate asset'), making the action unambiguous. It clearly distinguishes from sibling tools like art.asset.reject and art.asset.request_changes, so an agent can tell them apart immediately without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as reject or request_changes. The description provides no context about the approval workflow, prerequisites, or criteria that should be met before calling it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states 'promote... to become the canonical version' without disclosing side effects such as replacing the current version, authorization requirements, or reversibility. The mutation behavior is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, but it is under-specified for the tool's complexity. It lacks structure or additional context beyond the bare statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, nested objects, and no output schema, this description is inadequate. It doesn't explain the promotion workflow, success criteria, error handling, or implications for the asset's version history. An agent would struggle to call this correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already described. The description adds no extra meaning, such as relationships between parameters or usage context. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (promote) and the object (approved candidate to become canonical version). It is specific and uses a distinct verb, though it does not explicitly differentiate from sibling tools like art.asset.approve or art.asset.rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It never states prerequisites like having an approval record or that it should follow approval. The term 'approved candidate' implies it, but no explicit when/when-not is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Request changes' implies a write/mutation action, but the description doesn't state whether the change-request is persisted, whether it blocks or cancels the approval, notification behavior, or reversibility. For a mutation tool with zero annotation coverage this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that states the action clearly. It's front-loaded and every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations distilled from the description, this is too thin. An agent needs to know what 'request changes' does to the asset lifecycle, whether it persists, whether it feeds into an approval flow, and what the response looks like (no output schema). Four parameters including nested objects, no annotations, and no output schema – this description doesn't carry its weight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides. The nested feedback array is complex but the schema documents each sub-field (category, severity, etc.). The description doesn't clarify the relationship between reason and feedback, or how they interact. -1 for no added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Request changes') and a resource ('candidate asset'), which clearly identifies the tool's purpose. It's distinguishable from siblings like art.asset.archive_version or art.asset.update by its focus on the approval/review workflow, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling tools (e.g., art.qa.asset for quality checks, art.production.approve for approval). It doesn't state prerequisites (e.g., that an approval record must exist), nor when NOT to use it. The toolname and description imply an approval context, but no explicit routing or exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility. It states 'add' (a mutation) but does not disclose idempotency, whether it validates asset existence, whether it overwrites duplicates, or what it returns. No mention of side effects or prerequisites. A bare one-liner, so 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, no fluff. It is front-loaded with the action and object. However, it lacks any structural breakdown (e.g., when/how to use), so while concise it is not information-dense. Average 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing essential context: what a 'reference' is, how it differs from anchors/decisions, whether multiple references per asset are allowed, and what 'approved' means relative to the status field. The terse description leaves an agent guessing about semantics and preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every schema property has an explicit description (e.g., 'Asset ID this reference points to', 'Reference strength'), giving high schema coverage. The description itself adds no extra meaning beyond the word 'approved', which conflicts slightly with the status field. Baseline 3 because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'add' and object 'reference' clearly indicate a write operation, and the domain 'art memory' situates it among memory management tools. The word 'approved' adds intent but slightly conflates the operation with a status filter; however, it distinguishes from add_anchor/add_rejection siblings. Minor ambiguity, so 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs. art.memory.add_anchor, add_rejection, or resolve_references. Missing criteria such as 'when you need to store a new reference' or 'prefer add_reference for...'. Only implicit context from the name. Score 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the operation is read-only, what happens when an operation_id is invalid, whether it can be called repeatedly, or any side effects. The wording implies a query but lacks explicit safety or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It is front-loaded with the core action. However, the extreme brevity borders on under-specification, though it is not verbose enough to lose points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter, it is still incomplete. It does not explain what a provider operation is, what status values might be returned, or how to obtain an operation_id. Without an output schema or further context, an agent lacks enough information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for operation_id and coverage is 0%. The description adds no context about what operation_id represents, its format, or how to obtain it. It fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 (status of a provider operation), distinguishing it from sibling tools like execute, cancel, or list. It is concise and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as art.provider.execute or art.provider.cancel. The description does not mention prerequisites (e.g., need an operation_id from a prior execute call) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral aspects. It only states 'Request approval', which is a side-effectful action that likely creates a pending approval record or triggers a workflow. It does not disclose what happens after the request: whether it blocks, notifies human approvers, or returns a decision. The description is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient for a tool with clear semantics. However, given the complexity of the tool (7 parameters, nested objects), the brevity could be a trade-off; it's under-specified but not verbose. It earns a 4 for being front-loaded and to-the-point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects) and lack of annotations or output schema, the description does not provide enough context for an agent to understand the full purpose of the request, such as what constitutes a candidate asset, the role of the style, or the expected outcome. The description is too brief to be complete for a side-effectful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema description coverage is 100%, the description does not add any additional meaning to the parameters beyond the schema. The schema already names fields like asset_id, candidate_id, style, and actor, but the description does not explain how they relate to the approval request (e.g., that candidate_id likely refers to the generated asset version being submitted for approval). The description adds little value beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Request approval for a candidate asset' clearly identifies the action (request approval) and the resource (candidate asset), distinguishing it from related tools like 'art.asset.approve' (which approves) and 'art.asset.reject' (which rejects). However, it doesn't explicitly differentiate between requesting approval versus directly approving, which could be slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'art.asset.approve' or 'art.asset.request_changes'. The description does not state that this is for initiating an approval workflow rather than finalizing it, nor does it mention any prerequisites such as passing QA or the need for a style reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects itself; it states that the asset is removed from active use but omits whether this is reversible, whether it affects only the canonical version, what happens to references, or whether special actor permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It conveys the core action and consequence efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating archive operation with no annotations and no output schema, the description is under-specified: it lacks version semantics, reversibility, return behavior, and selection criteria. The presence of sibling archive/deprecate tools makes this ambiguity more costly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds no parameter-level meaning beyond the schema and does not clarify how asset_id identifies the canonical asset or how the actor object is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Archive') and a clear outcome ('removing it from active use'), so an agent understands the core operation. However, it does not differentiate this tool from the sibling art.asset.archive or art.asset.deprecate, and the phrase 'canonical asset' leaves the version-specific behavior implied by the tool name unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call archive_version versus art.asset.archive, art.asset.deprecate, promote, or rollback. The only usage signal is the generic purpose statement, which does not state exclusions, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the purpose and does not mention pagination, ordering, return format, or what fields each version entry contains. 'Get' implies read-only, but no further behavioral detail is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler. The action and resource are front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the returned version history contains. It does not, leaving an agent to guess about response structure, ordering, and pagination, which are material for a tool returning 'full' history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes asset_id as 'Asset identifier' with 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Get' and resource 'full version history of an asset'. The scope is clear enough to distinguish it from related siblings like art.asset.current or art.asset.inspect_version, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as art.asset.current, art.asset.inspect_version, or art.asset.provenance. The only usage signal is the phrase 'full version history', which is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It reports that the result includes an approval record, but it does not state whether the operation is read-only, what the provenance contains, whether any permissions are needed, or what the response looks like. This is thin for a tool with no structured annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the operation ('Get version provenance') and adds the key output qualifier ('including approval record'), earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should explain more about what 'provenance' includes and what the caller can expect. It does not specify return structure, limitations, or how this relates to the surrounding approval and history tools, leaving a fairly large gap for an agent selecting among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters adequately described in the input schema ('Asset identifier' and 'Version number'). The tool description itself adds no extra parameter meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get version provenance including approval record.' It clearly communicates that the tool retrieves provenance for a specific asset version, and the approval-record qualifier helps distinguish it from generic history or inspection tools. However, it does not explicitly name or differentiate against siblings like art.asset.history or art.asset.inspect_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as art.asset.history or art.asset.approval.inspect. The description implies a read operation for version provenance but gives no conditions, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action; it does not reveal side effects, whether the rejection updates an approval record, whether it can be reversed, or what response/callback occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant text. It is appropriately brief, though its brevity leaves context to be supplied elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating workflow action with no output schema and no annotations, the description is too thin to let an agent confidently understand consequences or expected results. The 100% schema coverage helps for parameters, but not for workflow semantics, rejection handling, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters and nested fields. The description adds no parameter-level meaning, but that is acceptable at baseline because the schema already carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reject') and resource ('candidate asset'), clearly identifying the action. It doesn't explicitly distinguish from sibling tools like art.asset.approve or request_changes, but the core purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance about when to use this tool versus alternatives such as art.asset.approve, art.asset.request_changes, or production.approve. The description provides no contextual conditions or exclusions, leaving the agent to infer appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'add a new style anchor' and does not disclose whether adding an existing anchor ID fails, overwrites, or duplicates, what validation occurs, or what the tool returns. For a mutation tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant elaboration. It front-loads the intended action and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—10 parameters, nested objects, multiple enums, no annotations, and no output schema—the description is far too minimal. An agent is left without guidance on return values, uniqueness/id constraints, required logical relationships between fields, or error behavior. The schema covers parameter syntax but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters and their meaning. The description adds no parameter-level detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Add a new style anchor to the art memory.' It names a specific verb and resource. It does not explicitly differentiate itself from sibling memory tools like add_reference or add_rejection, but the resource type is distinct enough to convey the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as whether the referenced style or asset IDs must already exist, nor does it explain when an anchor should be added rather than updated or resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description must shoulder the full burden of disclosing behavior, but it only states that a search occurs. The description does not disclose what a 'rejection record' represents, what entity it belongs to, whether any implicit status filtering (e.g., excluding 'archived') happens by default, or what the shape of the results will be. For a non-read-only annotation-less tool, this is a meaningful gap, though it doesn't contradict anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is seven words and wastes no words. It front-loads the action verb and noun phrase immediately, which an agent can parse in a single pass. For such a simple filtering tool, this level of concision is appropriate, though it leans toward terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity search endpoint with 5 optional, well-documented parameters, the description is mostly sufficient. The main shortcoming is the domain-specific term 'rejection records,' which is never elaborated upon (e.g., rejection of what — assets, styles?), and there is no mention of which sibling tools it complements. An agent familiar with the 'art.memory' domain will manage, but a novice agent might misinfer the resource scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a 'Filter by...' description, establishing a baseline of 3. The description's 'optional filters' correctly mirrors the schema's 0 required parameters but adds no additional meaning, such as how filters combine when multiple are provided, or whether the filters are inclusive or exact-match.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a precise verb ('Search') and resource ('rejection records'), making the core action clear and distinct from write operations. However, it doesn't explicitly differentiate from the very similarly-named sibling art.memory.get_rejection, which could plausibly perform the same action in a different mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to choose this tool over alternatives like art.memory.get_rejection, art.memory.find_references, or art.asset.find. The phrase 'with optional filters' implies a parametrized search but never states when this is the right call versus a simple get or lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose side effects (though likely read-only), error handling, or return format. With no annotations, it fails to convey what happens if the reference is not approved or not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single clear sentence with no unnecessary words. It is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools, the description lacks sufficient context about what a reference is and when to use this operation. It also omits expectations about the return value, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'id' parameter has an example in the schema, providing some semantic context. However, the description adds no extra meaning beyond the schema, and the significance of 'approved' is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (approved reference by ID). It is specific and distinguishes from sibling tools like find_references or add_reference, though the qualifier 'approved' could use clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to use this tool versus alternatives like find_references or add_reference. It lacks guidance on conditions such as having an ID or needing only approved references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Cancel' without explaining whether cancellation is destructive, irreversible, audited, or whether it affects running operations. This is notably thin for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It communicates the basic operation immediately, and given the single-parameter schema, the brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation operation with no annotations and no output schema, the description is too sparse. It does not state the effects of cancellation, whether it can be reversed, what happens to existing production attempts, or how an agent should confirm success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'job_id' as a 'Production job ID' with 100% coverage, so the description does not need to add parameter detail. It adds no extra semantic meaning beyond what the schema provides, which keeps this at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Cancel a production job.' It is specific enough to convey the core purpose, though it does not explicitly differentiate itself from sibling art.provider.cancel or explain what qualifies as a production job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description simply states the action without indicating whether the job must be active, pending, or in a particular state to be cancellable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It is a read operation ('Get full details') but does not state whether it requires special permissions, the volume of data returned (potentially large), any pagination behavior, or whether the job must exist (error behavior). It does suggest scope by naming included sub-resources, but lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. The key word 'full details' and the listed components (events, attempts, plan) are front-loaded. It is appropriately brief for a tool with one parameter and no complex output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (inspection) and the presence of many closely related production tools, the description is adequate but not complete. It does not specify the output structure (no output schema provided), does not differentiate from status/attempts, and gives no usage prerequisites. An agent might still confuse this with art.production.status due to lack of distinction, though the word 'full' hints at comprehensiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (job_id has a simple description). The description confirms the parameter is a production job ID but adds minimal extra meaning. Since the schema already documents the parameter, the baseline is 3. The description does not clarify any format specifics (e.g., whether it accepts an existing job vs. pending).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('full details of a production job'), listing the included sub-resources ('events, attempts, and plan'). It distinguishes from siblings like 'art.production.status' (which implies a lighter, status-only snapshot) and 'art.production.list' (which lists jobs), but the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 art.production.status or art.production.attempts. It does not mention that it retrieves a superset of status/attempts data, nor does it provide exclusions or contextual triggers. The distinction must be inferred from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It implies a read-only operation through 'Get', but does not explain what data is returned, what statuses may be observed, whether the tool errors on unknown job IDs, or any side-effect-free guarantees beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler or repetition. It is front-loaded with the action and resource, though it is so terse that it misses opportunities to add useful routing or behavioral context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It identifies the required parameter but leaves unclear what a caller should expect as a response, what valid production statuses are, and how this tool fits into the production workflow relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes job_id with 100% coverage as 'Production job ID', so the parameter's meaning is fully documented. The description adds no additional parameter-specific semantics such as ID format, lookup scope, or relation to other production tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'current status of a production job', which differentiates it from production lifecycle tools like create, start, resume, cancel, and approve. However, it does not distinguish it from overlapping siblings such as art.production.inspect or art.production.attempts, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like inspect, attempts, or list. There is no context about polling patterns, prerequisites for a job to have a status, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (cancel) but doesn't disclose what happens to the operation (e.g., whether it's reversible, whether partial results are discarded, whether it requires special permissions, or what the response contains). For a cancellation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no waste. It front-loads the action and resource. It could be slightly more informative, but it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimal but leaves key questions unanswered: how to obtain operation_id, what happens on success/failure, and whether cancellation is idempotent. With no annotations and no output schema, the description should provide more context for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 doesn't explain what operation_id refers to (e.g., where to obtain it, its format). However, the parameter name is self-explanatory and the schema marks it required, so an agent can likely infer its meaning. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Cancel') and resource ('a running provider operation'), which clearly distinguishes it from sibling tools like art.provider.execute or art.provider.operation. It doesn't explicitly name a sibling it is not, but the purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the operation must be running), nor does it contrast with related tools like art.production.cancel or art.provider.operation. An agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It indicates a simple read operation but does not mention return format, ordering, pagination, history scope, or possible side effects. 'Get' implies read-only behavior but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. It is appropriately sized for a simple tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple and the sole parameter is documented, but there is no output schema and no annotations. The agent is left without any knowledge of what a QA run history entry contains, how results are ordered, or whether any limits apply. A short mention of returned fields or default behavior would make the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents asset_id with 'Filter history by asset ID (omit for all)', giving 100% schema description coverage. The description's 'Optionally filter by asset ID' adds no new meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Get QA run history'. The verb 'Get' and resource are clear, giving an agent a basic understanding of the tool. However, it does not distinguish this from other history-related siblings like art.asset.history or art.memory.get_style_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as art.qa.asset or art.asset.history. The only usage signal is the optional asset_id filter, which is parameter information rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does 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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits: does it delete the canonical version or just switch a pointer? Does it create a new version entry? Does it require permission? The description neither confirms nor denies any of these. The mention of 'optimistic lock' in the schema hints at concurrency safety, but the description itself doesn't explain the consequences or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. The key action and target are front-loaded. It is appropriately concise given that the schema covers parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a rollback operation with four parameters, including an optimistic lock, the description lacks key details such as side effects (does it permanently discard the previous version?), preconditions (must the asset be in a certain state?), and concurrency behavior. There is no output schema, so the description should clarify what the response indicates, but it doesn't. Overall, while it covers the basics, it leaves out critical operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema_description_coverage is 100%, each parameter is described in the schema. However, the description adds only the concept of 'rollback' and 'canonical version', which provides some context but doesn't explain parameter relationships (e.g., why expected_current_version is needed). The schema descriptions are basic, so the description could have elaborated on the optimistic lock mechanism, but it doesn't, so the added value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (rollback) and the resource (canonical version), which is clear. It doesn't explicitly distinguish from other art.asset.* tools like art.asset.promote or art.asset.archive_version, but the verb 'rollback' is specific enough to indicate a revert operation, distinguishing it from promote or update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as art.asset.promote or art.asset.update. The description is a single sentence with no context about scenarios like reverting a bad deployment or precondition like asset must be in a certain state. The sibling tools include 'art.asset.archive_version' and 'art.asset.promote', which could be similar, but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys that this is a read-style search with optional filters, but it does not describe result behavior, default scope when no filters are supplied, pagination, limits, or ordering. No contradiction exists, but meaningful transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the action and resource are front-loaded. This is appropriately concise for a tool whose parameters are fully documented in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-optional-parameter search, the schema covers parameters, but the description omits return-value expectations and does not differentiate from art.memory.get_decision. Since there is no output schema and no annotations, the agent must infer what a successful response looks like and how broad the search can be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: each filter parameter is self-documented with a clear enum or type. The description adds no extra meaning beyond 'optional filters', so the schema correctly carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search') and resource ('art decision records'), and notes that filters are optional. It is distinguishable from the sibling art.memory.get_decision by the search/list framing, though that distinction is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use find_decisions versus get_decision, find_rejections, or other memory search tools. The description only states what the tool does; no context, exclusions, or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but it does not disclose the return format, whether it returns a list or object, any pagination, or side effects. For a simple read tool this is minimal, but still incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no superfluous content. It is appropriately short for a tool with no parameters, though it could perhaps be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description explains its basic function. However, it provides no context about when to use it relative to sibling tools or what kind of history is captured (e.g., across versions, changes, etc.). It is adequate but leaves gaps for an agent deciding between similar memory tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema trivially covers 100% of parameters. The description adds nothing about parameters, but none exist, so the baseline of 4 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a clear resource ('full style evolution history'). It is not a tautology and conveys what the tool does. However, it does not distinguish it from sibling memory tools like get_summary or explain_style, which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are mentioned. Given the large set of sibling tools, an agent would have to infer when to call this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'get' implying a read operation, but it does not disclose any additional behavioral traits like pagination, ordering, limits, or what data is included (e.g., timestamps, outcomes). For a history tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise, a single short sentence that immediately states the action and resource. There is no wasted verbiage, and it is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but not complete. It explains the purpose but lacks any details on output format, ordering, or potential errors. Given its simplicity, it's minimally viable but could easily be improved with a sentence on what data is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the job_id parameter described as 'Production job ID' in the schema. The description does not add any additional meaning or constraints beyond that, but given the high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('get') and a specific resource ('attempt history for a production job'), which is distinct enough from sibling tools that focus on status, inspection, or planning. However, it does not explicitly differentiate itself from other history-related tools like art.memory.get_style_history or art.qa.history, so it's clear but not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as art.production.status or art.production.inspect. The description only states what it does, not the scenarios where it is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior on its own. It does clarify the tool only plans and persists, not executes – useful. But it omits side effects (is it idempotent? does it overwrite?), state changes, auth/rate limits, or what happens on duplicate request_id. For a creation tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence, front-loaded with the key distinction ('plan + persist, does not start execution'). Zero fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, 2 nested objects, and no annotations or output schema, the one-line description leaves important gaps: what a production job is, what 'plan + persist' entails, validation rules, and what success looks like. The sentence conveys scope but not enough context to guide detailed usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with per-field descriptionsches (all fields have descriptions). The tool description adds no behavior beyond identifying that it persists a plan. Baseline 3 is appropriate since the schema itself is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('production job'), and clarifies scope with 'plan + persist, does not start execution'. It's clear what the tool does and meaningfully distinguishes it from execution tools (art.production.start). However, it doesn't explicitly name sibling tools or further qualify the resource type, leaving slight ambiguity about what a 'production job' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it does not start execution, which implies a workflow where the agent would call this to plan/persist and then use art.production.start separately dozen but no explicit when/when-not guidance is given. No exclusions, alternatives, or prerequisites are mentioned, so an agent gets minimal direction on when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives only the basic action 'create'. It does not disclose whether the plan is executable, whether it overwrites existing plans, or any permissions or side effects. For a tool with no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, and the parenthetical adds a useful operational note. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, nested objects, and no output schema, the description is far too sparse. It doesn't explain what a 'production plan' entails, what the output will be, or how to handle potential failures. An agent lacks critical context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all 9 parameters are individually documented. The tool description adds no additional meaning or relationships between parameters, which meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a production plan for an art asset, with a specific verb and resource. It distinguishes from siblings by focusing on 'plan' rather than execution or status, though it doesn't name alternative tools explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(inspect before executing)' implies a workflow sequence but does not explicitly state when to use this tool versus others like art.production.create or art.production.start. No exclusions or alternative conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. 'Get' implies a read operation, but the description does not say what capabilities are returned, whether the provider must be active, or what happens when the provider is invalid. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the core action and object, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter, the description is minimally viable, but it lacks any explanation of the output shape or how this relates to other provider tools. There is no output schema to compensate, so the agent receives only the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents provider_id with 100% coverage, and the description only says 'specific provider,' which adds no meaning beyond the schema. Baseline 3 is appropriate because the schema handles the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and a specific resource ('capabilities of a specific provider'). It is easy to understand the tool's basic function, though it does not explicitly differentiate itself from sibling tools like art.provider.get or art.provider.health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related provider tools such as art.provider.get, art.provider.list, or art.provider.health. It simply restates the action without offering context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Compare' suggests a read-only operation, but the description does not explicitly state that it produces no side effects, whether it requires any particular permissions, or what happens if the versions are identical. It doesn't describe the output format (e.g., a diff, a similarity score, a list of changes). For a tool with no annotation coverage, this is a significant gap, but the verb 'compare' does give some hint of non-mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary verb and resource. There's no unnecessary fluff or repetition of the tool name. It earns a high score for being efficient, though it could arguably include a bit more context within that sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is relatively minimal. It tells you what it does, but doesn't explain what 'compare' means operationally—does it return a diff, a list of changed fields, a boolean? With no output schema and no annotations, an agent might be unsure what to expect. The description is functional but incomplete for a tool that could have nuanced behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are described in the schema: asset_id, version_a, version_b. The description doesn't add additional context beyond what the schema provides, but given full coverage, the baseline is 3. There's no extra info like how the IDs are formatted or how version numbers should be ordered, but the schema handles the core semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Compare two versions of an asset.' It conveys the specific action of comparing versions, which is distinguishable from siblings like art.asset.get, art.asset.history, or art.asset.inspect_version. However, it doesn't explicitly differentiate itself from those siblings in the description text itself, so it doesn't quite reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool name and description imply a usage context: when you need to compare two versions of an asset. But there is no explicit guidance on when to use this versus alternatives like art.asset.history (which might list all versions), art.asset.inspect_version (which might show a single version), or art.asset.current. The description is minimal and leaves the when-to-use distinction to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the action without disclosing side effects (e.g., whether it validates input, overwrites existing records, or returns a status). The description does not clarify behaviors like conditional requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and leaves no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context such as expected output, error handling, or the conditional requirements implied by the schema (e.g., asset_id required for type=asset). An agent would need to infer these from the schema, making the description insufficient on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for each parameter, including constraints and enums. The tool description adds no further semantic clarification about relationships between parameters (e.g., asset_id vs. description depending on type). It relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new rejection record') and the resource ('art memory'), making it distinct from sibling tools like 'find_rejections' or 'add_decision'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as when a rejection is needed after a QA failure or how it complements the 'find_rejections' 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?
No annotations are provided, so the description carries the full disclosure burden. The verb 'Get' implies a read-only, side-effect-free retrieval, which is the core behavioral trait for a getter, but the description says nothing about what happens for unknown artifact_ids, error conditions, or the returned detail structure. For a single-parameter read tool this is acceptable but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no wasted words: 'Get details of a generated artifact.' It is appropriately sized for a one-parameter read tool and front-loads the core action, though it is more minimal than rich.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (1 parameter, no annotations, no output schema) the description covers the basic operation, but the meaning of 'details' is undefined and the tool can still be confusing among siblings. The lack of output schema means the description could have explained what the agent receives, so overall completeness is only partial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema alone contributes almost nothing beyond the parameter name and type. The phrase 'generated artifact' adds real meaning by clarifying that artifact_id refers to a produced artifact rather than an asset or provider instance, though it does not explain ID format, provenance, or how the ID relates to outputs of art.provider.execute or art.provider.operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'get details' of a 'generated artifact,' so an agent can tell what kind of operation this is. However, it does not explicitly distinguish itself from similar siblings like art.asset.get, art.provider.get, or art.asset.inspect_version — the word 'generated' hints at the difference but leaves the contrast unspoken.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many look-alike getters in the family (art.asset.get, art.provider.get, art.asset.inspect_version). With over 70 sibling tools and no exclusions or alternative routing, an agent must guess the intended use case from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implicitly indicates a read-only operation ('Returns'), but does not state side effects, permissions, rate limits, or any hidden behavior. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded with the core action and result, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with zero parameters, the description covers the essential purpose. However, it does not explain what constitutes the 'active style' (e.g., how it is set or retrieved), and lacks any output format indication. Given the minimal complexity, the description is mostly sufficient, but a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (trivially), so there is nothing to explain. Per the baseline for 0-param tools, a 4 is appropriate because the description correctly omits parameter details that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns the color palette') and the subject ('the active style'). It is a specific verb+resource. However, it does not differentiate from sibling tools like art.get_style or art.get_style_rules, which could also be relevant in style contexts, so it is not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or situations where another tool (e.g., art.get_style) would be more appropriate. With zero parameters, an agent may still call it without knowing if it is the right choice.
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?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a read ('Returns'), and hints at a dependency on an 'active style' being set. However, it does not explain prerequisites (how the active style gets established), error behavior when a category has no rules, or what 'active' means in context. Adequate for a simple getter but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of zero redundancy that front-loads the verb ('Returns') before the resource. Every word earns its place; nothing to cut and nothing missing in terms of phrasing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, enum-constrained, no output schema, no nesting), so the bar is low. The description states the return semantics adequately, but leaves the 'active style' dependency unexplained and does not clarify what happens for an empty category. For a low-complexity tool this is close to adequate, with only the state-dependency gap holding it back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the schema already documents the single 'category' parameter with its enum values and an inline description. The tool description adds no parameter-level information beyond what the schema provides. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Returns the rules for a specific category of the active style.' It identifies the operation (retrieve) and the resource (style rules by category). It does not explicitly differentiate itself from siblings like art.get_style (which returns the whole style) or art.qa.list_rules, so it doesn't fully earn a 5, but the purpose is 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/5Does 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. There is no 'use when...', no exclusions, and no mention that art.get_style or art.qa.list_rules might serve different purposes. The description relies entirely on the reader to infer usage from the term 'returns'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'List all production job IDs' without mentioning pagination, ordering, rate limits, authentication, or whether it's a read-only operation. This minimal disclosure is insufficient for a tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words. It's highly concise and front-loaded, stating the core action immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description adequately conveys the action and result (production job IDs). It could mention whether all IDs are returned at once or paginated, but given the tool's simplicity, the current description is mostly complete. The lack of any usage context or limitation notes is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema description coverage is effectively 100%. Per the calibration rule, a baseline of 4 applies. The description adds no parameter information, but none is needed since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'List all production job IDs.' It's specific and unambiguous. However, it doesn't distinguish itself from similar sibling tools like art.production.status or art.production.attempts, which could also return lists of jobs. The lacking differentiation prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. The description only says what it does, not when an agent should choose it over other production-related tools. There's no mention of scenarios 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?
With no annotations present, the description carries the full behavioral burden. The verb 'Check' reasonably implies a read-only, non-mutating operation, but the description does not explicitly state the absence of side effects, any required permissions, or what constitutes 'health status.' It gives some behavioral signal but leaves important details unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and target. There is no redundant information or filler, and the phrasing is direct and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, making the description minimally viable. However, it omits what the health check returns, how 'health' is defined, error behavior, and the relationship to sibling provider tools, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, provider_id, is described as 'Provider ID' in the schema. The description itself adds no additional meaning or usage details for the parameter, so the baseline score of 3 applies since the schema already documents it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a particular resource ('health status of a specific provider'), making the core function clear. It does not explicitly distinguish itself from siblings like art.provider.get or art.provider.capabilities, but 'health status' is a distinct concern, so the meaning is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as art.provider.get, art.provider.capabilities, or art.provider.list. There are no usage conditions, exclusions, or mention of alternatives, leaving an agent to infer the appropriate context solely from the name.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description states it's a 'Get' operation, implying read-only, but does not disclose whether it returns full record details, partial information, or if it requires special permissions. For a simple read-by-ID tool, this is adequate but sparse, missing any mention of error behavior or returned data shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is appropriately concise and front-loaded with the core action. It does its job without fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, no output schema, and no annotations, the description is reasonably complete for a simple fetch-by-ID tool. However, it lacks information about what the response contains or whether the tool is restricted to certain approval states, which could matter for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the single parameter, describing 'approval_id' as 'Approval record ID'. The description adds minimal value beyond this, but since coverage is high, the baseline is 3. No additional semantic detail about the ID format (e.g., UUID, numeric) is provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an approval record by ID' uses a specific verb ('Get') and specifies the resource ('approval record') and the lookup key ('by ID'). It clearly distinguishes this from other asset approval tools like art.asset.approve or art.asset.approval.request, which perform different actions. It doesn't explicitly contrast with siblings, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you have an approval record ID and need its details. It doesn't provide explicit context on when to prefer this over art.asset.approve or art.qa.history, but the name and description make it reasonably clear this is a read-only inspection tool. No exclusions or alternatives are named.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the core effect ('remove from active use') but does not mention reversibility, side effects, required permissions, or what happens to asset versions. This is adequate for a simple operation but leaves meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that clearly defines the operation and its effect. There is no fluff, and the parenthetical adds necessary clarification without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description covers the essential invocation details. It lacks usage guidance and behavioral nuance, but the operation is simple enough that an agent can call it with just the id and a reasonable understanding of the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so the schema already documents its meaning. The description's 'Asset ID to archive' adds no new semantic detail beyond the schema, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Archive') and resource ('asset'), and clarifies the meaning with 'remove from active use.' It is clear but does not explicitly distinguish itself from siblings like art.asset.archive_version or art.asset.deprecate, though the parenthetical helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as art.asset.archive_version, art.asset.deprecate, or art.asset.update. The description only states what the tool does, leaving the agent to infer selection criteria.
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?
With no annotations provided, the description carries the full burden. 'Get details' clearly indicates a read-only operation with no destructive side effects, which is transparent. However, it does not disclose any additional behavior such as existence requirements, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to the core meaning, making it appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two required parameters, no output schema), the description and schema together are sufficient to invoke the tool correctly. It lacks explicit return-value details and sibling differentiation, which prevents a perfect score, but the core invocation path is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'asset_id' and 'version' described in the input schema. The description adds no further meaning to these parameters beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'Get details of a specific asset version,' which clearly states the operation. It does not explicitly differentiate from sibling tools like art.asset.get or art.asset.current, relying only on the word 'version' for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as art.asset.get, art.asset.current, or art.asset.history. No conditions, exclusions, or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure. It states the primary effect (approving and moving to completed) but lacks any mention of side effects, failure conditions, reversibility, or authorization requirements. For a mutation tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It front-loads the action and outcome, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not mention what the tool returns, what happens if the job is not in an 'awaiting approval' state, or potential errors. The agent may be left uncertain about the behavior in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter job_id, which is described as 'Production job ID'. The tool description does not add any extra semantic detail about this parameter, so the baseline of 3 is appropriate since the schema already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'approve', the resource 'production job', and the outcome 'moving it to completed'. It is specific enough to distinguish from asset approval (art.asset.approve) by specifying 'production job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a production job is 'awaiting approval', which is a context cue. However, it does not explicitly mention alternatives like art.production.start or art.asset.approve, nor does it state when not to use this tool. Thus, usage is only implied, not fully guided.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose it returns a pass/fail verdict with full report, but does not mention side effects (if any), whether it mutates state, or any required permissions. However, the tool name and description suggest a non-destructive evaluation, and the description adds value by stating the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It front-loads the action and the outcome. It is concise and structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 2 parameters and no output schema. Given the complexity, the description is fairly complete but could mention the effect of the profile parameter or the nature of the report. However, since schema already covers parameter details, the description is adequate for a basic gate check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (profile and asset_id) are already described. The description does not add beyond schema. The profile parameter has enum with default, which is already clear from schema. The description adds no additional semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it runs a QA gate check on an asset and returns a pass/fail verdict with a full report. It uses specific verb (run) and resource (asset QA gate). While it could differentiate from siblings like art.qa.asset, art.qa.batch, or art.qa.explain_failure, the description is sufficiently specific about the outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (run a QA gate check) but does not explicitly state when to use this tool versus alternatives like art.qa.asset, art.qa.batch, or art.validate_style. It does not mention exclusions or prerequisites. The appropriate context is implied but not explicitly guided.
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?
With no annotations, the description carries the full burden. 'Validates... and returns errors found' implies a non-mutating operation, but it never explicitly states there are no side effects, doesn't describe the shape of a successful return, and doesn't reveal whether all errors are collected or it fails fast.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. Each phrase earns its place: 'validates' states the action, 'active style configuration' narrows the scope, and 'returns any errors found' tells the agent what to expect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool the bar is low, but a validation tool would benefit from stating what 'valid' means, whether the operation is read-only, and what the caller should do with the errors. The word 'active' also raises an unanswered question — is there state involved that the agent should know about?
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so there is nothing material for the description to add. The baseline of 4 applies here — nothing is missing since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb (validates), a specific resource (active style configuration), and the return type (errors). However, it doesn't differentiate from siblings like art.get_style, art.qa.rule, or art.get_style_rules — an agent must infer why validate_style is the right choice over those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to choose this tool over its many siblings. No when-to-use context, no exclusionary statements (e.g., 'use art.qa.gate for CI checks'), and no mention of prerequisites or ordering (e.g., 'validates the config as loaded by art.get_style').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state whether it returns the anchor object, whether it errors on unknown IDs, or if it has any side effects. Minimal behavioral detail is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states exactly what the tool does with zero wasted words. It is concise enough for agents to quickly parse and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, single-parameter getter, and the schema makes the parameter fully clear. However, without annotations or an output schema, the description leaves gaps around expected return values and failure behavior. Adequate for a straightforward retrieval, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the 'id' parameter with 100% coverage, including an example, so the description needn't restate it. The description adds only the resource type ('style anchor') to the parameter context, which is marginal—the tool name already conveys that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a specific resource ('style anchor'), and a specific lookup criterion ('by its ID'). This clearly distinguishes the tool from sibling memory operations such as find_anchors (searching) and add_anchor (creating).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its ID' implies the appropriate usage scenario—when you already know an anchor's ID—but it does not explicitly instruct when to prefer this tool over alternatives like find_anchors or get_reference. Usage is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get', implying a read operation, but does not state potential outcomes such as 'returns null if not found' or error behavior. There is no information about side effects or return structure. The description adds minimal value beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the action and target. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial getter, the description covers the essential input (id) and implies a return of the record. However, it omits details like return format, not-found handling, or whether the record is returned in full. Since there is no output schema, these gaps reduce completeness. The description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the id parameter with an example format. The description merely repeats 'by its ID', adding no new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('art decision record') with a clear key ('by its ID'). It is unambiguous and naturally distinct from sibling art.memory.find_decisions, which implies searching/filtering. The purpose is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an ID is known, but does not explicitly mention when not to use it or contrast it with find_decisions. It provides no exclusions or alternatives. For a simple getter, this is acceptable but leaves the agent to infer the differentiation from naming conventions.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It indicates a read operation ('Get') but does not mention any potential side effects, authorization requirements, rate limits, or error conditions. For a simple get it is adequate, but it adds no extra context beyond the verb and resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys the entire purpose with no wasted words. The information is front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id operation with one parameter and no output schema, the description is structurally sufficient. However, it lacks explanation of what a rejection record is, when one would use this instead of find_rejections, and what happens if the ID does not exist. Given the broader context of the toolset and the presence of a sibling search tool, more context would help an agent decide when to call this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the 'id' parameter is already described in the schema. The tool description adds no additional meaning or usage details for the parameter, so it earns the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (Get) and resource (rejection record) with the specific method of lookup (by ID). It is immediately distinguishable from the sibling art.memory.find_rejections, which implies a search/filter operation. However, it does not explicitly name the sibling as the alternative, so it misses the full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you already have a rejection ID, but it does not provide explicit guidance on when to prefer this over find_rejections or any other access pattern. There is no statement of when not to use it or mention of prerequisites. The context is clear enough but lacks exclusions or alternative routing.
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?
No annotations are provided, so the description carries the behavioral burden. 'Get detailed metadata' reasonably implies a read-only, non-mutating operation, but the description does not explicitly confirm side-effect-free behavior, permission requirements, or error behavior for unknown provider IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to the core meaning, and there is no repetition of the tool name or parameter schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one fully documented parameter, so the description is roughly adequate for selecting and invoking it. However, there is no output schema and the description does not clarify what 'detailed metadata' contains, leaving the agent without a clear expectation of the return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single required parameter provider_id is documented in the schema as 'Provider ID'. The description adds little beyond the schema, but given the high schema coverage, this meets the baseline without requiring additional compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Get detailed metadata for a specific provider') and signals that the operation is scoped to one provider rather than a list. It is clear enough to distinguish from provider.list, but it doesn't explicitly differentiate from similar read-style siblings like provider.capabilities or provider.health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific provider' implies the tool is used when a particular provider_id is already known, which gives useful context. However, it provides no explicit when-to-use/when-not-to-use guidance and names no alternative tools for cases like listing all providers or checking health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden. It mentions the return of a report but does not disclose side effects, failure modes, or whether it is read-only. Given the batch nature, more transparency about error handling would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant information. It clearly conveys the core action and expected outcome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks context on what 'QA checks' entail or how to interpret the batch report. It does not explain the relationship to sibling tools, but the name and schema provide some clarity. The lack of an output schema means more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptive names and schema descriptions covering 100% of the parameters. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs QA checks on multiple assets and returns a batch report with individual results. This distinguishes it from single-asset QA tools like art.qa.asset and aligns with the 'batch' naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multiple assets but does not explicitly compare with alternatives or state when to prefer this over single-asset QA. No conditions or exclusions 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?
No annotations are provided, so the description carries the full burden. It states what is returned (config, style, rules, palette) but does not disclose details like the format, size, or whether it might be expensive to call. Since it returns 'full' context, there might be performance implications, but the description doesn't mention them. It also doesn't state any authentication or side effects, but as a read-only aggregate, that might be inferred. The description is typical but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It immediately states what the tool returns and lists the components. It is efficient, though it could be slightly more structured, but it does its job without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is fairly complete. It clearly states what the agent will receive. The missing piece is guidance on when to use it versus the specific getters, but the core functionality is well described. Given the sibling richness, a bit more context would push it to 5, but 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (vacuously). The description correctly indicates no inputs are needed; it simply returns the context. Since there are no parameters, the description adds value by stating that no arguments are required, which is clear from the schema. A baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: returns the full art context, listing four specific components (project config, active style definition, all rule categories, and palette). The verb 'returns' is specific and the resource is clearly named. However, it doesn't explicitly distinguish itself from siblings like art.get_style, art.get_palette, or art.get_style_rules, which are likely subsets of this context. The description implies it is a broader aggregate but doesn't name them directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need the full art context in one call, but it provides no explicit guidance on when to use this versus more focused sibling tools like art.get_style or art.get_palette. There is no statement of alternatives or exclusions. An agent can infer it is a one-stop-shop, but the description doesn't explicitly say 'use this when you need multiple components at once' or 'for a single component use the specific getter.'
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?
With no annotations present, the description carries the behavioral burden. It states that this is a retrieval operation ('Returns'), but does not disclose other behavioral details such as what happens when an unknown style_id is used, whether the active style can change, or what the returned definition contains. The description is accurate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with what the tool does, and immediately explains how to modify the default behavior. Every phrase contributes meaning: 'Returns the active style definition' sets the base, and 'Optionally specify style_id and version' covers the parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two optional, fully documented parameters, the description is largely complete. It lacks an explicit return format or mention of errors, but given the absence of an output schema and the low complexity, the current description provides enough context for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds a small amount of context about using style_id and version together, but it mostly restates the optionality and lookup semantics that the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Returns') and resource ('style definition'), and distinguishes between the active style and a specific style when style_id/version are provided. It does not explicitly differentiate from sibling tools such as art.get_style_rules, but the resource and behavior are immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful operational guidance: omit style_id for the active style, or supply style_id and optionally version for a specific style. However, it does not explicitly state when to prefer this tool over alternatives like art.get_style_rules or art.validate_style, so usage guidance remains implied rather than explicit.
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?
No annotations are provided, so the description carries the full burden. It discloses that it lists all registered providers and returns metadata, which explains the read-only nature. However, it does not mention potential large response sizes, pagination, or any error behavior. It's transparent about the basic operation but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and result. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing operation, the description is complete: it states the action and what is returned. There is no output schema, but the return is implied to be a list of providers with metadata. It could mention pagination or sorting, but for a basic list, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema is empty), so schema coverage is effectively 100%. The description adds no parameter-level meaning, which is fine because there are none. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('registered art providers'), and clarifies the output ('with their metadata'). It clearly distinguishes from siblings like art.provider.get (which retrieves a single provider) and art.provider.capabilities (which gets capabilities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It states it lists all providers, but does not mention when to prefer it over art.provider.get or art.provider.capabilities. No exclusions or conditions are given.
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?
With no annotations, the description carries the transparency burden. It signals a read-only diagnostic operation ('Explain...') and discloses the return contents ('rule definition, issue details, and context'). It does not mention permissions, error behavior, or whether any state is recorded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the purpose and immediately state the return payload. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with no output schema, the description gives the needed invocation context and lists what is returned. It could be more specific about the shape of 'context' or error conditions, but it is adequate for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains rule_id and asset_id clearly. The description adds no additional meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Explain') and names the resource ('a specific QA rule failed for an asset'), so an agent can tell this is a diagnostic tool for individual failures. It does not explicitly call out sibling tools like art.qa.rule or art.qa.history, but the failure-explanation scope is distinct enough to avoid confusion with list/get/history 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Explain why a specific QA rule failed for an asset' implies the intended use case: after a rule failure has been identified, retrieve the explanation. It does not, however, state when not to use it or point to alternatives such as art.qa.history or art.qa.rule.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does state 'Returns the full asset record,' which hints at read-only retrieval, but it does not specify error behavior (e.g., not-found handling), prerequisites (asset must exist), or any side effects. Since 'Get' implies a read, it's minimally transparent but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The key action and return type are front-loaded. Every word adds value, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is adequate. It states what it does and what it returns. However, it lacks guidance on error conditions, whether the asset must be registered, and how to react to missing IDs. Given the low complexityaging, the gaps are minor but present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter (id) and provides an example value. The description adds no new semantics beyond 'by its ID,' which is redundant with the schema. With 100% schema coverage, baseline is 3; the description doesn't add meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('registered asset'), and specifies the lookup key ('by its ID'). It also states the return ('full asset record'). It clearly distinguishes from siblings like art.asset.find (search-oriented) and art.asset.exists (existence check) without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have an ID and want the full record) but does not explicitly state when to prefer this over art.asset.find, art.asset.exists, or art.asset.current. No exclusions or alternative routing provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. 'Rebuild' implies a destructive overwrite of the existing index and a potentially expensive scan of asset files, but none of these side effects, performance implications, or error states are mentioned. The description adds some context about the data source but does not cover the operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that states the operation and its input source with no redundant details. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is mostly adequate, but it lacks behavioral warnings and usage context. Given that the tool is a mutation-like operation with no annotations, an agent might benefit from knowing when to use it and what consequences to expect. Still, the core action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to clarify parameter meanings. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'rebuild' with the resource 'asset registry index' and identifies the source as 'all registered asset files'. This clearly distinguishes it from asset query/registration tools like art.asset.get or art.asset.register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to invoke this tool versus alternatives, nor any mention of prerequisites or conditions. While the action is clear, an agent is left to infer when a rebuild is appropriate, such as after bulk registration or index corruption. No alternative or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'resume' but does not explain the effects, prerequisites (e.g., whether the job must be in a specific state), side effects, or potential outcomes. It doesn't disclose what happens if the job is not failed/interrupted, nor does it mention any auth or resource requirements. This is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no fluff or redundancy. Every word adds value in defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is minimally adequate. It covers the trigger condition ('failed or interrupted') but omits behavioral details like state transitions, error handling, or idempotency. While not incomplete enough to be unusable, it leaves agents guessing about post-call behavior and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (job_id, 'Production job ID') with 100% coverage. The description adds no additional parameter-level information, so it meets the baseline of 3 for schema-covered parameters. No extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resume') with a clear resource ('production job') and scope ('failed or interrupted'). It clearly distinguishes from siblings like 'start' (new jobs) or 'cancel' (stopping jobs). No ambiguity in intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the condition for use ('failed or interrupted'), which provides clear usage context. While it doesn't mention alternatives or exclusions (e.g., don't use on completed jobs), the condition is sufficiently clear to differentiate from related tools. The absence of explicit alternatives is a minor gap.
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?
With no annotations provided, the description carries the burden of explaining behavior. It clearly discloses that the tool produces an explanation covering rules, anchors, decisions, avoidance guidance, and history, while 'Explain' reasonably implies a read-only, non-destructive operation. It does not detail output format or error behavior, but for a simple explanatory tool the disclosed content is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary action and resource first, then uses a compact colon-delimited list to enumerate output categories. There is no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with no required parameters, no output schema, and no annotations, the description adequately conveys the purpose and the scope of the explanation. It could be more complete by mentioning output format or how this differs from related retrieval tools, but the schema covers parameter defaults and the description covers output content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both style_id and style_version already documented as defaulting to latest. The description adds only the notion of 'current' style, which slightly enriches the mental model but does not add substantive parameter meaning beyond what the schema provides. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Explain'), names the resource ('style'), and enumerates the content of the explanation: core rules, canonical anchors, important decisions, things to avoid, and history. This is more specific than a tautology, though it does not explicitly differentiate itself from siblings like art.get_style, art.get_style_rules, or art.memory.get_style_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current or specified style' implies this tool can explain either a current/default style or one identified by parameters, and the parameter defaults are documented. However, it provides no explicit guidance about when to choose explain_style over sibling tools, no exclusions, and no notes about prerequisites or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only list operation and discloses that definitions are included, but it does not mention pagination, ordering, or any limitations. For a simple list, this is adequate but minimal; no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. The action and resource are front-loaded, making it easily scannable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is nearly complete. It states the action and the returned content (rules and definitions). It does not explain return format or any filters, but given the simplicity and sibling context, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema coverage is 100% (vacuously). Per the rubric, this yields a baseline of 4. The description adds nothing about parameters, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a resource ('all available QA rules'), and the content ('with their definitions'). It distinguishes itself from sibling QA tools like art.qa.rule (likely for retrieving a single rule) and art.qa.history (for past runs). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as art.qa.rule or art.qa.explain_failure. It does not mention what scenarios warrant listing all rules, nor does it exclude cases where a specific rule is needed. The agent is left to infer context.
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?
With no annotations provided at all, the description carries the full burden of behavioral disclosure. The verb 'Get' clearly signals a read-only operation and 'full definition' hints at return content, but there's no disclosure of error behavior for unknown IDs, response format, or performance characteristics. For a simple getter, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence that front-loads the verb and resource while wasting zero tokens. The qualifier 'full' adds meaningful scoping that 'definition' alone would lack, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity — one parameter, no output schema, no nested objects, 100% schema coverage — there is very little left undisclosed. 'Full definition' suggests return richness, and the sibling art.qa.list_rules handles the multi-rule case. Minor remaining gaps are low-stakes for a getter: no mention of not-found behavior or whether the output is compatible with an enum or known set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the single rule_id parameter, including a realistic example ('canvas.dimensions'). The description's 'by its ID' merely echoes the schema and adds no new semantic information, which lands it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('Get'), a specific resource ('full definition of a specific QA rule'), and a precise selection mechanism ('by its ID'). The deliberate use of 'specific' and 'by its ID' cleanly differentiates it from the natural sibling art.qa.list_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies this is used when a rule ID is already known — presumably from art.qa.list_rules — but the description never explicitly states when to use it versus a sibling tool like art.qa.batch. Usage is implied rather than directed.
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?
With no annotations, the description carries the burden of behavior disclosure. The 'search and filter' wording implies a read-only operation and the optionality clarifies the empty-query behavior, but it does not mention result shape, pagination, ordering, or any access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action first and the critical optionality note second. No filler or redundant restatement of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only filter tool with a fully documented schema, the description covers the essential call semantics. It would be more complete with a note on return format or default limits, but nothing blocks correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the cross-parameter insight that all filters are optional and an empty query lists everything, which is not immediately derivable from the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Search and filter registered assets.' It doesn't explicitly compare itself to sibling tools like art.asset.get or art.asset.current, so it loses the sibling-differentiation point, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'All parameters are optional; omit all to return every asset' gives clear operational guidance and tells the agent when an unfiltered listing is appropriate. It does not name alternatives or exclusions, so it falls short of a 5.
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?
With no annotations provided, the description carries the full behavioral burden. 'Check whether... exists' conveys a read-only, side-effect-free predicate operation rather than a mutation of registry data. For such a simple existence check, this level of behavioral disclosure is sufficiently clear, even though it does not spell out response format or edge cases like 'returns false for missing ID.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words. The operation is front-loaded, the resource is stetted immediately after, and every word contributes to understanding. This is concise to be model-parseable in a tool list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, side-effect-free existence predicate, the description is essentially complete: the parameter is fully documented by schema, and 'check whether it exists' naturally implies a boolean/presence outcome. An explicit 'returns true if the asset exists, false otherwise' would be marginally more precise given there is no output schema, but it is not missing for high-confidence invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'id' as 'Asset ID to check.' The description merely refers to 'the given ID' and adds no extra format, validation, or usage details beyond the schema, meaning it meets the baseline but does not improve on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Check whether') and resource ('an asset with the given ID exists in the registry'), which is unambiguous about what the tool does. It also differentiates from sibling asset tools such as art.asset.get, art.asset.find, and art.asset.current by framing this as a pure existence test rather than a retrieval, search, or state-changing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the right choice when an agent only needs to verify whether an asset exists, but it never explicitly says when to prefer this over art.asset.get or art.asset.find. No alternatives, exclusions, or contextual conditions are provided, so the agent must infer usage from the verb 'exists' and the sibling tool names.
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?
No annotations are provided, so the description carries the full burden. It mentions validation of schema, style, source, and relationships, but does not clearly state the outcome (e.g., creation success) or any side effects or failure behavior. This leaves some ambiguity about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and then a concise list of validation areas. No redundant or vague wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, nested objects) and absence of an output schema, the description provides adequate context for the tool's function. It does not mention return values or explicit preconditions (e.g., uniqueness of ID), but these are not critical for a create operation and the description is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all parameters (100% coverage), so the tool description adds minimal extra semantic value. It does highlight that validation applies to certain fields, but this is already implied by the schema's required fields and enums. The description does not clarify any nuanced parameter interactions beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Register' and the resource 'new asset in the registry', distinguishing it from other asset operations like update or archive. It also hints at the validation scope, making the tool's primary function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating new assets, which is sufficient given the presence of related sibling tools like art.asset.update. However, it does not explicitly mention when not to use it or provide alternatives, so it falls slightly short of fully explicit 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?
No annotations are provided, so the description carries the full burden. 'Run QA checks' and 'returns a full QA report' clearly indicate a read-only verification behavior that produces a report. It does not explicitly address authorization, mutation, or edge cases like missing assets, but the described operation is evidently non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff: the first states the action and resource, the second states the exact output. It is front-loaded and every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully covers the two input parameters, and the description communicates the return value shape. Since no output schema is provided, stating 'full QA report with all rule results' is a useful minimum. A brief note on what 'full' entails or how 'profile' affects the report would be beneficial but not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'asset_id' and 'profile' have descriptions and the enum values are fully listed. The description adds no extra parameter semantics beyond calling out the single-asset scope, so it is appropriately average.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb ('Run QA checks') and a specific resource ('a single asset'), then specifies the result ('full QA report with all rule results'). This naturally distinguishes the tool from siblings like 'art.qa.batch' (many assets), 'art.qa.rule' (a single rule), and 'art.qa.gate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on a single asset' provides a clear usage context: choose this tool when there is exactly one asset to QA. It does not explicitly spell out alternatives or when to use other QA tools instead, but the scope is clear enough for reasonable selection.
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?
With no annotations, the description carries the full burden of behavior. It correctly describes the returned counts and implies a read operation, but does not explicitly state it is side-effect free, nor does it mention any error conditions or edge cases (e.g., empty memory). It is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the action ('Get a summary') and lists the key return fields. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only summary tool with a clearly enumerated output, the description is complete. An agent needs no further details to invoke it correctly: no inputs, no schema complexity, and the output is specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on return payload rather than parameters, and schema coverage is trivially 100% with an empty properties object. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get) and resource (summary of the art memory) and enumerates the specific content (anchor count, active decisions, active rejections, total references). This defines a distinct purpose compared to the many granular sibling tools like get_anchor or find_references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as an overview, contrasting with the more specific lookup tools in the sibling list. However, it does not explicitly state when to prefer this over alternatives or provide exclusions, though the word 'summary' effectively signals its role.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Cuvara/game-art-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server