rubrkit

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that new versions are created per changed file, which is a key behavioral trait. However, it does not disclose potential destructiveness, error conditions, or side effects beyond version creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence plus a requirement, with no wasted words. The main action is front-loaded and the prerequisite follows cleanly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that modifies bundle files, the description is too minimal. It lacks details on side effects, error handling, output (beyond 'new version'), and whether existing versions are affected. Given no output schema and no annotations, more context is needed for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no meaning to the two UUID parameters ('auditRunId', 'artifactBundleId') beyond their names. The schema's property names are somewhat self-explanatory, but the description should clarify what each ID refers to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Apply a completed audit's AI rewrite'), the resource ('bundle files'), and the outcome ('a new version per changed file'). It is specific and distinguishes from sibling tools like rubrkit_start_audit or rubrkit_read_audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a prerequisite ('Requires audits:run for API keys') but lacks guidance on when to use this tool vs alternatives, or any when-not-to-use conditions. It gives minimal context about its appropriate usage scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It states the job is async but does not explain what triggers the conversion, how to track progress, or any side effects. The permission requirement is noted, but details on rate limits, cancellation, or data retention are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short (two sentences) but omits essential information. It is not verbose, but brevity comes at the cost of completeness. The front-loading is fine.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 7 parameters with no descriptions, no output schema, and no annotations, the description is severely incomplete. It does not cover return values, job lifecycle, or how to map parameters to inputs. A complex async job requires far more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description does not explain any of the 7 parameters (e.g., modelTier, outputPath, reasoningEffort). The agent must rely solely on the schema, which lacks descriptions, making it impossible to understand how to correctly fill in parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Start' and the resource 'rubr_flow conversion job'. It also mentions the required permission, distinguishing it from read/list operations like rubrkit_list_rubr_flow_conversions and rubrkit_read_rubr_flow_conversion, though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives such as rubrkit_poll_job for checking job status or rubrkit_list_rubr_flow_conversions for listing existing conversions. No 'when-not' or alternative tools mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions the required permission, which is a behavioral trait. However, no annotations exist, and the description does not disclose other important behaviors such as idempotency, effects of creation, or error conditions. It lacks sufficient detail 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (two sentences), but this conciseness comes at the expense of missing critical information about parameters and behavior. It is under-specified for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has four parameters, no output schema, and no annotations, the description is extremely incomplete. It fails to provide context about the return value, parameter meanings, or usage examples, making it inadequate for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description must explain parameters. It does not explain any of the four parameters (name, settings, description, customRubric) beyond what is in the schema. The agent has no guidance on how to use them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Create an artifact bundle' and specifies the API endpoint and required permission. This verb-resource combination is specific and distinguishes from sibling tools like delete, list, and read.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides the required permission 'artifact_bundles:write', which helps agents know when they can use the tool. However, it does not explicitly state when not to use it or suggest alternatives, though the sibling tools have distinct purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses soft delete (archiving) and the ability to restore or permanently delete later, but could elaborate on whether the bundle is removed from listing or other 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words, efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool with no output schema, the description covers purpose, behavior, and auth requirements completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds context by mentioning the endpoint path that uses the parameter, clarifying its role as the bundle identifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Archive an artifact bundle (soft delete)' with the HTTP method and endpoint, distinguishing it from the sibling hard delete tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes the soft delete behavior and state transition, and specifies required auth scope 'artifact_bundles:write', with implied alternative of hard delete from sibling name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It states the job is async and export storage is enabled by default, but omits critical behavioral details like side effects, how to check job status, or whether the operation is idempotent. This is insufficient for an async job tool with 11 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler, front-loading the key action and requirement. However, it could be more concise if it integrated parameter guidance, but as is, it earns a 4 for efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given high complexity (11 params, async job, no output schema), the description is far from complete. It does not explain the job output, how to poll for results, or the purpose of the many parameters. The flow implied by sibling tools (e.g., rubrkit_poll_job) is not mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description does not explain any of the 11 parameters. The only parameter hint is 'export storage enabled by default' implicitly referencing includeExport, but no details on evalRunId, auditRunId, sourceFileId, etc. The agent has no guidance on how to fill these parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool starts an async proof report job with export storage enabled by default. It uses a specific verb ('start') and identifies the resource ('proof report job'), which distinguishes it from sibling read tools like rubrkit_read_proof_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite ('Requires evals:run for API keys') but provides no guidance on when to use this tool vs alternatives such as rubrkit_start_audit or rubrkit_run_evals. No explicit when-not-to-use or alternative tool names are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully covers behavioral aspects: irreversibility, the deletion of all associated files/versions/run history, the requirement that bundle be archived, and needed API key permission. This provides good transparency for a destructive action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each adding essential information: action scope, irreversibility/condition, and permission requirement. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool with no output schema or annotations, the description covers all necessary aspects: purpose, prerequisites, permission, and endpoint. It does not describe return value, but that is acceptable given the tool's nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains that the single parameter (artifactBundleId) is the bundle ID used in the DELETE endpoint URL, and it clarifies that the bundle must be archived. This adds meaning beyond the schema's basic type and format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it permanently deletes an archived artifact bundle including all files, versions, and run history. It distinguishes itself from the soft delete sibling tool (rubrkit_delete_artifact_bundle) by emphasizing irreversibility and the 'archived' condition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description specifies that the tool only works on archived bundles and requires write permissions. It implies when to use this hard delete over the soft delete variant, though it does not explicitly name the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the required permission (artifact_bundles:read for API keys), which is helpful for authorization. However, it lacks details on pagination, rate limits, or side effects. The endpoint URL is provided, adding some transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence states the purpose, and the second adds a permission note. It is front-loaded and efficient, though it could include brief parameter explanations without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and two parameters with no description, the description is incomplete. It does not explain what the list returns, how pagination works, or filter options (status enum). Critical context for a list operation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description does not describe any of the two parameters (limit, status) or their effects. It provides no additional meaning beyond the schema, failing to compensate for the lack of parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List artifact bundles' which is a specific verb and resource, and it provides the API endpoint. However, it does not explicitly differentiate itself from other list tools among siblings, though the resource name is unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a permission requirement but provides no guidance on when to use this tool versus alternatives like rubrkit_read_artifact_bundle or other list tools. No when-not or alternative recommendations are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds the permission requirement, which is helpful given no annotations. However, it does not disclose whether the operation is read-only, idempotent, or other behavioral traits like pagination defaults.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy. Purpose and permission are stated upfront. Concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and many sibling tools, the description lacks context about return values, how version events differ from file version events, and pagination behavior. Incomplete for a 2-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain any parameters. The meaning of artifactBundleId and limit is left entirely to the schema, which lacks descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists 'bundle-level version events', distinguishing it from sibling tools that list bundles or files. However, 'version events' could be more explicit about what is returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_artifact_bundles or list_file_versions. Only a permission requirement is mentioned, but not usage context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only indicates a read operation implicitly via 'List' and mentions auth requirements, but fails to disclose pagination behavior, default limits, what fields are returned, or any side effects. For a read operation, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, no redundant phrasing. However, it lacks structure (e.g., bullet points or separate sections) and could benefit from a note about pagination or the limit parameter. Still, every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and a simple list operation, the description is incomplete. It omits details about the response format, pagination (even though a limit parameter exists), ordering, and whether the tool returns file metadata or paths. A more complete description would help the agent understand what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 2 parameters (artifactBundleId, limit) with 0% schema description coverage, yet the description does not explain either parameter. It does not clarify that artifactBundleId is a UUID or what the limit parameter controls, leaving the agent without additional context beyond the schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'List files in an artifact bundle,' which clearly identifies the verb (list) and resource (files in a bundle). It is distinct from sibling tools like rubrkit_list_artifact_bundles and rubrkit_list_artifact_bundle_versions, which serve different purposes. The added auth note further clarifies scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only mentions authorization requirements ('Requires files:read for API keys') but does not provide guidance on when to use this tool versus alternatives, nor does it explain when not to use it. The context is minimal; an agent would need to infer usage from the name and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It mentions listing and permission requirements but does not clarify return format, pagination behavior (though 'limit' parameter suggests it), or whether results are ordered. This is insufficient for a read operation with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two short sentences with no superfluous words. Every sentence is informational.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks essential information given no output schema. Does not describe the return type (e.g., list of audit objects), pagination details, or any ordering. The minimal description leaves room for confusion about the tool's output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description does not explain the 'artifactBundleId' or 'limit' parameters. While parameter names are somewhat self-explanatory, the description adds no extra context about their purpose or constraints (e.g., what artifactBundleId represents).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists persisted audit history, distinguishing from 'read_audit' which retrieves a single audit. However, it does not explicitly differentiate from other list operations like 'list_evals' or 'list_artifact_bundles'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes a permission requirement ('Requires artifact_bundles:read for API keys'), which is a helpful prerequisite. Does not provide guidance on when to use this tool versus alternatives such as 'read_audit' or other list tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the auth requirement, adding behavioral context beyond schema fields. However, it does not explicitly state that the tool is read-only or idempotent, and no annotations exist to fill this gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with only two short sentences, no redundancy, and all information provided is directly useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters, no output schema, and no annotations, the description is incomplete. It lacks explanations of output format, pagination, or how the 'limit' parameter works, leaving significant gaps for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description fails to explain the parameters 'artifactBundleId' and 'limit.' It adds no meaning beyond the schema's basic type definitions, making it unhelpful for parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'List eval history,' which is a specific verb and resource. It is distinct from siblings like 'rubrkit_read_eval' (singular) and 'rubrkit_run_evals' (run), though it does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a prerequisite ('Requires artifact_bundles:read for API keys'), which helps in understanding authentication, but it offers no guidance on when to use this list tool versus alternatives like 'rubrkit_read_eval' or 'rubrkit_run_evals.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must convey behaviors. It states the read-only nature ('list') and auth requirement, but does not mention pagination limits (only implicit in schema), ordering, or any additional traits. Adequate for simple tool but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose, second adds auth requirement. No fluff, front-loaded with core info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 0% parameter coverage, the description lacks detail on return format, version ordering, or whether it lists all versions. Incomplete for an agent to use effectively without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no parameter details beyond the schema. It does not explain artifactBundleId, fileId, or limit in context, leaving the agent to infer from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'List immutable versions for a file', specifying the action (list) and resource (file versions). Distinguishes from sibling tools focused on artifact bundles, like rubrkit_list_artifact_bundle_versions, by targeting file-specific versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Only mentions a prerequisite (requires files:read for API keys) but provides no guidance on when to use this tool versus alternatives, such as rubrkit_list_artifact_bundle_versions or rubrkit_read_artifact_file.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the read-only nature and append-only behavior of events, and mentions auth requirements. However, it does not cover error handling or pagination details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: one sentence plus an auth note, with no extraneous information. It is well-structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 2 parameters, no output schema, and a list operation, the description is incomplete. It lacks details about what is returned, pagination behavior, and event contents, leaving significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention the parameters (jobId, limit) at all, leaving the agent to infer their purpose solely from names and schema constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read' and resource 'append-only job progress events', distinguishing it from sibling list tools that list other entities like artifact bundles or audits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes an authorization requirement ('Requires jobs:read for API keys'), which provides context for when the tool can be used, but lacks guidance on when to choose this over alternative list tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the permission requirement (read) but does not explicitly state the operation is read-only, nor does it describe pagination, ordering, or output format. Some value is added by the permission hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences that convey core purpose and a permission requirement. It is well-structured and front-loaded without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters (one required) and no output schema, the description is too minimal. It lacks parameter explanations, return value description, and details on pagination or effective usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It does not mention artifactBundleId or limit, leaving their semantics entirely to the schema. The description adds no value for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List conversion history', directly aligning with the tool name and title. It also adds a permission requirement, providing useful context for usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only mentions a permission requirement but offers no guidance on when to use this tool versus siblings like read_rubr_flow_conversion or convert_to_rubr_flow. No context on filtering or alternatives is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden. It discloses the read nature and permission requirement, but fails to describe the return format (e.g., what 'progress' means, status fields, polling behavior), leaving behavior partially ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with clear separation of purpose and auth requirement—efficient and front-loaded, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tool with one parameter, but lacks description of the return value or behavior beyond 'progress', which is important since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no meaning beyond the input schema; the schema covers 0% of parameter semantics, and while 'jobId' is self-explanatory, the description does not elaborate on format, constraints, or how to obtain the ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read' and the resource 'async job progress', which is specific and distinguishes it from sibling tools like rubrkit_list_job_events that list events rather than progress.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided; the description only mentions a permission requirement ('Requires jobs:read for API keys') but does not specify when to use this tool over alternatives or any prerequisites beyond auth.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 a non-destructive read operation but doesn't disclose any potential behaviors such as error cases, permissions, or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence that front-loads the verb and resource. It could be slightly more structured but is efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter and no output schema or annotations, the description provides the core purpose. However, it lacks details on return format or any constraints, which would add completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'slugOrPath' has minimal schema definition (just type and minLength). The description adds significant meaning by explaining it can be a slug, file name, or docs/api path, which compensates for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Read' and the resource 'docs/api guide or OpenAPI source', along with how to locate it (by slug, file name, or path). This distinguishes it effectively from sibling tools like search_api_docs or read_artifact_bundle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reading specific API docs but doesn't explicitly state when to use this tool over alternatives or provide any context about prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 clearly states it is a read operation ('Read'), which implies no side effects, and specifies what is returned (details, files, file tree). While it could explicitly note idempotency, the description adequately conveys the safe read-only nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no superfluous information. The first sentence states the tool's function, and the second adds a permission requirement. Every word contributes value, making it highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, the description provides a high-level overview ('details, files, and file tree') but does not specify what details include. It is adequate for a simple read tool but could be more complete by listing typical fields or explaining the output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'artifactBundleId' is not explained in the description beyond its presence in the schema. With 0% schema description coverage, the description should add context (e.g., where to find the ID, format expectations), but it does not. The parameter name is self-explanatory, but lacking guidance on how to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read artifact bundle details, files, and file tree,' specifying the verb (read), resource (artifact bundle), and the sub-resources (details, files, file tree). This distinguishes it from sibling tools like rubrkit_read_artifact_file and rubrkit_list_artifact_bundles, which have different scopes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only mentions a permission requirement ('Requires artifact_bundles:read for API keys') but does not provide explicit guidance on when to use this tool versus alternatives (e.g., rubrkit_list_artifact_bundles for listing all bundles). No when-to-use or when-not-to-use information is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It states 'Read' (non-destructive) and the required permission, but does not disclose whether it returns multiple versions, pagination, error handling, or if the 'latest' file is always the current version. The description is vague about the operation's exact behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise and front-loaded. However, it sacrifices essential details, making it under-specified. It earns no extra credit for brevity because it omits critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With two required parameters, no output schema, and no annotations, the description is very incomplete. It lacks information about return values, error conditions, parameter relationships, and how this tool fits among many sibling read tools. The agent would struggle to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the parameters have no descriptions in the schema. The tool description does not add any meaning to 'fileId' or 'artifactBundleId', nor explain their relationship. The agent must infer their purpose from names alone, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Read the latest file metadata and content,' which clearly identifies the action (read) and resource (artifact file). It distinguishes from sibling tools like 'rubrkit_list_artifact_files' (which lists files) and 'rubrkit_read_artifact_bundle' (which reads a bundle). However, it does not explicitly mention the required IDs (artifactBundleId, fileId) in the description, relying on the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only mentions a prerequisite ('Requires files:read for API keys') but provides no guidance on when to use this tool versus alternatives like 'rubrkit_list_artifact_files' or 'rubrkit_read_artifact_bundle'. It does not explain the use case or conditions for invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only mentions 'Read' and a permission requirement, but does not confirm safety (e.g., idempotency, no side effects), response format, or any constraints beyond the permission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, the first clearly stating purpose. However, it is under-informative for a tool with no output schema and no parameter descriptions, making it less effective than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 required params, no output schema), the description fails to provide essential context such as typical use cases, return value hints, or how the audit run is identified. It is minimally complete at best.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning. It does not explain what 'artifactBundleId' or 'auditRunId' represent, nor how they relate to the audit run. Parameter names provide limited hints, but 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read' and the resource 'a single audit run', distinguishing it from sibling tools like rubrkit_list_audits which list multiple runs. However, it does not explicitly name alternative tools or specify when to use this over others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It only states a prerequisite (permission requirement) but does not explain context or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states 'Read one eval run' implying non-destructive behavior and mentions an auth requirement. However, it does not disclose error handling, idempotency, or side effects beyond presumption of read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (two sentences) but sacrifices completeness by omitting parameter and output details. While efficient, it does not earn its brevity given the need for more information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity, the description fails to cover parameter meanings (schema coverage 0%) and does not hint at return values (no output schema). This leaves significant gaps for a tool that requires two IDs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage for parameter descriptions, and the description does not explain evalRunId or artifactBundleId. With no additional context, the agent must infer their meaning from names and UUID formats, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read one eval run,' specifying a single resource and a read operation. The name and title align, and the tool is distinct from siblings like 'rubrkit_list_evals' and 'rubrkit_run_evals'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Covers when to use (reading one eval run) and a key prerequisite (requires artifact_bundles:read). Does not explicitly exclude alternatives or list when-not-to-use, but the context from sibling tools implies differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only says 'Read' without disclosing behavioral details such as output format, caching, authentication, or side effects. For a read operation, minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, single sentence with no wasted words. Verb and resource are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description is minimal but adequate for a simple read. However, it could mention what the tool returns or how it relates to sibling read tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description adds nothing beyond the schema, but no additional parameter information is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action ('Read') and the specific resource ('canonical docs/api/openapi.yaml contract'), which distinguishes it from sibling tools like rubrkit_read_api_doc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., rubrkit_read_api_doc, rubrkit_search_api_docs). The agent is left to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states 'Read' (non-destructive operation) and a permission requirement. However, it does not disclose error behavior (e.g., missing report), idempotency, or any side effects. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two short sentences, front-loaded with the core purpose. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 0% parameter description coverage, the description is too brief. It does not describe the return value or the significance of the UUIDs, leaving the agent with insufficient context to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description does not explain the purpose or relationship of 'proofReportId' and 'artifactBundleId'. With two UUID parameters and no schema documentation, the description fails to clarify their roles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Read one proof report' – specific verb and resource. However, among siblings there are many 'read' tools (e.g., read_artifact_bundle, read_audit), and the description does not differentiate what a proof report is versus those, limiting sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions a prerequisite ('Requires artifact_bundles:read for API keys') but provides no guidance on when to use this tool versus alternatives, no when-not-to-use, and no context about the relationship to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the tool reads a report and mentions an auth requirement, omitting any details about potential errors (e.g., if the conversion doesn't exist), rate limits, idempotency, or return behavior. This is insufficient for a critical read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (two short sentences), which is positive, but it lacks any structure describing parameters, behavior, or output. It sacrifices necessary detail for brevity, resulting in an incomplete specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters with no schema descriptions, no annotations, and no output schema, the description fails to provide adequate context. It does not explain the relationship between the parameters, the structure of the conversion report, or any usage tips, making it insufficient for an agent to use correctly without prior knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has two parameters (conversionId, artifactBundleId) with 0% description coverage, and the description adds no explanation about what these parameters represent or how they map to the report. The agent must infer their meaning from context, which is risky and incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and the resource ('one conversion report'), which precisely identifies the tool's function. It effectively distinguishes itself from the sibling tool rubrkit_list_rubr_flow_conversions by specifying the singular nature of the read operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite ('Requires artifact_bundles:read for API keys'), which provides some usage context. However, it does not provide guidance on when to use this tool versus alternatives like list conversions, or any conditions under which the tool should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool creates new file versions (write operation) and requires specific permissions. However, it does not state whether existing files are overwritten, if the operation is reversible, or any potential side effects. Partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. It front-loads the primary action, then states the required permissions. Very efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 3 undocumented parameters, the description lacks important context. It does not explain what happens to current files, whether all files are restored, or the nature of the response. For a tool with significant side effects, this is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should explain parameters. It does not describe any of the three parameters (message, versionNumber, artifactBundleId) individually. No meaning is added beyond the schema's basic field definitions, leaving the agent to guess their purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it restores files from a prior artifact-bundle version by creating new file versions. The verb 'restore' and resource 'artifact bundle version' are specific. However, it does not explicitly distinguish from the sibling tool 'rubrkit_restore_file_version', which restores a single file version.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions required permissions (artifact_bundles:write and files:write), which is a prerequisite. But it provides no guidance on when to use this tool versus alternatives like 'rubrkit_restore_file_version' or other sibling tools. No context on scenarios or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full burden. It mentions 'by creating a new version' and the auth scope, but does not disclose side effects, error conditions, or what happens to the current version.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no unnecessary words. First sentence states the purpose, second adds a critical auth requirement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description is insufficient. It omits parameter purposes, return values, and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any of the 4 parameters (fileId, message, versionNumber, artifactBundleId). With zero compensation, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Restore a prior file version by creating a new version', specifying the verb and resource. It distinguishes from sibling tools like rubrkit_restore_artifact_bundle_version by focusing on file versions, not bundle versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It only mentions an auth requirement but does not provide context for selection among siblings or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description correctly identifies the operation as async, a key behavioral trait. However, with no annotations provided, it fails to disclose other important aspects like mutation side effects, return value (job ID or status), or error handling. The description does not indicate whether it is safe or destructive, leaving an agent uninformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (two sentences) and front-loaded with the purpose. However, given the tool's complexity (11 parameters, no output schema), it sacrifices necessary detail for brevity. It is concise but at the cost of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fails to cover essential context for an agent: parameter semantics, return value, polling mechanism for async completion, dependencies, or relationship to other tools like poll_job. With high complexity and no output schema, this description is critically incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description offers zero information about the 11 input schema parameters, despite the schema having 0% coverage. It does not explain what artifactBundleId, maxCases, testCases, or any other parameter does. The agent must rely solely on parameter names and types, which are insufficient without descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Start' and the resource 'async eval run'. It distinguishes from siblings like list_evals and read_eval by indicating a new run is initiated. However, it does not elaborate on the async nature or how it differs from other mutation tools like start_audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a required permission ('Requires evals:run for API keys'), which gives usage context. But it lacks explicit guidance on when to use this tool versus alternatives such as list_evals or read_eval. No when-not-to-use or alternative suggestions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only specifies what is searched, not how (e.g., full-text vs keyword, ranking, pagination, or result format). Critical behavioral details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters, no annotations, and no output schema, the description is incomplete. It omits search behavior, result format, and parameter details, leaving significant gaps for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not elaborate on the parameters. With 0% schema description coverage, it should clarify query semantics (e.g., free text, phrase) and limit behavior. Parameter names alone are insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: searching through 'canonical docs/api Markdown guides and OpenAPI operation summaries.' This specific verb-resource combination distinguishes it from sibling tools like rubrkit_read_api_doc, which retrieves a single document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention when-not-to-use or suggest related tools like rubrkit_read_api_doc for specific document access.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes async nature, caching, force bypass, and auth requirements. Lacks details on result retrieval or monitoring, but covers key behavioral aspects given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with main action, efficient explanation of caching and auth. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 10 parameters, no output schema, and no annotations, the description is insufficient. It explains only one parameter and omits how to handle results, monitor progress, or what returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only 'force' parameter is explained in description; the other 9 parameters (including required artifactBundleId) are left to the schema, which has 0% description coverage. Description adds minimal semantic value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Start an async audit job', specifying verb and resource. It distinguishes from sibling tools like rubrkit_list_audits or rubrkit_read_audit by focusing on starting a new audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on caching behavior and use of force parameter, along with required permission (audits:run). Does not explicitly state when not to use or compare to siblings, but context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for behavioral disclosure. It states the tool creates a new version (mutation), but does not clarify whether this overwrites the existing file, how versioning works, or any side effects. The description lacks details on what happens to old versions, idempotency, or concurrency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two short sentences: the first states the action, the second states the permission. It is highly concise, front-loaded with the core functionality, and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is overly brief. It omits crucial information such as return values, error conditions, file existence requirements, version management, and parameter constraints. The description leaves significant gaps for effective agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning no parameter descriptions are provided in the schema. The description does not explain any of the five parameters (fileId, content, message, mediaType, artifactBundleId), nor does it clarify their roles beyond the bare names. Thus, it adds minimal value for understanding parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Write a new editable version for a file.' The verb 'write' and the specific object 'editable version for a file' make the purpose unambiguous. It distinguishes itself from siblings like 'read_artifact_file' (read) and 'upload_artifact_files' (initial upload).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the permission requirement 'Requires files:write for API keys,' which is a prerequisite. However, it provides no guidance on when to use this tool versus alternatives (e.g., upload_artifact_files, restore_file_version), nor does it specify when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It mentions 'text files' but schema allows any string content. It does not disclose behavior on bundle existence, overwriting, or file size limits. The permission note is useful but insufficient for complete transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence plus a permission note, which is concise. However, it is too brief given the parameter complexity (2 required params, 5 optional sub-properties). It could include more detail without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations, no output schema, and 0% parameter description coverage. The tool has complex nested parameters, but the description provides minimal context. An agent would struggle to understand return values, error conditions, or file constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to the parameters (artifactBundleId, files with path, content, message, mediaType, artifactType). The agent gets no hints about how to populate these fields correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Upload one or more text files into an artifact bundle' and mentions the required permission 'files:write for API keys'. It distinguishes from sibling tools like read, update, delete, and list by specifying the unique action of uploading files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear precondition: requires files:write permission. It implies when to use (to add files to a bundle) but does not explicitly state when not to use or suggest alternatives like update for existing files.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.