rubrkit

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 mentions required permissions (artifact_bundles:write), but does not describe success/failure behavior, response format, side effects, or any additional constraints. For a mutation tool, 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 two sentences, front-loaded with the key action. No filler words. Every sentence adds value: first explains what the tool does, second provides endpoint and permission 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 the complexity (8 parameters, nested objects, no output schema, no annotations), the description is incomplete. It covers purpose and auth but leaves parameter details and behavior unspecified. The tool is a creation operation, yet return values and side effects are omitted.

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

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

Schema description coverage is 0%, so the description must compensate. It only hints at 'input' and 'expectedOutput' via the phrase 'input with a confirmed-correct output', but ignores 6 other parameters (tags, origin, weight, criteria, originRef). The URL path implied artifactBundleId but no details on format or constraints 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?

The description clearly states the verb 'Add', the resource 'golden case', and the context 'to an artifact bundle'. It explains what a golden case is (a real edge-case input with confirmed-correct output), distinguishing it from sibling tools like retire or list golden cases. The endpoint URL is also provided, adding specificity.

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 when you need to add a golden case to an artifact bundle, but does not explicitly state when to use this tool versus alternatives like list_golden_cases or retire_golden_case. No when-not-to-use guidance 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 carries full burden. It reveals the mutation effect ('a new version per changed file') and mentions authorization scope. However, it omits details on reversibility, idempotency, or rate limits. The key behavioral trait is communicated but not comprehensively.

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

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

Two concise sentences: the first states the primary purpose and key detail (new versions), the second adds a permission requirement. No redundancy, front-loaded, and 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 the tool's mutation nature, the description covers the basic effect and a prerequisite. However, it lacks context on prerequisites (e.g., audit must be complete), output or side effects beyond version creation, and how to obtain IDs. The explanation is sufficient for a familiar agent but incomplete for a new one.

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 provides no explanation of the two required parameters (auditRunId, artifactBundleId). It gives no context on how to obtain them or their role, forcing the agent to infer from the tool name 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?

The description explicitly states the action ('Apply') and the resource ('a completed audit's AI rewrite to the bundle files'), with additional detail about creating new versions per changed file. This clearly distinguishes it 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'), which is helpful. However, it does not specify when to use this tool versus alternatives, nor provide context about the required state of the audit (e.g., 'after completion'). The guidance is minimal.

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 indicates the tool is async ('start an async ... job') and requires specific permissions. Without annotations, these are useful behavioral traits. However, it omits details like whether it returns a job ID, how to track progress, 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.

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

Two concise sentences with no filler. Essential info (async job, required permission) is front-loaded. Every sentence adds value.

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 7 parameters, no output schema, and no schema descriptions, the description fails to cover key aspects like job lifecycle, return value, polling, or error scenarios. The tool's complexity is not matched by the description.

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 parameter descriptions in schema or description. Only artifactBundleId is mentioned as required. Parameter names like modelTier, reasoningEffort, targetFileId, targetVersionNumber, and artifactBundleVersionNumber are not explained, leaving ambiguity. Enums are present but not described.

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 tool starts an async conversion job for rubr_flow. The verb 'start' and resource 'rubr_flow conversion' are specific. While it doesn't explicitly distinguish from siblings, the context of sibling tools like read and list conversions provides differentiation.

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

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

No guidance on when to use this tool versus alternatives. Only mentions a required permission (rubr_flow:convert). Does not state prerequisites, scenarios, or when to avoid using 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 must fully disclose behavior. It only states it creates a bundle and the required permission, but lacks details on side effects, idempotency, return values, or any constraints beyond the schema. For a creation tool, 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 exceptionally concise, consisting of two sentences that front-load the core action and permission requirement. Every word adds value without redundancy.

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 4 parameters (including nested objects) and no output schema, the description is far from complete. It fails to explain the purpose of 'settings' or 'customRubric', nor does it describe the response. Sibling tools are listed but not differentiated.

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 adds no information about the 4 parameters (name, settings, description, customRubric). While the schema provides type and constraints, the description does not explain what these parameters mean or how to use them effectively.

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 'create' and the resource 'artifact bundle', along with the specific API endpoint. This distinguishes it from sibling tools, which target different resources like drift monitors or golden cases. The action is unambiguous.

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

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

The description implies the tool is for creating artifact bundles and mentions the required permission 'artifact_bundles:write', which provides context for API key usage. However, it does not explicitly state when to use this tool vs alternatives, though no direct alternative exists for creating artifact bundles among siblings.

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 states the HTTP method and required permission but lacks details on behavioral traits: whether creation is idempotent, limits on monitors per bundle, immediate triggering, or side effects. The cadence and repeats parameters are unexplained, leaving ambiguity.

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 at two sentences, front-loading the action and endpoint. However, it sacrifices essential information for brevity, so it does not earn the top score.

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 incomplete. It fails to explain key parameters (cadence, repeats) or describe the return value. For a creation tool, more context on success/error behavior is needed.

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 JSON schema provides no descriptions for any of the 4 parameters. The description does not explain artifactBundleId, pinnedVersionId, cadence, or repeats, offering no meaning beyond the schema. This is a critical gap.

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 creates a drift monitor pinned to a file version, using the specific HTTP POST endpoint. This distinguishes it from sibling tools like list_drift_monitors or set_drift_monitor_status. The verb 'Create' and resource 'drift monitor' are explicit.

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 (artifact_bundles:write), indicating a prerequisite, but does not provide guidance on when to use this tool versus alternatives like list or set status. Usage context is implied but not differentiated.

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 the state change to archived, the possibility of future restoration or permanent deletion, and the required permission. It lacks details on idempotency or side effects but is adequate for a simple archive 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?

The description is two sentences, front-loaded with the core action and resource. Every word adds value with no redundancy.

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 simple tool (one parameter, no output schema), the description covers the operation, state change, and permissions. It could briefly mention how restoration works, but overall it is sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions the parameter implicitly via the endpoint path but does not provide additional details beyond the UUID format specified in the schema. The value is minimal.

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 that the tool archives an artifact bundle via soft delete and specifies the HTTP endpoint. It distinguishes itself from the sibling tool `rubrkit_hard_delete_artifact_bundle` by using the term 'soft delete' and mentioning the archived state.

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 that this tool is for archiving, with the ability to restore or permanently delete later. However, it does not explicitly name the alternative hard delete tool, though the sibling list provides 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 are provided, so the description must carry the full burden. It reveals the async nature and default export storage, but does not disclose any side effects, rate limits, or what happens to existing reports. This is a moderate disclosure.

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 concise sentences, front-loading the primary action. It is not verbose, though it could include a bit more detail without becoming wordy. Overall, 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?

With 11 parameters, no output schema, and no annotations, the description leaves critical gaps: parameter usage, return value, error states, and additional prerequisites. The brief mention of async and permissions does not compensate for the missing 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 adds no explanation for any of the 11 parameters. It only mentions a required permission, not parameter meanings. The agent has no guidance on how to fill in fields like evalRunId, artifactBundleId, etc.

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 distinguishes from sibling tools like rubrkit_read_proof_report and rubrkit_poll_job, making the purpose unambiguous.

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

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

The description mentions the required permission 'evals:run', providing context for when to use the tool. It does not explicitly exclude alternatives or describe when not to use, but the permission hint is useful for agent decision-making.

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 explicitly states irreversibility, that it affects all associated files, versions, and run history, and the prerequisite that the bundle must be archived. This fully discloses the destructive nature and constraints.

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: first explains the action and scope, second adds prerequisites and permissions. No unnecessary words. Efficient and 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 one parameter, no output schema, and no annotations, the description covers the essential aspects: what it does, permanence, prerequisites, and permissions. It does not mention error scenarios or return values, but for a simple destructive operation with a clear purpose, this is nearly complete.

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

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

Schema coverage is 0%, so description must add value. It mentions the URL pattern with {artifactBundleId} but does not explicitly describe the parameter's format (UUID) or its meaning beyond the path. While the path implies the ID, a direct statement would be clearer. Score 3 because it provides some context but not full compensation for lack of schema description.

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 permanently deletes an archived artifact bundle including all files, versions, and run history. The verb 'permanently delete' combined with the resource 'artifact bundle' precisely defines the action. It distinguishes from the sibling 'rubrkit_delete_artifact_bundle' which likely performs soft delete.

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 specifies that the tool only works on bundles already archived and requires the 'artifact_bundles:write' permission. It does not explicitly list when not to use this tool or name alternatives, but the context of permanence implies a soft delete alternative exists.

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 burden. It discloses the required read permission, indicating a safe operation. However, it lacks details on pagination, rate limits, or behavior edge cases.

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, no fluff, front-loaded with the core purpose. Every word adds value.

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

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

The tool has 2 parameters and no output schema, yet the description omits parameter purpose and response format. Basic guidelines like pagination or filtering are missing, leaving the agent underinformed.

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 the limit and status parameters. Agents must infer from schema names and types, which may lead to incorrect usage without further context.

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 lists artifact bundles, specifies the endpoint, and distinguishes from siblings like read or create. It names the required permission, making the purpose unambiguous.

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

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

The description implies usage for listing bundles but provides no guidance on when to use this versus read, or how to filter using parameters. No exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description carries full responsibility. It only states the basic action and permission. It does not disclose pagination behavior, ordering, or what 'version events' include (e.g., creation, updates). This is insufficient for an agent to understand side effects or expectations.

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 at one sentence plus a permission note. It is front-loaded with the core action. However, it could include more useful information without being overly verbose, so it slightly lacks 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?

Given the tool has 2 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It does not explain the return format, pagination, or how to interpret 'version events'. This is inadequate for an agent 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%, meaning the description adds no meaning beyond the schema. The description does not explain what 'limit' controls or that 'artifactBundleId' is required. The agent must rely solely on the schema, which is minimal.

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 title and description clearly state the tool lists bundle-level version events. The verb 'list' and resource 'artifact bundle versions' are specific and distinguish it from siblings like rubrkit_list_artifact_bundles and rubrkit_list_file_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?

The description includes a permission requirement ('Requires artifact_bundles:read for API keys'), providing some context for use. However, it does not specify when to use this tool versus alternatives like rubrkit_list_file_versions, nor does it mention any 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 must carry full burden. It fails to disclose behavior beyond listing files, such as pagination behavior, error handling for missing bundles, or ordering. The permission note is the only behavioral 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 very short (one sentence plus permission note), which is concise but omits essential details. It could be restructured to front-load the purpose and then add parameter context without increasing length much.

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 and the number of parameters, the description is incomplete. It does not explain pagination (limit parameter), return format, or ordering. For a list operation, this information is critical for correct invocation.

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 information about the two parameters (artifactBundleId and limit). The schema provides basic constraints (type, default, min/max), but the agent receives no explanation of their purpose or 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 verb (list) and resource (files in an artifact bundle). It effectively distinguishes from sibling tools like rubrkit_list_artifact_bundles and rubrkit_list_file_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?

The description mentions the required permission ('Requires files:read for API keys'), but does not provide explicit guidance on when to use this tool versus alternatives such as read_artifact_file or list_file_versions. Usage is implied by the verb.

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?

Annotations are absent, so description carries full burden. Only discloses a permission requirement; no info on side effects, pagination, ordering, or data scope.

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, efficient but omits critical parameter details. Loses points for not being structured to include parameter guidance.

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 (1 required), no output schema, and no nested objects, description is too sparse. Lacks parameter explanation and return value context, making it 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?

Schema description coverage is 0%, yet description provides no information about parameters (artifactBundleId, limit). Agent cannot infer parameter roles or formats from description 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 it lists persisted audit history, using a specific verb and resource. Distinguishes from siblings like rubrkit_read_audit (read single) and rubrkit_start_audit (create).

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 required permission (artifact_bundles:read), implying usage context. Does not explicitly state when not to use or alternatives, but the permission requirement offers some guidance.

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 cover behavioral aspects. It mentions the endpoint and permissions but omits details like response format, pagination, or side effects. The tool is a read operation, but more context is needed.

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, consisting of two sentences with no unnecessary information. It is well-structured and front-loaded with the core 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?

The description is incomplete for a list operation without an output schema. It does not explain what the response contains (e.g., an array of monitor objects) or mention pagination. Given no annotations, more detail is needed.

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 does not explain the parameter artifactBundleId beyond its presence in the schema. It could clarify where to obtain this ID or its significance, but it does not.

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 that the tool lists drift monitors for an artifact bundle, specifying the API endpoint. This distinguishes it from sibling tools like rubrkit_create_drift_monitor or rubrkit_set_drift_monitor_status.

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 but does not explicitly state when to use this tool versus alternatives. The name implies listing, but no guidance is given on when to list versus other operations like creating or setting status.

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 must cover behavioral traits. It only states listing and a permission, omitting details like pagination, ordering, or output format. The limit parameter in the schema hints at pagination but is not explained.

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 brief but under-specifies. While it avoids fluff, it lacks detail necessary for correct use, making it more inadequate than 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 tool's complexity (two parameters, list operation, no output schema), the description is incomplete. It fails to explain what eval history consists of, how results are structured, or how to interpret the artifactBundleId requirement.

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%, so the description should clarify parameters. It does not explain artifactBundleId or limit, failing to add meaning beyond the bare schema definitions.

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 lists eval history. The verb 'list' and resource 'eval history' are specific, and it distinguishes from sibling tools like rubrkit_read_eval for reading a single eval.

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 ('artifact_bundles:read'), which provides usage context. However, it does not specify when to use this tool versus alternatives like rubrkit_read_eval or how to filter or paginate results.

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. Description states 'immutable versions' implying read-only, but lacks details on pagination, ordering, or empty result handling. Minimal transparency beyond basic read 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?

Extremely concise (one sentence plus permission), but lacks structure and important details. Efficiency is overwhelmed by incompleteness.

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 output schema, parameter descriptions missing, and no behavioral details. The tool's full behavior and expected output are underspecified, making it hard for an agent to invoke 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 coverage is 0%. Description does not explain any of the three parameters (fileId, artifactBundleId, limit). The agent must rely on parameter 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?

Description clearly states action 'List' and resource 'immutable versions for a file' with a permission requirement. Differentiates from siblings like restore_file_version and read_artifact_file.

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 permission requirement but provides no guidance on when to use this tool over other list tools (e.g., list_artifact_bundle_versions, list_artifact_files). No when-to-use or when-not-to-use 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?

With no annotations, the description must fully disclose behavior. It only states the API endpoint and required permissions, offering no details about pagination, filtering, ordering, error handling, or result format. This is insufficient for understanding the tool's 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 very short (two sentences) and to the point. It front-loads the purpose. However, it could be more informative without sacrificing conciseness.

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

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

Given the lack of output schema and annotations, the description is inadequate. It does not explain what golden cases are, how results are structured, or any limitations. For a list tool, pagination or sorting details are typically expected.

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

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

The schema description coverage is 0%, so the description should explain parameters. It does not mention artifactBundleId or status, nor their purpose or constraints. The description adds no semantic 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 action ('list') and the resource ('golden cases for an artifact bundle'), with explicit mention of the API endpoint. It effectively distinguishes from sibling tools like rubrkit_add_golden_case and rubrkit_retire_golden_case.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no indication of prerequisites, use cases, or when not to use it. Only a permission requirement is 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 states the behavior (read append-only events) and adds the API key requirement. However, it lacks details on ordering, pagination, or rate limits, which are important for a list tool without annotations.

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

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

The description is very short and front-loaded, which is good for conciseness, but it is under-specified and misses critical details, making it less effective.

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 no parameter descriptions, the description should provide more context about the return format, ordering, or event structure. It is incomplete for a list endpoint.

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 provides no information about the parameters (jobId or limit). The schema itself lacks descriptions, so the description must compensate, but it does not.

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 resource ('job progress events'), and implies read-only nature. However, it does not explicitly differentiate from sibling list tools, though the resource name is distinct.

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 jobs:read for API keys') but provides no guidance on when to use this tool versus alternatives like rubrkit_poll_job 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?

No annotations are provided, so the description carries full burden. It discloses the permission requirement but does not mention behaviors like pagination, sorting, or response format. The 'limit' parameter is not described, leaving the agent unaware of its effect.

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 with two sentences, but it is not optimally front-loaded. The first sentence states the purpose clearly. However, the second sentence provides a permission requirement, which is useful but not enough to compensate for missing parameter 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 the tool has 2 parameters, no output schema, and no annotations, the description should explain the required 'artifactBundleId' and optional 'limit'. It does not, leaving the agent with incomplete context to use the tool properly.

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

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

Schema description coverage is 0%, so the description must compensate. It fails to describe the two parameters ('artifactBundleId' as required filter, and 'limit' for pagination). This leaves the agent without essential information to correctly invoke the tool.

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

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

The description 'List conversion history' clearly states the action (list) and resource (conversion history). It distinguishes from the sibling 'read_rubr_flow_conversion' which reads a single conversion. However, it could be more explicit about the artifact bundle context.

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 the required permission 'artifact_bundles:read'. It provides no guidance on when to use this tool versus alternatives like 'read_rubr_flow_conversion', nor any context for when listing is appropriate.

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 must convey behavioral traits. It states 'read' implying safety, but lacks details on side effects, idempotency, or whether it modifies state. Minimal implicit 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 brief but under-specified. The single sentence omits critical details; it is not concise in the sense of being optimally informative. Fails to earn its place with substantive 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?

Despite low complexity, the description omits important context: what the response contains (e.g., progress percentage, status), that the job ID comes from an async operation, and any rate limits. Incomplete 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?

Schema has one parameter (jobId) with 0% description coverage. The description does not mention the parameter, its role, or constraints such as format, adding 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 'Read async job progress', specifying the verb and resource. It distinguishes from sibling 'rubrkit_list_job_events' which lists events rather than polling 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 guidance on when to use this tool vs alternatives. The permission note 'Requires jobs:read for API keys' is provided, but there is no context about appropriate invocation timing or scenarios.

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 only states 'Read' implying non-destructive, but no details on side effects, authentication, rate limits, caching, or error behavior. 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.

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

Single sentence, no unnecessary words. Front-loaded with purpose. 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?

No output schema, no parameter details beyond vague types. The description fails to explain return format, pagination, or error scenarios. Incomplete for an API doc reader 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 has 0% description coverage. The description adds that slugOrPath can be a slug, file name, or path, which provides some context beyond the schema, but format or constraints are still unclear.

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 reads docs/api Markdown guides or OpenAPI sources by slug, file name, or path. This is specific and distinguishes from search tools, but it overlaps with 'read_openapi_contract' sibling, slightly reducing clarity.

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 like rubrkit_search_api_docs or rubrkit_read_openapi_contract. No when-to or when-not-to information.

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 carry the full burden. It states the operation is read-only and requires specific permissions, but it does not disclose idempotency, side effects, or response structure. The vague phrase 'details, files, and file tree' leaves ambiguity about output.

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 concise sentences: first stating the action and scope, second noting the required permission. No redundant information. Front-loaded with the core 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 the tool's simplicity (1 parameter, no output schema, no annotations), the description covers basic purpose and auth but lacks detail on return structure and usage scenarios, leaving gaps for an agent to fully understand the tool's capabilities.

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' has no description in the input schema (0% coverage). The tool description does not explain the parameter's purpose or format beyond the schema. Although the name is self-explanatory, the description adds no value to 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?

Description clearly states 'read artifact bundle details, files, and file tree', specifying the action and scope. However, it does not differentiate from sibling read tools like rubrkit_read_artifact_file or rubrkit_read_audit, which limits clarity for tool selection.

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. The only usage information is the required permission 'artifact_bundles:read'. There is no mention of when not to use it or which sibling tools to consider for different scenarios.

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, description carries full burden. It implies a non-destructive read but does not clarify what 'latest' means, whether content is raw or metadata, or response structure. Minimal behavioral insight.

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 extra words, but lacks sufficient detail to be truly useful. Could be expanded while staying 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 no output schema and two UUID params, description is too sparse. Missing details on what 'latest' version means, return format, or how parameters relate. Not complete for reliable 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 has 0% description coverage, and description adds no information about the two required parameters (fileId, artifactBundleId). Agent must infer meaning solely from parameter names, 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?

Description clearly states it reads the latest file metadata and content, using specific verbs and resource. Distinguishes from sibling list tools like rubrkit_list_artifact_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?

Only provides authentication requirement (files:read) but no guidance on when to use this tool versus alternatives like rubrkit_read_artifact_bundle or rubrkit_list_file_versions. Lacks 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?

With no annotations provided, the description adds the permission requirement as behavioral context, but lacks details on side effects, rate limits, or response 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 concise with two sentences, front-loaded with the primary action, and contains 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 simple read tool with two parameters and no output schema, the description is minimally adequate but could be improved by mentioning what is returned.

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 the two UUID parameters (auditRunId and artifactBundleId), failing to add meaning beyond the schema itself.

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

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

The description uses the specific verb 'Read' and resource 'audit run', clearly distinguishing it from sibling tools like 'rubrkit_list_audits' which lists 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 mentions a required permission ('artifact_bundles:read') but does not provide explicit guidance on when to use this tool versus alternatives 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?

With no annotations, the description carries the burden. It gives permission requirements and the API endpoint, but does not disclose response format, pagination, or ordering. For a read-only list tool, it is moderately transparent but could be improved.

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 the action. The API path could be implied, but it is not overly verbose. Efficient for the information provided.

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 simple parameter set and lack of output schema, the description covers the basic purpose and permissions. However, it lacks details on return format, pagination, error codes, or example usage, leaving some context 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?

Schema coverage is 0%, so the description must compensate. However, it does not explain the parameter 'driftMonitorId' beyond what the schema provides (type, format). No additional meaning or context.

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 (List), the resource (observations for a drift monitor), and the API endpoint. It distinguishes this tool from sibling tools like 'rubrkit_list_drift_monitors' which lists monitors, not observations.

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, no prerequisites or exclusions. Only mentions permission requirements, which is minimal guidance.

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 the full burden. It discloses that 'stats' are only available for advanced-mode runs and empty for standard runs, which is a key behavioral detail. It also mentions the required permission. It does not, however, describe error handling or response format, but the given details are above average.

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 long, front-loads the core purpose and key behavioral nuance about stats, and adds a permission note. Every sentence adds value with no redundancy.

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 output schema exists, so the description should clarify return values. It mentions 'stats' but not other potential fields (e.g., basic eval data). For a simple read operation, this may be adequate, but it leaves ambiguity about the full response structure. Given the lack of schema, a bit more detail would improve 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%, so the description must compensate. It does not explain the meaning or purpose of 'evalRunId' or 'artifactBundleId' beyond stating they are required. No additional context is provided, making it hard for the agent to infer how to obtain these IDs.

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 tool reads one eval run and specifies the inclusion of 'stats' for advanced-mode runs. It uses a specific verb ('Read') and resource ('eval run'), and distinguishes from sibling tools like 'rubrkit_list_evals' and 'rubrkit_run_evals' by focusing on a single run with statistical details.

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'), but does not explicitly state when to use this tool versus alternatives like 'rubrkit_list_evals' or 'rubrkit_run_evals'. It lacks guidance on when not to use it or how the stats behavior relates to typical workflows.

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 fully disclose behavioral traits. It implies a read operation (via 'Compare' and required read permissions) but does not explicitly state idempotency, side effects, rate limits, or data retrieval characteristics. The endpoint URL adds structural detail but not behavioral 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 at two sentences. The first sentence efficiently conveys action, method, and endpoint; the second covers permission requirements. No redundant text, though the first sentence is dense.

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 annotations, no output schema, and incomplete parameter explanations, the description is insufficient for reliable tool selection and invocation. Missing details include return format, error handling, parameter constraints, and behavior beyond the basic operation.

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

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

The input schema has three parameters (artifactBundleId, binCount, windowDays) with 0% schema description coverage. The description only mentions artifactBundleId implicitly via the endpoint and hints at windowDays ('reference window'), but entirely omits binCount. The agent lacks essential meaning for binCount.

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 identifies the specific action: compare recent production inputs against a prior reference window using population stability index (PSI) for an artifact bundle. It includes the exact HTTP method and endpoint path, distinguishing it from sibling tools like read_drift_observations and read_validity_drift.

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 lists required permissions (artifact_bundles:read or artifacts:pull), providing practical guidance. However, it does not explicitly contrast with other drift-related sibling tools or state when to prefer this over alternatives.

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 verb 'Read' implies a safe, idempotent operation with no destructive side effects. However, without annotations and given the minimal description, the agent gets no explicit confirmation of safety, permissions, or return format. The implied behavior is clear 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.

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

Single sentence, front-loaded with the verb, and contains no superfluous words. It is highly efficient and directly conveys the tool's 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?

For a parameterless read tool with a clear file path, the description is sufficient. However, it does not explain the relationship to rubrkit_read_api_doc or why 'canonical' matters, leaving minor ambiguity in a rich sibling 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?

The input schema has no parameters (100% coverage by absence), so the description adds nothing beyond the schema. Baseline 3 is appropriate per rules.

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 (the canonical docs/api/openapi.yaml contract). The term 'canonical' helps distinguish from sibling tools like rubrkit_read_api_doc, which likely reads a different API 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?

No guidance on when to use this tool versus its siblings. It does not explain what makes this the 'canonical' contract or contrast with other read tools such as rubrkit_read_api_doc or rubrkit_search_api_docs.

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 auth requirement but lacks details on side effects (likely none), output format, or any constraints like rate limiting or data scope.

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

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

The description is a single sentence with a permission note, no redundant words, and the core action is front-loaded. Every word earns its place.

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

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

Given no annotations, no output schema, and minimal param info, the description leaves the agent without context on what a proof report is, how to obtain the IDs, or what the response contains. It meets basic requirements but is insufficient for practical 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?

Schema description coverage is 0%, and the description does not explain the parameters 'artifactBundleId' and 'proofReportId' beyond their names. The parameter names are somewhat self-explanatory, but the description adds no additional meaning.

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

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

The description clearly states 'Read one proof report,' specifying the action and resource. It distinguishes from siblings because the resource is specific, though it does not explicitly differentiate from other read tools like 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 mentions a permission requirement ('Requires artifact_bundles:read for API keys') but provides no guidance on when to use this tool versus alternatives such as rubrkit_export_proof_report or other read 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?

Describes read operation and required permission, but no annotations provided; lacks details on side effects 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.

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

Extremely concise with two sentences; front-loads purpose, but could include parameter details without adding bulk.

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 output schema, no parameter descriptions, and no usage examples; incomplete for a tool with two required parameters.

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 description does not explain the meaning or format of conversionId and artifactBundleId beyond basic 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?

Description clearly states verb 'Read' and resource 'conversion report', distinguishing from sibling list tool that retrieves multiple conversions.

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 prerequisite permission but does not explicitly guide when to use this tool versus the list sibling or alternatives.

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. The description adds auth requirements and indicates it is a read operation (GET), but lacks details on error behavior, pagination, or rate limits. Partial 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.

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

Two sentences, no wasted words. First sentence packs purpose and endpoint; second adds auth requirements. Efficient and 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?

No output schema, so description should explain return values; it does not. Also lacks guidance on obtaining artifactBundleId. Not fully complete for agent use, especially among many drift siblings.

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% with one parameter. The description mentions artifactBundleId implicitly in the URL but adds no meaning beyond the schema (e.g., how to obtain the ID or valid format). Should compensate more.

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 'correlate' and 'check', the resource 'validity drift of an artifact bundle', and distinguishes from siblings like read_drift_observations and read_input_drift by specifying 'validity'.

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

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

The description gives context via the HTTP method and path but does not explicitly state when to use this tool versus siblings like read_drift_observations or read_input_drift. No when-not or alternative guidance 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?

No annotations are provided, so the description carries the full burden. It mentions the HTTP method POST and the resource, but does not disclose whether the operation is idempotent, destructive, or what happens on duplicate entries. Side effects and behavior are not described.

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: the first contains the action, object, data types, and endpoint; the second adds permission info. It is front-loaded with essential information and contains 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?

Given the tool has 7 parameters, 0% schema coverage, no annotations, and no output schema, the description is too sparse. It does not explain return values, default behaviors, or constraints for most parameters, making it insufficient for an agent to fully understand the tool's behavior.

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 only hints at three parameters (inputFeature, outcomeMetric, outcomeLabel) via 'input feature, metric, and/or label', but does not explain inputHash, occurredAt, artifactVersionId, or artifactBundleId beyond the endpoint. With 0% schema coverage, the description should provide more parameter details.

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 specifies the action 'Record' and the resource 'production outcome event for an artifact bundle', including the HTTP method and endpoint. It clearly distinguishes from siblings like 'create_artifact_bundle' or 'list_artifact_bundles' by targeting a specific outcome event record.

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 states the required permission ('artifact_bundles:write') but does not provide explicit guidance on when to use this tool versus alternatives, such as when to record an outcome vs. when to create an artifact bundle. The purpose is clear enough to infer usage, but lacks explicit when/when-not 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 are provided, so the description carries the full burden. It discloses that the tool creates new file versions to restore, which is the core behavior. However, it omits details such as whether the operation is destructive, idempotent, or has side effects. Adequately 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?

The description is two sentences: the first states the purpose, the second provides required permissions. No unnecessary words, front-loaded, and 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?

There is no output schema, and the description does not mention return values, error conditions, or prerequisites beyond permissions. For a restoration tool, this leaves significant gaps for an AI 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%, meaning the description adds no meaning to the parameters. The agent must infer from parameter names and types (e.g., artifactBundleId, versionNumber, message) without any textual explanation. The description does not clarify the role of 'message' or other details.

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 'Restore files from a prior artifact-bundle version' and identifies the resource as an artifact-bundle version. However, it does not explicitly differentiate 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 includes required permissions but provides no guidance on when to use this tool versus alternatives like 'rubrkit_restore_file_version'. No when-to-use or when-not-to-use context 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 carries the burden. It discloses that it creates a new version and requires 'files:write' permission, but lacks details on side effects (e.g., whether it overwrites or preserves the current version) or idempotency.

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

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

The description is a single sentence with no extraneous words. However, it lacks structure such as bullet points for parameters or separate sections.

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 absence of an output schema and zero parameter documentation, the description is incomplete. It does not explain what the tool returns, error conditions, or other contextual information.

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 provides no explanation of the four parameters (fileId, versionNumber, artifactBundleId, message). The description adds no meaning beyond the parameter names and 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 clearly states the action (restore), resource (file version), and mechanism (by creating a new version). It distinguishes from sibling tools like rubrkit_restore_artifact_bundle_version and rubrkit_list_file_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?

The description provides no guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions beyond the required permission.

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 discloses the HTTP DELETE method and required permission (artifact_bundles:write), but does not clarify if the operation is reversible or if it is a soft vs hard delete.

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 short sentences with no filler, efficiently conveying purpose and a key 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?

For a simple tool with one parameter and no output schema, the description is adequate but lacks behavioral context (e.g., soft vs hard delete) that would support agent decision-making.

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 beyond the parameter name; it only implies goldenCaseId is a path parameter via the endpoint.

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 'Retire a golden case' with the HTTP method and endpoint, distinguishing it from sibling tools like rubrkit_add_golden_case and rubrkit_list_golden_cases.

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 but gives no explicit guidance on when to use this tool vs alternatives 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?

With no annotations, the description discloses that this is a queue operation, calibrates baseline on first check, costs per repeat, and requires specific permissions. It lacks explicit mention of idempotency or side effects beyond costing audits, but covers key behavioral traits.

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 total: first states the action and endpoint, second adds calibration detail, third covers cost and permissions. No redundancy, front-loaded with the 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?

Commendable coverage of core details, but does not address the asynchronous nature (it queues the check) or need to poll for results, despite sibling poll_job tool existing. Lacks mention of return format or response 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 only parameter is driftMonitorId with no schema description (0% coverage). The description indirectly explains it via the endpoint path, but does not provide additional context like how to obtain it or its role beyond identification. Adequate but minimal.

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 queues a drift check immediately, distinguishing it from waiting for the schedule. It specifies the exact HTTP endpoint and action, leaving no ambiguity about the resource ('drift check on a drift monitor').

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 explains when to use this tool (immediate check instead of waiting for schedule) and mentions the first check calibrates baseline and costs an audit. It implies use when an immediate result is needed, but does not explicitly compare to siblings like read_drift_observations or list_drift_monitors.

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 must disclose behavior. It reveals the async nature, permission requirement, and default repeats for advanced mode. However, it lacks details on return value, error handling, or state changes, making coverage partial.

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 brief at two sentences plus a clause, with no unnecessary words. It front-loads the core purpose. However, the third sentence is slightly dense with parentheses, but overall 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?

With 15 parameters, 1 required, no output schema, and no annotations, the description is too sparse. It fails to explain many parameters, return behavior, or standard mode, making it inadequate for complete understanding.

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%, so the description must compensate. It only explains mode, baselineVersionId, candidateVersionId, and repeats (defaults). It omits 11 other parameters like artifactBundleId (required), testCases, and maxCases, providing insufficient guidance.

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 'Start an async eval run,' which is a specific verb and resource. It distinguishes this tool from siblings like rubrkit_list_evals or rubrkit_read_eval by indicating it initiates a run asynchronously.

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 usage context by requiring evals:run permission and explaining how to use advanced mode with baselineVersionId and candidateVersionId. However, it does not compare standard vs. advanced modes or mention when not to use this tool.

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 carries full burden. It states it 'searches' but does not disclose whether it returns snippets, how results are sorted, or any side effects. This is minimal behavioral disclosure.

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 that is front-loaded and free of fluff. However, it could add more useful detail without becoming 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?

Given the absence of output schema, annotations, and schema descriptions, the description is too minimal. It does not cover return format, pagination behavior, or any constraints beyond the schema.

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

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

Schema description coverage is 0%, but the description adds no meaning to the parameters 'query' and 'limit' beyond their names. No explanation of what constitutes a valid query or how limit affects results.

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 'search' and the target 'canonical docs/api Markdown guides and OpenAPI operation summaries', distinguishing it from siblings like rubrkit_read_api_doc which likely retrieves a specific 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?

The description gives no guidance on when to use this tool vs alternatives such as rubrkit_read_api_doc. It does not mention when not to use it or any prerequisites.

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 must fully disclose behavioral traits. It mentions it is a PATCH operation and requires specific permissions, but does not describe side effects (e.g., whether pausing stops monitoring, generates events, or affects other resources). No details on idempotency or limitations.

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, front-loaded with the action and endpoint. No unnecessary words. Efficient for the information provided.

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 mutation tool with two required parameters and no output schema, the description is adequate but basic. It provides action, resource, endpoint, and auth. Missing details on behavior (e.g., idempotency, return values, side effects) that would make it fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It implies the 'status' parameter accepts 'active' or 'paused' by stating the tool pauses or resumes, but does not explicitly map the enum values. It does not explain what 'driftMonitorId' refers to. Minimal added meaning 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 tool's purpose: 'Pause or resume a drift monitor'. It specifies the HTTP method and endpoint, which adds context. It is distinct from sibling tools like rubrkit_create_drift_monitor and rubrkit_list_drift_monitors.

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 mentions an auth requirement ('Requires artifact_bundles:write'), but does not explain when pausing vs resuming is appropriate or how it compares to other drift monitor operations.

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 explains key behavioral traits: the job is async, results are cached per account by content hash, the force flag bypasses cache, and it requires 'audits:run' permission for API keys. This adds significant value beyond the input schema.

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 are concise and front-loaded with the primary purpose. No unnecessary words, but could be slightly more structured for scanning.

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 (10 parameters, async behavior, no output schema), the description omits critical details: how to track the job (e.g., via rubrkit_poll_job), what the response looks like, and the meaning of missing parameters. This leaves the agent underinformed.

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?

Despite 0% schema description coverage, the description only explains the 'force' parameter (its CLI equivalent and effect). Nine other parameters (modelTier, rubricKey, etc.) are left unexplained, failing to compensate for the schema's lack of 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 'Start an async audit job', using a specific verb-resource pair. It is distinguishable from sibling tools like rubrkit_list_audits or rubrkit_read_audit which only read, not create jobs.

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

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

The description gives guidance on when to use the force flag ('to bypass the cache and run a fresh audit'), but does not indicate when to use this tool versus alternatives. Since no sibling tool starts an audit, the usage context is implied.

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 must fully disclose behavioral traits. It indicates a write operation and a permission requirement, but lacks details on idempotency, side effects (e.g., does it overwrite the previous version?), failure modes, or the nature of 'editable version.' For a mutation tool, 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 at two sentences, efficiently communicating the core action and a permission requirement. However, it sacrifices necessary detail for brevity, especially given the absence of schema descriptions. It is well-front-loaded but could be expanded without becoming 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?

Given the five parameters, no schema descriptions, no output schema, and no annotations, the description is incomplete. It does not explain the purpose of the 'message' and 'mediaType' fields, nor does it specify acceptable content formats. The agent has insufficient context to correctly invoke the tool without external 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 0% description coverage for its parameters, yet the description adds no explanations for any of the five parameters (fileId, content, message, mediaType, artifactBundleId). The description fails to clarify the role of 'message' or 'mediaType', leaving the agent without guidance on how to fill the content field.

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 the action is to 'write a new editable version for a file', which clearly indicates updating an existing file's content. However, it does not explicitly differentiate from the sibling rubrkit_upload_artifact_files (which likely creates new files) or rubrkit_restore_file_version (which restores a previous version), leaving ambiguity about when to use this tool over alternatives.

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 only usage guidance is the permission requirement 'Requires files:write for API keys.' There is no mention of when to use this tool versus siblings like rubrkit_upload_artifact_files or rubrkit_restore_file_version, nor any exclusion criteria or prerequisites (e.g., that the file must already exist in the bundle).

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 must fully cover behavioral traits. It only states the action and permission, omitting details like idempotency, file overwrite behavior, bundle existence validation, size limits, or error conditions. The term 'text files' may mislead if binary content is allowed via mediaType.

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 and front-loaded with the main verb, but it is too brief to be informative. While concise, it sacrifices necessary details, making it minimally adequate.

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 schema descriptions, no output schema, and only 2 parameters, the description is severely incomplete. It fails to explain return values, error handling, or parameter details, leaving the agent with little usable 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?

The input schema has 0% description coverage, yet the description adds no information about the parameters (artifactBundleId, files, or sub-properties like path, content, message). The agent must infer meaning solely from parameter names, 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 the action 'Upload one or more text files into an artifact bundle,' specifying the verb and resource. It distinguishes from siblings like 'create_artifact_bundle' (create bundle) and 'update_artifact_file' (modify existing file), though it does not explicitly contrast with update or mention that upload creates new 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 mentions a permission requirement ('Requires files:write') but provides no guidance on when to use this tool versus alternatives like 'update_artifact_file' or 'create_artifact_bundle'. No context on prerequisites, limitations, or typical use cases.

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