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

Despite no annotations, the description discloses key behavioral constraints: required existence, uniqueness, and special handling for ALTR collections; output schema exists so return values need not be 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?

Two concise, front-loaded sentences with no wasted words.

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

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

Fully covers the tool's preconditions and constraints; with output schema present, no further details are 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?

Adds meaning beyond schema by stating that classifiers must already exist and not be duplicates, complementing the schema's type descriptions.

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

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

The description clearly states the action (add) and the resource (classifiers to an existing collection), distinguishing it from siblings like remove_classifiers_from_collection.

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

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

Provides specific preconditions (classifiers must exist, not already in collection) and an exclusion (ALTR managed collections cannot be appended), but does not explicitly name alternative tools.

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

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

With no annotations, the description adds important behavioral info: auto-split for >99 rules, batch nature, and prerequisite. Lacks details on error handling or idempotency, but sufficient for basic 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?

Two focused paragraphs: first states purpose and prerequisite, second details rules structure and batch limit. No wasted words.

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

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

Given sibling tools and output schema existence, the description covers key aspects: operation, constraints, prerequisite, and parameter format. No gaps identified.

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?

Adds significant meaning beyond schema: 'Raw policy ID from `get_policies`. Do not URL-encode.' and rules explanation (dict structure, alternative JSON string), enhancing agent understanding.

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

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

The description clearly states the action ('Add one or more masking rules'), the resource ('to a policy'), and the batching capability. It distinguishes from 'create_policy' and 'delete_rule' by 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?

Provides prerequisite ('A policy must already exist... see `create_policy`') and batch limit. Does not explicitly exclude scenarios for using 'update_rule' or other alternatives, but the context is clear.

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 does not disclose behavioral traits such as side effects, permission requirements, or whether the action is reversible. The one-liner is insufficient for understanding the tool's impact.

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, front-loaded sentence with no extraneous words. Every word is essential and the structure is optimal for quick understanding.

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 having an output schema, the description omits important context such as the outcome of approval, potential errors, and lifecycle considerations. It is too minimal for a tool that modifies state.

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?

Both parameters are fully described in the schema (100% coverage). The description adds no additional meaning beyond the schema; it merely restates the tool's purpose. Baseline score of 3 is appropriate.

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 'Approve' and the resource 'pending access request', making the purpose unambiguous. It is distinct from sibling tools like deny_access_request and cancel_access_request.

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

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

No guidance on when to use this tool versus alternatives (e.g., deny_access_request). The description does not specify prerequisites like the request must be pending, nor does it indicate when approval 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?

Discloses that archiving is a soft-delete, that definitions become hidden from normal listings, and that restoration is possible via a sibling tool. This adds value beyond the destructiveHint annotation, which only indicates potential data loss.

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. Front-loaded with the core action and immediately clarifies soft-delete behavior.

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?

Complete for a single-parameter tool with output schema. Covers behavior, visibility, and recovery path.

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

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

Schema coverage is 100%, with the parameter description already clear. The description does not add additional semantics but is sufficient given the simplicity.

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 the tool archives (soft-deletes) an audit report definition, distinguishing it from related tools like restore_report_definition. The verb 'archive' and resource 'audit report definition' are specific and accurate.

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

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

Explicitly describes when to use (to hide from listings without permanent deletion) and mentions the alternative tool for restoration. Could be slightly improved by contrasting with permanent deletion, but it is effective.

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 for behavioral disclosure. It only states the action without revealing side effects, permissions needed, whether the cancellation is reversible, or any notification behavior.

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

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

The description is a single, clear sentence with no wasted words. It is efficient, though it could benefit from slightly more structure (e.g., listing required preconditions).

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 having an output schema, the description lacks completeness. It does not explain what happens on success or failure, nor does it clarify that only the creator can cancel, which is important context for a tool with a 'you created' scope.

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?

Both parameters are fully documented in the input schema (100% coverage). The description adds no additional meaning, so a baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Cancel' and identifies the resource as 'an access request you created,' which clearly distinguishes it from sibling tools like 'approve_access_request' or 'deny_access_request.'

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 or when alternatives are appropriate. It lacks explicit context, exclusions, or references to related tools.

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

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

With no annotations provided, the description fully discloses behavioral aspects: it registers a Snowflake tag as a first-class ALTR object, creates a `tag_group_id` and masking configuration, and automatically resolves the friendly database name. It also lists related tools for inspection and editing, giving a complete picture of 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?

The description is well-structured: it opens with a clear purpose statement, then provides platform-specific guidance, explains workflow, and ends with a behavioral note. It is reasonably concise, though the Databricks advice is repeated slightly. Overall, it is 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 complexity and the lack of annotations, the description is complete. It explains the tool's role within the ALTR ecosystem, prerequisites, post-connection effects, and platform-specific behavior. The presence of an output schema (not shown but indicated) complements the description, making it fully informative for 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 100%, so the baseline is 3. The description adds value by explaining that `database_name` is a friendly name from `get_databases` and that the tool auto-resolves it, but it does not elaborate on `schema_name` or `tag_name` beyond the schema. The added context is useful but not extensive.

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: connecting a Snowflake tag to ALTR for use in masking policies. It specifies the action (connect), the resource (Snowflake tag), and the intended use, effectively distinguishing it from sibling tools by explicitly stating it is Snowflake-only.

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 explicit usage guidance: 'SNOWFLAKE ONLY — do NOT use for Databricks.' It explains why Databricks tags are not applicable and directs the agent to use `create_policy` instead. It also outlines prerequisites (tag must exist in Snowflake) and post-connection behavior, making when-to-use and when-not-to-use clear.

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 request requires approval before access is granted (behavioral trait). However, it lacks details on side effects, idempotency, or required permissions. Given the absence of annotations, this is adequate but not exhaustive.

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 reasonably concise, with the main purpose stated first, followed by a usage hint and structured parameter explanation. Every sentence adds value, though the rules explanation could be slightly more compact. Overall, it is well-organized 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?

The tool has 7 parameters (4 required) and an output schema. The description covers the core workflow and the complex rules parameter, but it could mention the relationship with other access request tools (e.g., approve, cancel) to provide better context. It is functionally complete for basic use but lacks some contextual depth.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the structure of the 'rules' parameter with actors, objects, and access fields, which goes beyond the schema's generic description. Other parameters are well-described in schema. This extra detail justifies a 4.

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

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

The description clearly states it creates a new access request for data access approval, which is specific and action-oriented. However, among many 'create_*' sibling tools, it doesn't explicitly distinguish itself from others like create_database, but the context of access approval provides some 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?

It gives a pointer to use get_access_requests to check status after creation, which is helpful. But it does not specify when to use this tool versus related tools like approve_access_request, cancel_access_request, or deny_access_request. Usage context is implied but not explicit.

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

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

No annotations are provided, so the description must disclose behavioral traits. The description only states creation and that classifiers can be added to collections and used in jobs. It does not mention side effects, idempotency, error handling, or what happens on duplicate names. This is insufficient for a creation tool.

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

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

Two sentences: first sentence states the core action and resource, second provides usage context. Extremely concise with no wasted words.

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

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

Given the tool has 5 required parameters, an output schema, and no annotations, the description is brief but covers the core purpose and usage scenario. However, it lacks behavioral and lifecycle details that would help an agent use it correctly. Output schema exists but description doesn't mention it.

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

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

Schema coverage is 100% with each parameter already described in the input schema. The description adds no specific parameter details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool creates a custom data classifier for specific patterns, and distinguishes from built-in classifiers by mentioning when to use (when built-in don't cover data types). It also mentions that custom classifiers can be added to collections and used in jobs, which adds 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?

Explicitly says 'Use when ALTR's built-in classifiers don't cover your data types,' providing clear when-to-use guidance. However, it does not specify when not to use or mention alternatives beyond built-in classifiers.

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 describes the creation action and grouping behavior, but doesn't disclose permissions, side effects, or reversibility. It's adequate but not rich.

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

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

The description is well-structured and concise, with a clear purpose statement, explanation of the collection, and a typical workflow. Every sentence 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 presence of an output schema, the description doesn't need to explain return values. It provides workflow context and integrates with sibling tools well. Minor gap in not describing permission requirements or destruction 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?

Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, e.g., 'Unique name' slightly clarifies uniqueness, but doesn't elaborate on format or constraints.

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

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

The description clearly states the tool creates a classifier collection for automated data discovery, distinguishing it from sibling tools like add_classifiers_to_collection and create_job by placing it in a typical workflow.

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 explicitly outlines a typical workflow: create a collection (or use existing ALTR Managed), then use in create_job, then review with get_classification_report. This provides clear when-to-use and alternative 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 carries the full burden. It discloses that the tool creates a database connection, lists authentication options, and recommends verification. It does not mention potential errors or permissions but provides sufficient behavioral context for a creation tool.

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

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

The description is concise and well-structured with a clear opening sentence followed by bullet points for authentication modes. Every sentence adds value, and there is no redundancy or fluff.

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 8 parameters and an output schema, the description covers authentication modes and post-creation steps. It could mention what happens on failure or required permissions, but it is adequate for a creation tool among many 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 coverage is 100%, but the description adds significant value by grouping parameters into two authentication modes, explaining that 'service_user_id' comes from 'get_service_users', and clarifying that hostname/port are only for password auth. This guidance is not evident from schema descriptions 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 clearly states 'Connect a new data source to the ALTR platform' with a specific verb and resource. It distinguishes from siblings like 'create_databricks_database' by focusing on generic database creation and detailing two authentication modes.

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 two authentication modes with conditions and suggests using 'get_databases' post-creation. However, it does not explicitly exclude use cases or compare to alternative tools like 'create_databricks_database'.

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

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

With no annotations, the description bears full burden. It discloses creation of a connection and two auth modes, but does not discuss idempotency, overwrite behavior, or side effects. Sufficient for basic usage but lacks depth for a creation tool.

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

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

The description is concise with two short paragraphs, uses numbered list for auth modes, and front-loads the main action. Every sentence 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?

Covers essential aspects: purpose, auth options, and post-creation step. Lacks explicit guidance on mutual exclusivity of password vs. service user fields, but that is inferable from schema. With output schema present, return values need not be explained. Adequate for an agent to operate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters into auth modes (service user vs. password) and indicating that 'service_user_id' comes from 'get_service_users'. This contextualizes parameter relationships beyond the schema descriptions.

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

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

The description clearly states the tool connects a Databricks workspace to the ALTR platform, with specific verb 'Connect'. It distinguishes from sibling tools like 'create_databricks_job' or 'create_database' by focusing on the connection setup.

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

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

Provides clear context on when to use (to connect a Databricks workspace) and recommends a preferred auth mode. Includes a follow-up step to use 'get_databases' to confirm creation. Does not explicitly state when not to use or list alternatives, but the context is adequate.

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 of behavioral disclosure. It explains that the tool runs asynchronously, requires polling, and performs a catalog scan. It does not mention potential limitations or error states, but the async behavior and outcome are well-communicated.

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 three sentences long, each serving a distinct purpose: stating the action, detailing the scan, and explaining the async workflow. No redundant information, and the most important elements are front-loaded.

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

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

Given the tool has a single parameter and an output schema, the description covers the essential aspects: purpose, async behavior, and follow-up tools. It does not discuss error handling or edge cases, but for a straightforward creation tool, it is sufficiently 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?

The only parameter, database_id, has 100% schema description coverage. The tool description does not add additional details beyond what the schema provides, but it correctly integrates the parameter into the overall task. A score of 3 is appropriate given high schema coverage.

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

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

The description clearly states that the tool runs a GDLP classification scan on a Databricks database, specifying the verb 'Run', the resource 'Databricks database', and the action 'scan to identify sensitive data columns'. It distinguishes itself from siblings like 'create_job' and 'create_databricks_database' by being specific to classification scans.

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 indicates when to use the tool (to run a classification scan) and provides clear follow-up steps: use 'get_jobs' to poll and 'get_classification_report' to view results. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for an agent to decide.

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

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

No annotations provided, so description carries burden. It discloses asynchronous behavior (10-30+ minutes) and recommends polling. Could mention read-only nature, but still informative.

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 paragraphs, front-loaded with main purpose. No filler. 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?

Covers purpose, async behavior, follow-up tools. Output schema exists, so return values need not be explained. Complete for a 3-param tool with no annotations.

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

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

Schema coverage is 100%; description adds little beyond schema for parameters (e.g., 'classifiers in the specified collection' for collection_name). Baseline score of 3 applies.

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

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

The description clearly states it runs an automated classification scan to discover sensitive data. It specifies the resource (database) and action (scan), and differentiates from siblings like create_classifier and create_database.

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

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

Provides clear context: scans database columns using classifiers in a collection. Mentions asynchronous nature and suggests follow-up tools (get_jobs, get_classification_report). Does not explicitly exclude alternatives, but guidance is adequate.

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 exist, so description must carry behavioral burden. It only repeats schema constraints on name/namespace but does not disclose side effects, duplicate handling, or permissions required for creation.

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

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

The description is concise with two short, front-loaded sentences. No extraneous information.

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

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

While an output schema exists, the description lacks context on prerequisites, error cases, or when to use this over sibling tools. Minimal completeness for a key-creation tool.

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

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

Schema coverage is 100% and descriptions already provided. The tool description adds no new meaning beyond what the schema states regarding namespace and name constraints.

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

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

The description clearly states it creates a new FPE encryption key, specifying the resource (key) and action (create). It is distinct from sibling tools like create_tweak or deactivate_key.

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 explicit guidance on when to use this tool versus alternatives (e.g., create_tweak or rotate_key). The context of encryption key creation is implied but not elaborated.

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 does not disclose behavioral traits such as side effects, required permissions, or whether the operation is destructive. The description focuses on rule structure but omits 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?

The description is concise, with a clear purpose sentence followed by a structured bullet list for the rules parameter. It is front-loaded and well-organized, though it could be slightly more compact without losing clarity.

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 (7 params, 6 required, no output schema described but exists), the description covers the core purpose and rules structure well. However, it lacks information about return values, error conditions, or prerequisites. Since output schema exists, return value explanation is not required, but the description could still mention that it returns the created policy.

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 100%, so baseline is 3. The description adds significant value by detailing the exact structure of the 'rules' parameter—specifying required fields (type, actors, objects) with subfield types and constraints (e.g., 'condition': 'equals'). This clarifies what would otherwise be vague 'List of OLTP access rule objects' in 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 states 'Create an access management policy for an OLTP datasource,' providing a specific verb ('Create'), resource ('access management policy'), and context ('OLTP datasource'). This clearly distinguishes it from sibling tools like 'create_policy' (general) and 'create_snowflake_access_policy' (Snowflake-specific).

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 OLTP datasources but does not explicitly state when to use this tool versus alternatives (e.g., 'create_policy', 'create_snowflake_access_policy'). There is no guidance on prerequisites or scenarios where this tool 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?

No annotations provided, so description carries full burden. It discloses that until rules are added, all users see NULL for tagged columns. Explains per-platform behavior: Snowflake tags are connected objects, Databricks tags are raw strings. Also warns about policy uniqueness per tag.

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?

Description is long but well-structured with clear sections for purpose, platform differences, and masking levels. It is front-loaded with key information. The masking levels list is necessary reference info, so no waste.

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 complexity with platform differences and no annotations, description covers all necessary aspects: purpose, prerequisites, post-creation steps, parameter nuances, and available masking levels. Output schema exists but doesn't need return value explanation.

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

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

Schema coverage is 100%, but description adds crucial context beyond schema: case-sensitivity for Snowflake tag, requirement for 'policy_type' only for Databricks, 'database_ids' must be a list even for single IDs, and connection prerequisites. This significantly aids correct parameter usage.

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

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

The description clearly states 'Create an empty masking policy for a specific tag' and explains its role controlling data masking. It distinguishes from sibling tools like 'add_rules' and 'get_policies', noting that rules are added later and conflicts should be checked first.

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

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

Explicitly advises checking 'get_policies' first to avoid conflicts and using 'add_rules' after creation. Provides platform-specific guidance: for Snowflake, must call 'connect_tag' first; for Databricks, must not call 'connect_tag' and must set 'policy_type' to 'PUSHDOWN' and provide 'database_ids'.

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 given, so the description must fully disclose behavior. It only states 'add a comment' without detailing idempotency, permissions, side effects, or return values, leaving critical gaps.

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, short and to the point. While efficient, it could be expanded slightly to improve completeness 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?

Despite having an output schema, the description lacks any mention of what the tool returns (e.g., the created comment or success status) and does not cover behavioral context like required permissions or error conditions.

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 covers all three parameters with descriptions, achieving 100% schema coverage. The description adds no extra meaning beyond the schema, so baseline score 3 is appropriate.

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 'Add a comment to a report instance' clearly specifies the action (add) and the resource (comment to a report instance), distinguishing it from sibling tools like create_report_definition or create_report_sign_off.

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 such as pin_report_comment or list_report_comments, nor any prerequisites like requiring an existing report instance.

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 bears full responsibility for disclosing behavioral traits. It states it creates a new definition but does not mention whether it is idempotent, what happens if a definition with the same name exists, authentication requirements, or any side effects. This lack of detail leaves the agent uninformed about important behavioral boundaries.

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

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

The description is extremely concise: two sentences plus a header. The first sentence states the primary purpose, and the second adds immediate next-step guidance. Every word earns its place with zero 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's complexity (10 parameters) and the presence of an output schema (not shown), the description covers the main creation intent and workflow linkage. It could mention that the tool returns the created definition object, but since output schema exists, it is not strictly required. Overall, it provides sufficient context for an agent to understand and correctly invoke the 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?

The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing a high-level overview of what the parameters collectively achieve and includes extensive, practical examples for the 'schedule_cron' parameter (e.g., common cron patterns) and clear shapes for 'delivery' and 'filters'. This goes beyond the schema's individual descriptions.

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

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

The description clearly states the action ('Create') and the resource ('new audit report definition'), with a verb+resource structure. It also distinguishes from sibling tool 'trigger_report_definition' by mentioning the explicit next step, 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 provides clear guidance on the typical workflow by stating 'After creating, use trigger_report_definition to generate a report on demand.' This implies when to use this tool and suggests an alternative for report generation. However, it does not explicitly mention when not to use it or contrast with other creation tools in the sibling list.

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 mentions recording approval and enabling pinning, but does not reveal whether multiple sign-offs are allowed, if sign-offs can be undone, required permissions, or error scenarios. This is insufficient for a mutation tool.

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

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

The description is only two sentences, front-loading the main purpose with no extraneous information. It is efficiently structured.

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

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

Given the presence of an output schema (so return values are covered) and full parameter schema, the description provides a basic overview and a post-condition. However, it lacks important behavioral context such as idempotency, permissions, and error handling, making it adequate but 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 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter. It does not explain the relationship between action, attestation, and comments.

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 signs off/reports approval on a report instance, using specific verbs ('Sign off', 'Records approval') and resource ('report instance'). It distinguishes from sibling tools like create_report_comment (creates comments) and pin_report_comment (pins after sign-off).

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 a sequence (sign off before pinning comments) but does not explicitly state when to use this tool vs alternatives like list_report_sign_offs or get_report_sign_off. It lacks explicit when-to-use or when-not-to-use 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, and the description only states the action without any behavioral traits (e.g., idempotency, side effects, authentication requirements, rate limits). The agent creation process and implications are not disclosed.

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, which is concise but lacks structure and sufficient detail for a tool with 5 parameters. Every sentence should add value; this one is too minimal.

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 having an output schema, the description is incomplete for a creation tool. It does not mention what is returned (e.g., agent ID) or any post-creation steps. The tool complexity and lack of annotations warrant more context.

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

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

The input schema describes all parameters with 100% coverage, so the description adds no additional meaning beyond the schema. Baseline score is 3.

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 'Create a new ALTR agent' uses a specific verb and resource, clearly indicating the tool's purpose. It distinguishes from sibling creation tools like create_sc_agent_task or create_sc_sidecar by the resource type, but does not explicitly differentiate them.

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 given on when to use this tool versus alternatives, such as create_sc_agent_task or create_sc_service_user. There is no mention of prerequisites or context for invocation.

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

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

With no annotations, the description carries full burden. It reveals that configuration depends on agent type, explains schedule format, and notes conditional service_user requirements. However, it does not disclose potential side effects, permissions, or error conditions.

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 structured into clear sections and front-loads the main purpose. It is comprehensive but slightly lengthy; every sentence earns its place, though minor trimming could improve 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 tool's complexity (7 params, conditional logic), the description thoroughly covers all parameters and usage scenarios. An output schema exists, so return values need not be explained. Contextually 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 description coverage is 100%, but the description adds significant meaning: it explains the configuration structure per agent type, schedule format, and service_user conditions, far exceeding schema 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 'Create a task for an agent' and specifies that the task runs against a specific repo on a schedule. It distinguishes from sibling tools like delete_sc_agent_task, update_sc_agent_task, and list_sc_agent_tasks by focusing on creation and configuration 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 explicit when-to-use guidance, including checking agent type with get_sc_agent first. It details configuration per agent type (CLASSIFIER vs SIS) and specifies fields to include or avoid, serving as clear 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 are provided, so the description carries full burden. It only says 'Create' without disclosing behavioral traits such as idempotency, permissions required, side effects, or reversibility. This is insufficient for 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 a single sentence, concise and front-loaded. It efficiently states the purpose, though it could benefit from more context 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 complexity (5 parameters, 4 required, output schema exists), the description lacks essential context for a creation tool, such as behavior on duplicate names, default values, or required permissions. The presence of an output schema mitigates return value explanation but not the broader completeness gap.

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

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

Schema coverage is 100% with all parameters described. The description adds no additional meaning beyond the schema, so it meets the baseline expectation but does not exceed it.

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

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

The description 'Create a new database repository for sidecar proxying' clearly states the action and resource. It distinguishes this tool from sibling creation tools like create_database or create_sc_sidecar by specifying 'database repository for sidecar proxying'.

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 mention prerequisites or constraints. It simply states the action, leaving the agent without context for appropriate invocation.

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

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

Discloses creation (write) and credential constraint, but no annotations exist. Lacks details on idempotency, conflict behavior, or side effects. Output schema exists but not referenced.

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, no wasted words. Purpose and key constraint 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?

Covers essential info for a simple creation tool with 4 params. Output schema exists, so return values need not be explained. Could mention idempotency but not critical.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by clarifying the 'exactly one' constraint for credential parameters, which is not in 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?

Clearly states verb 'Create' and resource 'repo user', with explicit constraint about credential reference. Distinguishes from siblings like create_sc_repo and create_sc_service_user.

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

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

Provides explicit guidance on mutual exclusivity of credential methods ('Provide exactly one of...'). Lacks guidance on when to use this over alternative tools like create_sc_service_user.

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 the creation action and the mutual exclusivity constraint, but lacks information on permissions, side effects, error conditions, or the return value (though output schema exists). This is insufficient for safe invocation.

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 purpose, and a clear constraint. No redundant or unnecessary information. Very efficient.

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

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

The description does not explain prerequisites (e.g., repository must exist), the purpose of the service user, or the format of the credential parameters. Although an output schema exists, the description lacks context 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 100%, but the description adds critical semantic nuance: the mutual exclusivity of 'aws_secrets_manager' and 'azure_key_vault' parameters, which is not enforced by the schema. This adds value beyond the schema descriptions.

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

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

The description clearly states the verb 'create' and the resource 'service user for a repository', distinguishing it from sibling tools like 'delete_sc_service_user' or 'create_sc_repo_user'. The additional constraint about providing exactly one credential type adds 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 explicitly says 'Provide exactly one of aws_secrets_manager or azure_key_vault', which is a crucial usage constraint. However, it does not compare to alternatives like 'create_sc_repo_user' or explain when a service user 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?

No annotations are provided, and the description fails to disclose any behavioral traits such as idempotency, permissions, side effects, or rate limits. For a mutation tool, this is a critical gap.

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

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

The description is extremely concise—one sentence—but for a 7-parameter creation tool, it is arguably too brief and lacks contextual value. It is not wasteful but could be more informative.

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 (7 parameters, 2 required, output schema present), the description is too sparse. It omits high-level context such as the role of a sidecar, prerequisites, or relationship to sibling tools like create_sc_sidecar_binding.

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 has 100% coverage with descriptions for all 7 parameters, so the description need not add parameter info. It does not add any additional meaning beyond what the schema provides, meeting the baseline.

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 'Create a new sidecar' directly states the action (create) and resource (sidecar). It is specific and not a tautology, but it lacks differentiation from sibling tools that create other resources like agents or repos.

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. No prerequisites, exclusions, or sibling tool comparisons are mentioned, leaving the agent without context for appropriate invocation.

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

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

No annotations provided. Description does not disclose side effects (e.g., idempotency, overwriting), required permissions, or behavior on failure. Output schema exists but description does not clarify return value.

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, efficient and front-loaded. Lacks some detail but avoids verbosity.

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?

Minimal description; missing usage context and behavioral details. Output schema exists but description does not leverage it to reduce burden. Incomplete for a create tool with no annotations.

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 descriptions cover all parameters (sidecar_id, port, repo_name) with basic details. Description adds no extra semantics beyond schema, so at baseline 3 given 100% coverage.

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

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

Description clearly states 'Bind a repository to a sidecar listener port,' specifying verb and resource. Differentiates from sibling tools like create_sc_sidecar (creates sidecar) and list_sc_sidecar_bindings/delete_sc_sidecar_binding.

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, no prerequisites mentioned (e.g., sidecar must exist, port must be unused), and no conditions for successful binding.

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 details the rule structure but omits behavioral aspects like immediate enforcement, permissions required, or whether creation overrides existing policies. Basic context is given but not comprehensive.

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 well-structured with a clear first sentence and detailed bullet points for rules. It is not overly verbose, though some redundancy exists (e.g., repeating 'list of dicts' pattern could be more 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 an output schema exists and parameters have 100% coverage, the description covers the essential purpose and the complex rule structure. It lacks details on error cases or output format, but the presence of an output schema mitigates that.

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

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

Schema coverage is 100%, providing a baseline of 3. The description adds significant value for the complex 'rules' parameter by specifying required fields (actors, objects, access, tagged_objects) and their subtypes, which is beyond the schema's generic 'list of objects' definition.

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 Snowflake access policy and specifies its components (roles, objects, access). It distinguishes itself from siblings like create_oltp_access_policy and update_snowflake_access_policy by targeting Snowflake datasources.

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 what the policy does (enforced by ALTR, scheduled checks) but does not explicitly compare to alternatives like create_oltp_access_policy or update_snowflake_access_policy. It lacks guidance on when to use this tool vs others.

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 behavioral disclosure. It mentions the naming constraint and that it generates a random value, but does not specify side effects, idempotency, failure modes, or permission requirements. Minimal behavioral context beyond the core operation.

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

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

The description is extremely concise (two sentences) and front-loaded with the core action. Every sentence adds necessary information, no redundancy or fluff.

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 (one parameter, no annotations, output schema exists), the description covers the essential purpose and naming constraint. It could mention error handling for duplicate names or clarify the return value, but the presence of an output schema mitigates that need.

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 100%, so the parameter is already well-documented. The description adds context that the tweak is for FPE, which clarifies the parameter's role, but mostly repeats the schema's constraint about leading/trailing spaces. Baseline 3 is appropriate.

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

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

The description clearly states it creates a new FPE tweak, explaining it generates a named random value for format-preserving encryption. It distinguishes from sibling tools like create_key by specifying the FPE 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?

Usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives (e.g., create_key) or exclusions. The description lacks when-not-to-use or 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?

Annotations provide destructiveHint=true, but description adds valuable context: invalid tokens are silently ignored, deterministic token re-tokenization behavior, and a maximum of 1024 values per call. This goes beyond the annotation to disclose important operational details.

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

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

The description is concise, with three clear points in separate paragraphs. No unnecessary words. Front-loaded with the primary action, then key behaviors. 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?

For a delete operation, the description covers what happens (delete), edge cases (invalid tokens, re-tokenization), and limits (1024). Output schema exists, so return format is not needed. Complete for effective 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 coverage is 100% and describes the 'tokens' parameter as a dict. Description adds a usage example and the constraint of max 1024 values, which complements the schema. The description enhances understanding of the parameter's semantics.

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 'Delete critical tokens, removing them from the token store.' It specifies the resource (critical tokens) and action (delete), and distinguishes from sibling delete tools like 'vault_delete_tokens' by the 'critical' qualifier and additional behavior 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 does not explicitly state when to use this tool over alternatives like 'vault_delete_tokens'. It implies use for critical tokens but lacks direct comparison or exclusion criteria. The behavior details (silent ignore, re-tokenization) provide some context but no when-to-use 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?

Beyond the `readOnlyHint` annotation, the description adds important behavioral details: failure on invalid tokens, token format requirements, and limits. There is no contradiction with annotations, and the agent understands both the safety profile and 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 only three sentences, each serving a clear purpose: state the action, explain failure and alternative, and provide operational constraints. It is front-loaded 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 presence of an output schema, the description covers purpose, usage guidelines, parameter semantics, and behavioral aspects comprehensively. It addresses failure modes, limits, and distinguishes from a sibling, making it self-contained for an 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?

The input schema already fully describes the parameter with an example. The description adds value by specifying the token format and validation criteria (64+ chars, `token_XXXX...`), which is not in the schema, raising it above the baseline of 3.

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 ('Detokenize critical tokens to recover plaintext values') and distinguishes this tool from the sibling `critical_partial_detokenize` by specifying that it fails on non-valid tokens, while the partial version handles mixed inputs.

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 explicitly advises when to use this tool (all tokens are valid critical tokens) and when not (mixed inputs, recommending `critical_partial_detokenize`). It also provides constraints: maximum 1024 values and case-sensitivity, leaving no ambiguity.

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 only provide readOnlyHint=true. The description adds significant behavioral details: it passes through non-tokens, does not fail on mixed input, and has a call limit. No contradictions with annotations.

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

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

The description is very concise: one sentence for purpose, one contrasting with sibling, and one for a constraint. Front-loaded with the core action. No extraneous content.

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

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

Covers purpose, usage, constraints, and behavior. Could mention error handling for invalid tokens, but output schema likely provides return type details. Overall sufficient for the tool's complexity.

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

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

Schema coverage is 100% and already includes parameter descriptions (e.g., 'Non-token values are passed through'). The tool description only restates this concept without adding new parameter-specific meaning, so baseline score of 3 is appropriate.

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 detokenizes critical tokens while passing non-token values through unchanged. It distinguishes itself from sibling 'critical_detokenize' by noting it does not fail on non-tokens, providing a specific verb-resource combination.

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

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

Explicitly contrasts with 'critical_detokenize', telling when to use this tool (when non-token values may be present). Also mentions a maximum of 1024 values per call, providing clear usage constraints.

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

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

Discloses token format (token_XXXX..., 64+ chars), detokenization ability, deterministic vs random option, and size limits. No contradictions with annotations (none provided).

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?

Well-structured with clear sections, front-loading the main action. Each sentence adds value, no redundancy. Concise yet complete.

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 but high schema coverage and presence of output schema, the description sufficiently covers behavior, constraints, and parameters. All necessary context for correct invocation is present.

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 covers both parameters (values, deterministic) with descriptions. Description adds context: token format, deterministic behavior effect, and 128 code units limit per value, enhancing understanding beyond schema.

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

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

Description clearly states it tokenizes plaintext using ALTR critical tokenization, with format and behavioral details. It distinguishes from siblings like vault_tokenize by specifying 'critical tokenization', though not explicitly contrasting.

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

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

Provides constraints (max 1024 values, 128 UTF-8 code units per value) and mentions detokenization capability. Does not explicitly state when to use this tool vs alternatives like vault_tokenize or critical_detokenize.

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?

Beyond the destructiveHint annotation, the description explains that deactivated keys cannot be used for new encryption operations, adding valuable 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, front-loaded with the action, no wasted words.

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

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

For a simple deactivation tool with annotations and output schema, the description provides essential context: the effect and a tip for obtaining the required parameter. 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?

Input schema has 100% description coverage for all three parameters. The description adds no additional parameter information beyond the schema, so baseline 3 is appropriate.

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 deactivates a specific version of an FPE key, and explains the consequence. This distinguishes it from siblings like deactivate_tweak or rotate_key.

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

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

Provides guidance to use get_key to find the sequence identifier, which is a prerequisite. Does not explicitly mention when not to use, but context is clear.

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?

Beyond the destructiveHint annotation, the description adds that deactivated tweaks are prevented from use in new FPE operations, clarifying the behavioral impact. No contradiction with annotations found.

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

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

Two sentences with no unnecessary words. The action is stated first, followed by a key consequence and a helpful pointer. Highly 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?

For a simple state-change tool with two parameters and an output schema, the description covers the purpose, consequence, and parameter discovery. It lacks details on return values or authorization, but the output schema mitigates the former.

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 100% coverage, so parameters are already well-described. The description adds no new parameter details beyond referencing 'get_tweak' for the sequence identifier, but this does not enhance the semantic understanding of the parameters themselves.

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 'Deactivate' and the resource 'specific version of an FPE tweak'. It distinguishes from sibling tools like 'delete_tweak' and 'deactivate_key' by specifying the exact resource and action.

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 that deactivated tweaks cannot be used for new FPE operations, providing consequence. It also explicitly advises using 'get_tweak' to discover the sequence identifier, guiding the agent on parameter acquisition.

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

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

The description correctly indicates the destructive nature (consistent with annotations), but adds no additional behavioral details such as side effects, reversibility, or required permissions. With annotations already setting destructiveHint: true, the description is neutral but not informative beyond that.

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 4 words, front-loading the action and resource. However, it could include a bit more context without significantly increasing length, such as noting the requirement for both parameters.

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 presence of an output schema and annotations, the description still lacks completeness. It does not explain return values, prerequisites (e.g., the instance must exist), or potential consequences. For a destructive tool, this leaves important gaps.

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 100% coverage with descriptions for both agent_id and instance_id. The tool description does not add any additional meaning or usage context for the parameters, so it meets the baseline without improvement.

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 'Delete' and the resource 'agent instance', making the tool's purpose unambiguous. It distinguishes itself from sibling delete tools like delete_classifier or delete_collection by specifying the resource type.

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 (e.g., deactivating instead of deleting), nor are there prerequisites or conditions for usage. The description lacks any context about appropriate scenarios or exclusions.

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

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

While the destructiveHint annotation already indicates destructive behavior, the description adds important behavioral details: the tool cannot delete ALTR managed classifiers, and it is restricted to user-created classifiers. This provides context beyond the annotation.

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 highly concise, consisting of two short sentences. It front-loads the primary purpose and immediately follows with usage restrictions, with no wasted words.

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

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

The tool is simple (one parameter, destructive), and the description covers purpose and usage restrictions. An output schema exists, so return values are not needed in the description. The description adequately addresses the tool's scope without missing critical 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 already fully describes the single parameter (classifier_name) with a clear description. The tool description adds no additional parameter semantics, so the baseline score of 3 applies given the high schema coverage.

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

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

The description clearly states the tool removes a custom classifier, using the verb 'Remove' and specifying the resource 'custom classifier you created'. It distinguishes itself from other delete tools by clarifying it only applies to user-created classifiers, not ALTR managed ones.

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 explicitly states when to use the tool ('Only use for classifiers you created with `create_classifier`') and when not to use it ('Cannot delete ALTR managed classifiers'), providing clear guidance on appropriate contexts.

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 already signal destructiveness with destructiveHint=true. The description adds valuable behavioral context: constraints on deletion (only if not in use by active/recent jobs, only own collections). No contradictions with annotations.

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

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

Extremely concise: three sentences that cover purpose and constraints without any fluff. First sentence directly states the action, making it 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?

For a simple tool with one parameter and an output schema, the description is complete. It explains the action, the conditions for use, and the parameter's source. No additional context 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 coverage is 100% with a clear description for collection_name ('Exact collection name as returned by get_collections'). The description does not add extra parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.

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 'Delete a classifier collection', specifying the action and resource. The constraints (cannot delete if in use by active/recent jobs, only delete collections you created) further clarify its scope, distinguishing it from sibling tools like delete_classifier.

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

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

Description provides explicit when-to-use guidance ('only delete collections you created that are no longer needed') and when-not-to-use ('Cannot delete collections that are in use by active or recent jobs'). While it doesn't name alternative tools, the context is clear enough for appropriate selection.

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 already set destructiveHint=true, and the description adds valuable context by clarifying that the removal is permanent and does not affect the actual database. It does not contradict annotations.

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

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

The description is very concise, using two short sentences. The first sentence states the action, and the second clarifies the permanence and scope. No unnecessary words or 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 output schema exists, the description does not need to explain return values. It covers the key nuance of not affecting the actual database. However, it could mention prerequisites like permissions or required database state. Still, it's fairly complete for a delete tool with annotations.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description does not add additional parameter meaning. Baseline 3 is appropriate as the description adds no extra semantics.

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 disconnects and removes a database from ALTR, emphasizing it only affects the ALTR connection, not the actual database. This distinguishes it from sibling tools like create_database or update_database.

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 does not explicitly state when to use or not use this tool, nor does it compare it to alternatives like delete_collection or delete_agent_instance. It implicitly guides by clarifying the scope, but lacks explicit 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?

Annotations already indicate destructiveHint=true. Description adds context about removal of all associated rules and a safe usage suggestion (review first), which goes beyond the annotation.

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 action, then caution and guidance. No extraneous information.

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

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

For a simple delete tool with one parameter and existing output schema, the description covers purpose, scope, and caution adequately. No gaps.

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

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

Only one parameter, policy_id, is fully documented in the schema with clear instructions. Description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states 'Delete a masking policy and all its rules,' specifying the action and scope. It distinguishes from siblings like 'delete_rule' which deletes a single rule.

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

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

Explicitly advises 'Use with caution' and recommends reviewing rules with `get_rules` first. Provides clear when-to-use guidance but lacks explicit alternatives or exclusions.

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

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

Annotations already indicate destructiveHint=true. Description adds value by explaining fine-grained nature and prerequisite step, beyond what annotations provide.

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 concise sentences covering purpose, benefit, and prerequisite. No wasted words.

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

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

Given simple 2-param tool with output schema, description covers purpose, usage, and prerequisite. Complete for intended 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 descriptions are already complete (100% coverage). Description adds context on how to obtain rule_id parameter, which is helpful 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?

States 'Remove a specific masking rule from a policy' with clear verb and resource. Differentiates from delete_policy by explicitly noting 'without deleting the entire policy'.

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

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

Provides explicit prerequisite: 'Use get_rules first to identify the rule_id'. Does not explicitly state when not to use, but context implies deletion of entire policy is alternative.

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

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

Annotations confirm destructiveHint=true; the description adds the precondition about task_count, indicating that deletion will fail if not met, but does not detail other side effects or irreversibility beyond annotations.

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

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

One concise sentence front-loading the action and including the precondition, with no wasted words.

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

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

Given the output schema likely handles return values, the description covers the core action and precondition adequately; could mention if deletion is reversible or cascades, but not necessary for this simple case.

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 already describes agent_id as 'Agent UUID' with 100% coverage; description adds no further parameter meaning beyond the precondition regarding values.

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 'Delete an agent' with a specific verb and resource, distinguishing it from sibling tools like delete_sc_agent_task.

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 precondition 'Agent must have task_count of 0' tells when to use the tool, implicitly guiding away from agents with tasks, but does not explicitly list alternatives or when not to use.

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 provide destructiveHint=true, but the description adds atomicity and mentions decrementing agent and service user task counts. This goes beyond annotations, offering operational 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: first states purpose, second adds behavioral details. No wasted words, front-loaded with key information.

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

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

With output schema present, description need not explain return values. It covers operation, atomicity, and side effects. Could mention error handling but complete enough for a simple delete.

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

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

Schema coverage is 100% with clear descriptions of agent_id and task_id as UUIDs. The description does not add additional parameter semantics, meeting the baseline but not exceeding it.

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

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

The description clearly states 'Delete an agent task' with specific verb and resource. It distinguishes from sibling tools like delete_sc_agent and update_sc_agent_task by specifying the exact resource and adding atomicity and count decrement 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 does not explicitly provide when to use or alternatives. While deletion is straightforward, no guidance on conditions or when not to use limits the score. It lacks explicit 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?

Annotations already indicate destructiveHint=true. The description adds a precondition (no users/bindings) that affects behavior, but does not disclose what happens if the precondition fails, whether deletion is reversible, or any other side effects. It adds marginal value beyond annotations.

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

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

Two short sentences with no filler. The action and key constraint are front-loaded. Every word is necessary and earned.

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

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

For a simple single-parameter deletion tool with annotations and an output schema (implied), the description is adequate. It covers the action and a critical precondition. Could mention permanence of deletion or that the repo must exist, but not strictly required.

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

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

Schema coverage is 100% (one parameter with description 'Repository name.'). The description does not add any additional meaning or constraints about the parameter beyond what the schema provides.

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 (Delete) and the resource (repository), and adds a key precondition (no users or bindings), which distinguishes it from related sibling tools like create_sc_repo or update_sc_repo.

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 a precondition (must have no users or bindings) but does not explicitly guide when to use this tool versus alternatives like delete_sc_repo_user or list_sc_repo_bindings. There is no mention of when not to use it or steps to prepare the repository for deletion.

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 already indicate destructiveHint=true. The description adds nothing beyond confirming deletion, omitting important details like permanence, permission requirements, or side effects. With annotations present, the description should complement them, but here it merely restates the 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 a single sentence with no extraneous words, achieving high efficiency. However, it could be slightly more informative without losing conciseness.

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

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

Although an output schema exists (not shown), the description fails to cover important contextual aspects for a destructive tool, such as irreversibility, required permissions, or typical use cases. Minimal guidance beyond the basic action.

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 provides clear descriptions for both required parameters (repo_name and username), achieving 100% coverage. The description adds no additional meaning beyond what the schema already conveys, so baseline 3 is appropriate.

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 'Delete a repo user' clearly identifies the verb (delete) and the resource (repo user). It is specific enough among siblings like delete_sc_repo or delete_sc_agent, though it could be more precise by stating 'from a repository'.

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. Sibling tools include create, update, list for repo users, and other delete tools, but the description lacks context about prerequisites (e.g., user must exist) or when this operation 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?

The destructiveHint annotation already indicates the operation is destructive, but the description does not add any additional behavioral context (e.g., irreversibility, cascading effects, or required authentication).

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 (3 words), which is front-loaded, but lacks necessary context. Every word is functional, but the brevity sacrifices 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 output schema exists and annotations are present, the description is minimal. It does not address the variety of service users or distinguish from similar delete tools, making it less complete for an 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?

The input schema describes both parameters (repo_name, username) with coverage 100%. The description does not add further semantic meaning, so baseline score of 3 is appropriate.

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 'Delete a service user' clearly identifies the verb (delete) and resource (service user). However, it does not differentiate from sibling tools like delete_sc_repo_user or delete_sc_agent, missing an opportunity to specify scope.

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

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

No guidance on when to use this tool vs alternatives. There is no mention of prerequisites, permissions, or when to choose this over related delete 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?

The description adds the precondition about listeners beyond the destructiveHint annotation, which informs the agent of a necessary condition for successful execution.

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

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

The description is extremely concise with two sentences, front-loading the action and then the condition, with 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 delete tool, the description adequately covers the action and a key precondition. It does not discuss error handling or output, but the output schema likely covers that.

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 already fully describes the single parameter 'sidecar_id' as 'Sidecar UUID.' The description adds no additional parameter information.

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 'Delete a sidecar,' which is a specific verb and resource, and it is distinct from sibling tools like create_sc_sidecar and get_sc_sidecar.

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