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

With no annotations provided, the description carries the full burden of behavioral disclosure. It flags 'WRITE OPERATION' but does not state that deletion is permanent, irreversible, or might have side effects on existing DAG runs or downstream dependencies. It adds minimal context beyond what the action 'Delete' already implies.

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 and front-loaded, with a single clear sentence and a bold safety note. It is appropriately short for a simple delete operation, though the 'WRITE OPERATION' warning might be considered redundant given the verb 'Delete.'

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 critical context for a destructive operation. It does not mention that deletion is permanent, what happens to associated resources (e.g., job runs), or whether special permissions are required. It also fails to explain the authentication parameters, leaving users under-informed for safe invocation.

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

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

Schema description coverage is 0%, and the description provides no meaning for the input parameters (job_name, cde_user, cde_password, cde_endpoint_url). It fails to explain the purpose of the optional authentication parameters or clarify the required job_name. The description adds zero value over the raw 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 uses a specific verb ('Delete') and resource ('CDE Airflow job'), clearly distinguishing it from sibling tools like list_cde_jobs, describe_cde_job, and trigger_cde_job. It unambiguously states what the tool does.

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

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

The description implies usage when you need to delete a CDE job, but it does not explicitly mention when to use this tool versus alternatives, nor does it provide any prerequisites or exclusions. There is no guidance on when not to use it, such as if the job is running or has dependencies.

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

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

With no annotations, the description carries the full burden and does well by disclosing that it creates/updates a CDE files resource and Airflow job, checks live table data, avoids WAP/staging, and supports force_recreate for deletion. It lacks details on failure modes or idempotency, but covers the key behavioral traits for a deployment 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 well-structured with a concise summary followed by an Args list. Every sentence adds value, and the layout makes it easy to scan for purpose, behavior, and 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?

For a complex tool with 9 parameters and no annotations, the description is remarkably complete: it covers all parameter semantics, key side effects, and even special behavior like no WAP branch. Since an output schema exists, not explaining return values is acceptable.

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?

Although schema description coverage is 0%, the Args section in the description provides meaningful definitions and defaults for all 9 parameters, such as 'ODCS-compatible contract JSON', 'default CDW', and 'default daily 0 3 * * *'. This fully compensates for the schema's missing 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 opens with a specific verb+resource statement: 'Generate DAG from data contract and deploy to Cloudera CDE as an Airflow job.' It clearly distinguishes itself from siblings like generate_dag_from_contract by explicitly adding deployment and the creation/update of CDE files resource and Airflow job.

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 clearly conveys the tool's deployment purpose and side effects, allowing an agent to infer when to use it. However, it does not explicitly mention alternatives or exclusion criteria, such as 'use generate_dag_from_contract if you only need the DAG without deployment.'

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 only says 'Describe', which implies a read-only operation, but it does not disclose that cde_user, cde_password, and cde_endpoint_url are likely authentication-related, nor what happens if they are absent or invalid. Credential handling is a meaningful behavioral trait left unexplained.

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?

A single, front-loaded sentence with no filler. Every word contributes to the core purpose. It is appropriately concise for a simple describe operation.

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 4 parameters, no annotations, and 13 sibling tools, this one-liner is insufficient. It lacks guidance on authentication requirements, selection relative to sibling tools, and what 'describe' encompasses. The output schema may cover return values, but the description does not make the tool easy to invoke correctly without prior domain knowledge.

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

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

Schema description coverage is 0%, and the description only reinforces that job_name is the lookup key via 'by name'. It does not explain cde_user, cde_password, or cde_endpoint_url, which are critical optional parameters. The description fails to compensate for the absent 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 action ('Describe') and resource ('a CDE job'), and narrows it by name. It distinguishes from list_cde_jobs by implying a single-job lookup, though it doesn't explicitly name alternatives or the nature of the returned 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?

There is no guidance on when to use this tool versus list_cde_jobs, get_cde_config, or get_cde_job_run_status. The 'by name' qualifier implicitly suggests targeted lookup, but no exclusions or alternative recommendations are provided.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions that it 'configure endpoint + list jobs', which gives some insight into actions, but it does not clarify potential side effects (e.g., modifying config files), authentication requirements, or failure behavior. This partial transparency warrants a middle score.

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 focused sentence followed by a clear, structured argument list. Every element serves a purpose, with no filler or repetition, making it highly concise and well-structured.

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

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

The tool has an output schema, so the description need not explain return values, but it lacks context about when to use this for diagnosing connectivity versus simply listing jobs. It also does not mention any prerequisites or expected inputs, leaving the agent with a minimal but not fully complete picture.

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

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

Despite having 0% schema description coverage, the description enriches all three parameters by stating they override environment variables (e.g., 'overrides CDE_USER env'). This adds clear meaning beyond the raw schema, though it does not specify defaults or required-ness, which are already in the schema as nullable with defaults.

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 with the verb 'probe' and resource 'CDE CLI connectivity', and it distinguishes itself from siblings like list_cde_jobs by noting it also 'configure endpoint + list jobs'. This gives a specific, actionable definition.

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 such as list_cde_jobs or describe_cde_job. There is no mention of scenarios, exclusions, or alternative tools, leaving the agent to infer usage from the purpose alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions validation logic, CDW connection, and default schedule, which is useful. However, it is ambiguous whether validation happens at generation time or inside the generated DAG, and it does not disclose output format or side effects beyond 'Generate Airflow DAG Python'.

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 opening, behavioral details, and an Args list. It is front-loaded and every sentence adds information, though the Args section is somewhat verbose and could be tightened.

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 lack of annotations, the description covers key aspects: purpose, parameters, defaults, and validation behavior. It is nearly complete but leaves gaps around the 'no WAP' qualifier, the distinction from deploy_contract_dq_job, and the exact timing of validation. The presence of an output schema mitigates the need to describe return values.

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

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

Schema description coverage is 0%, so the description must compensate. The Args section explains all four parameters with meanings and defaults (e.g., contract_json, schedule, cdw_connection_id, audit_table). This adds substantial value beyond the bare input 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 opens with 'Generate Airflow DAG Python from an ODCS data contract (no WAP)', which clearly states the tool's verb, resource, and scope. This distinguishes it from sibling tools like deploy_contract_dq_job and preview_contract_checks, making its 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 context about defaults and validation behavior but does not explicitly state when to use this tool versus alternatives like deploy_contract_dq_job or preview_contract_checks. Usage is implied by the name and purpose, but no explicit exclusions or alternative comparisons are given.

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

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

With no annotations, the description carries the full burden. It clearly states this is a read-only monitoring operation that returns status, start/end times, and run ID. It does not overpromise or hide side effects; the phrase 'via CDE run API' adds context. Minor gap: it doesn't explicitly state it makes no changes, but the 'monitor' wording implies a safe read operation.

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

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

The description is two sentences, front-loaded with the key action and resource. The second sentence adds valuable return details. No wasted words, though 'CDE Airflow job' appears twice redundantly; still concise and well-structured.

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

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

The description covers the tool's core purpose and return data, and an output schema exists, so return structure is provided elsewhere. However, it is under-specified given 4 parameters with 0% schema coverage, especially the auth-related params, and lacks usage guidance relative to sibling tools. It is minimally viable but leaves notable gaps for an agent to invoke correctly with correct credentials.

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

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

Schema description coverage is 0%, and the description does not explain any parameters. While job_name is obvious, the optional credentials (cde_user, cde_password, cde_endpoint_url) are left entirely unexplained, forcing the agent to guess their purpose. The description fails to compensate for the schema gap.

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

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

The description states a specific verb ('Monitor') and resource ('latest CDE Airflow job run status'), and clarifies it returns the most recent run with status, times, and run ID. This clearly differentiates it from sibling tools like get_cde_job_run_status which likely handles specific runs.

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: 'Monitor latest' suggests using this tool when you want the most recent run status. However, no explicit alternatives or when-not-to-use guidance is provided, and sibling tools like list_cde_job_runs and get_cde_job_run_status are not mentioned as 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?

With no annotations provided, the description carries the full burden, and it does well by noting 'passwords redacted' and specifying the exact environment variables and source file. It does not mention whether there are side effects, but the read-only nature is strongly implied by 'Return current configuration'.

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

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

The description is two short sentences with no wasted words. The main purpose is front-loaded, and the redaction note is included parenthetically for immediate awareness.

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 zero-parameter configuration getter, the description is complete: it states what it returns, what it reads, and the important security behavior (password redaction). No further context is needed to invoke it correctly.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. The description adds value by listing the exact configuration keys that will be read, even though these are not function parameters.

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

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

The description uses a specific verb and resource: 'Return current CDE/CDW configuration', clearly indicating this is a read-only retrieval tool. It distinguishes itself from sibling job-management tools by focusing on configuration rather than job operations.

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 clearly implies this is the tool to call when the agent needs the current CDE/CDW configuration, including source (environment or .env). It does not explicitly state when not to use it or name alternatives, but the context is clear enough given the sibling tools are about job lifecycle and diagnostics.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Get status' – implying a read operation – but does not mention authentication requirements (despite cde_user/cde_password params), error handling, or any edge-case behavior. The credential parameters hint at auth, but the description gives no 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 a single 6-word sentence: 'Get status of a specific CDE job run.' It is front-loaded and has no filler words. However, it is so sparse that it borders on under-specification, but this is still concise rather than 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?

Even though an output schema exists (reducing the need to explain return values), the description is incomplete for a 4-parameter tool with optional auth credentials and multiple sibling tools. It lacks usage guidance, parameter explanations, and any context about when or how to supply cde_user/cde_password/cde_endpoint_url. The tool's complexity is not matched by the description's minimal detail.

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

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

Schema description coverage is 0%, and the tool description provides no parameter information whatsoever. run_id, cde_user, cde_password, and cde_endpoint_url are completely undocumented in both schema and description, leaving the agent without any clue about their meanings or expected formats. The description fails to compensate for the schema gap.

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

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

Description states 'Get status of a specific CDE job run' – a clear verb ('Get') and resource ('status of a specific CDE job run'), which distinguishes it from list_cde_job_runs (which lists runs) and get_airflow_dag_run_status (Airflow-specific). The specificity of 'specific' run makes the purpose unambiguous.

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

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

The description implies usage when a run_id is known and status is needed, but does not explicitly state when to use this tool versus list_cde_job_runs for seeing all runs or get_airflow_dag_run_status for a different system. No exclusions or alternative tool mentions are provided.

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

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

With no annotations, the description must carry the burden of disclosing behavioral traits, but it provides no details beyond restating the function name. It does not mention whether the operation is read-only, if authentication is required, or how runs are scoped (e.g., all runs vs. recent). The parenthetical clarifies purpose, not 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 sentence, directly starting with the verb 'List' and including all essential information. There is no redundant text or filler, making it an exemplar of 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?

Despite the output schema existing, the tool has 4 parameters with no schema descriptions and no annotations. The description does not explain the required job_name parameter or optional credential parameters, leaving the agent uncertain about prerequisites and invocation. This is a significant gap for a tool with multiple configuration parameters.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It only hints at 'job_name' by saying 'for a job', but provides no explanation for the optional cde_user, cde_password, or cde_endpoint_url parameters. This is minimal value beyond the raw schema.

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

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

The description clearly states the tool's function: 'List CDE runs for a job' with the purpose of monitoring execution status. This verb+resource pairing distinguishes it from sibling tools like list_cde_jobs (which lists jobs) and get_cde_job_run_status (which gets a single run's status). The parenthetical adds clarity to the intent without ambiguity.

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 phrase '(monitor execution status)' gives clear context for when to use this tool—when you want to check the status of a job's runs. However, it does not explicitly state when not to use alternatives or name any exclusions, so it falls short of a full 5.

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

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

With no annotations provided, the description must disclose behavioral traits. It only states the action 'List' without confirming read-only status, authentication requirements, pagination behavior, or error handling. This is insufficient for an operation that takes credential parameters.

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

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

The description is a single sentence with a front-loaded verb and no wasted words. It is appropriately sized for the information it conveys, though that information is 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 tool has three optional authentication-related parameters and a large sibling tool set. The description does not explain why credentials might be needed, how it differs from related list tools, or any connection/authentication prerequisites. The description is minimally viable but lacks essential context.

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

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

Schema description coverage is 0% and the description does not explain the purpose or usage of the three parameters (cde_user, cde_password, cde_endpoint_url). It adds no meaning beyond the parameter names, completely failing to compensate for the lack of 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 uses a specific verb 'List' and resource 'CDE jobs', which clearly distinguishes it from sibling tools like list_cde_job_runs (lists runs) and describe_cde_job (describes a single job). It is direct and 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 no guidance on when to use this tool versus alternatives such as list_cde_resources or describe_cde_job. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer the appropriate context.

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

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

No annotations are present, so the description carries the burden of disclosing behavior. It only says 'List' which implies read-only, but it does not mention authentication needs (despite credential parameters), potential errors, rate limits, or the nature of the returned data.

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 filler. It is concise, but the brevity comes at the cost of necessary detail. It still earns its place as a minimal functional statement.

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

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

For a tool that likely requires CDE credentials and connectivity, the description is incomplete. It does not explain what 'file resources' are, when this should be called, or how the optional parameters affect the request. The presence of an output schema reduces the need to describe return values, but the lack of contextual setup is a significant 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 description coverage is 0%, and the description does not mention or explain any parameters. While parameter names (cde_user, cde_password, cde_endpoint_url) are somewhat self-explanatory, the description adds no contextual meaning about how or why these are used.

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 a clear action ('List') and a specific resource ('CDE file resources'), which is more specific than a tautology. However, it does not define what 'file resources' encompasses, so it is not fully self-explanatory.

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 siblings like list_cde_jobs or diagnose_cde_connectivity. There is no mention of prerequisites, use cases, or alternatives.

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

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

Since no annotations are provided, the description carries the full burden. The word 'Preview' suggests a read-only, non-destructive operation, and 'would be generated' indicates hypothetical output. However, the description doesn't explicitly confirm that no side effects occur, whether validation happens, or what happens on invalid input. This is a minor gap for a preview 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 a single, focused sentence that conveys the core purpose without unnecessary detail. Every word contributes to understanding the tool's function, making it highly concise and well-structured.

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

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

The tool has an output schema, which likely covers return values, and one simple parameter. However, the description lacks contextual guidance on how this tool fits into the broader workflow (e.g., using it before generate_dag_from_contract). It's adequate for a simple preview tool but not fully complete given the sibling context.

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

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

Schema description coverage is 0%, and the description adds little beyond the parameter name. 'contract_json' is a string, and the description says 'from a contract', but it doesn't specify the expected JSON structure, format, or any details about how the contract should be provided. The description fails to compensate for the lack of schema documentation.

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 a specific verb 'Preview' with a clear resource ('schema and quality SQL checks') and source ('from a contract'). It effectively distinguishes this tool from siblings like generate_dag_from_contract or deploy_contract_dq_job, which perform different actions.

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 usage context is implied but not explicitly stated. The description implies this tool is for inspecting checks before generation or deployment, but it doesn't explicitly say when to use it over alternatives or mention any exclusions or prerequisites. There's no clear guidance on workflow placement.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action ('Trigger'). It does not mention side effects, authorization requirements, whether the run is asynchronous, or what happens if the job is already running. This is a mutating operation that needs more 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, grammatically correct sentence with no filler, and the verb is front-loaded. However, it is under-specified for a tool with four parameters and mutation side effects, so conciseness borders on being too terse.

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 mutating trigger tool with no annotations and four parameters, the description is incomplete. It fails to explain return values, error conditions, or parameter relationships, and the presence of an output schema does not compensate for missing usage and behavioral context.

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

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

Schema description coverage is 0%, and the description names no parameters. The required job_name and optional cde_user, cde_password, and cde_endpoint_url are not explained beyond their titles, leaving the agent without semantic guidance for populating them.

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

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

The description uses a specific verb ('Trigger') and identifies the resource ('a manual CDE job run'), making the core action clear. It is distinguishable from sibling tools like list_cde_jobs or describe_cde_job, though it could be more explicit about what 'manual' implies.

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 get_cde_job_run_status or diagnose_cde_connectivity. There is no mention of prerequisites, scheduling context, or exclusions, leaving the agent to infer usage.

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