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

Annotations already mark this as destructive/non-readonly, and the description goes well beyond them: atomic all-or-nothing application, full pre-validation before any HTTP call, ETag optimistic-concurrency with one transparent retry, auto-naming/auto-sizing, write-once placement/dataRoles, and same-batch forward-reference failure. No contradiction 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 definition is long, but it is front-loaded with the core purpose and organized into labeled bullets with concrete examples. Every section earns its place given the breadth of operation types and layout rules; only minor trimming might help an agent parse it faster.

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 mutation tool, it covers validation behavior, atomicity, concurrency handling, layout placement rules, header restrictions, multi-page batching, save-as behavior, and verification workflow. With an output schema present, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, yet the description still adds indispensable meaning: the list of valid operation keys, a concrete addObject example, layout/title recipes, save-as atomic template instantiation paired with changeData, conflict policy semantics, and the dry_run validation value. This greatly exceeds what the input schema alone conveys.

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 precise verb and resource ('Apply an ordered batch of operations to a report') and immediately positions it as 'the authoring workhorse' for adding pages/objects, setting parameters, and swapping data sources. This clearly separates it from read-only report tools and report creation/copy siblings.

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 explicitly states when to use the tool ('This is how you add pages...') and routes the agent to supporting tools such as describe_report_objects and get_castable_columns. It also tells the agent to read structure via get_report_outline and verify via export_report, but it does not give explicit when-not-to-use exclusions against create_report/copy_report.

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 goes well beyond the annotations by explaining what the assignment actually does, what downstream catalog facets read it, and that 'assigning the same term to the same column twice is reported, not duplicated.' This gives concrete idempotency semantics beyond the idempotentHint annotation, with no contradiction to the 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 purpose is front-loaded in the first sentence, and each subsequent sentence adds non-redundant context: the distinction from term creation, the downstream consumers of the assignment, and duplicate behavior. There is no filler or unnecessary repetition.

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 fully documented schema, output schema, and annotations, the description supplies the non-obvious context an agent needs: what the assignment does, what reads it, and how duplicates are handled. Nothing material is missing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including term_id, term_name, table_name, column_name, and resource_uri. The description does not add parameter-level meaning beyond that, so the baseline score 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 opens with a specific verb and resource: 'Assign a business term to a table column,' and immediately conveys the operational consequence ('the step that makes a term govern data'). It also distinguishes itself from create_glossary_term by explaining that creating only defines a word, so an agent can tell assignment apart from term 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 clearly implies when to use this tool: after a term exists, when the goal is to attach it to a column rather than just define it. It also ties the effect to downstream tools like list_table_terms and list_term_assets, giving useful context. However, it does not explicitly point to unassign_glossary_term as the removal alternative or state when not to use this tool.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's job is lighter. The description adds the useful scoping constraint that only running jobs can be canceled, but it does not disclose potential side effects or failure behavior 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 one short sentence that immediately communicates the operation and adds the key qualifier 'running' beyond the title. There is no redundancy or wasted text.

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 one-parameter, destructive operation with full schema coverage, an output schema, and relevant annotations, the description is mostly sufficient. It clearly identifies the target and state constraint, though it could be more complete with a note about cancellation effects 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 fully documents job_id as the ID of the job to cancel, so schema coverage is 100%. The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific action (cancel) and a specific resource (a running job), making the tool's purpose immediately clear. It also distinguishes this tool from sibling job-related tools like submit_batch_job, get_job_status, list_jobs, and get_job_log.

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

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

The description gives no guidance on when to use this tool versus alternatives, such as checking job status first with get_job_status or retrieving logs with get_job_log. It only implies the tool is for running jobs, but does not explain prerequisites, ordering, or when cancellation is not 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?

Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral context beyond that: it returns a recommendation to run catalog_run_adhoc_analysis instead of an empty profile when profiling is missing, resolves resource_uri via resourceId like catalog_find_instance, and documents that instance_id takes precedence when both are supplied.

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 front-loaded with the core action and output in the first sentence, then adds fallback behavior and parameter-selection details in short, purposeful paragraphs. Every sentence contributes distinct information without repetition.

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 read-only download tool with rich annotations, full schema coverage, an output schema, and an important edge case, the description covers the result format, unprofiled-table behavior, parameter precedence, and relevant sibling workflow. No critical usage information is missing.

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

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

The schema already describes all three parameters, but the description adds critical non-redundant semantics: the caller must provide either instance_id or resource_uri, instance_id takes precedence if both are given, and resource_uri supports a search → profile → download workflow without handling an instance id. This materially improves parameter understanding beyond the schema.

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

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

The description opens with a specific verb and resource: 'Download a catalog table's data dictionary and profile as CSV.' It also distinguishes the tool from siblings like catalog_run_adhoc_analysis by describing the unprofiled-table fallback, so an agent can clearly identify what this 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?

It states when the tool is appropriate (downloading metadata/profile) and names the alternative catalog_run_adhoc_analysis for the unprofiled-table case. It also provides clear guidance on choosing instance_id vs resource_uri, including the workflow benefit of resource_uri. It does not exhaustively compare to all catalog siblings, but the guidance is strong.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavior beyond annotations: it performs lookup by resourceId, returns the instance id plus profile attributes, and exposes whether the asset has been profiled via analysisTimeStamp. This gives the agent a good mental model of what will happen without contradicting the 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 front-loaded with the core purpose, then builds context efficiently. Every sentence earns its place: one sentence for purpose, one for relation to catalog_search and key return fields, one for the downstream tool. The use of backticks for identifiers keeps it scannable without unnecessary 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?

For a single-parameter lookup tool with a rich output schema and annotations covering safety, the description is complete. It explains the input, the output, the relationship to sibling tools, and the practical use case. Nothing an agent needs to decide whether to call this tool is missing.

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

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

Schema coverage is 100% and the schema already documents resource_uri with an example. The description adds meaning by explaining where the URI comes from (search hit or CAS table path) and connecting it to the resourceId lookup used by the profiling workflow. This goes beyond a bare schema description, though the relationship between resource_uri and resourceId could be slightly clearer.

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 and resource: 'Resolve the catalog instance for a source-asset URI.' It immediately distinguishes the tool from catalog_search by explaining that catalog_search finds assets by free text and facets while this tool resolves the instance id that profiling/download tools require. The purpose is unmistakable even without reading the schema.

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

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

The description gives explicit when-to-use guidance: use it when you already hold a resource URI from a search hit or a CAS table path, and use it before calling catalog_download_table_profile. It also names the alternative, catalog_search, and explains the difference in lookup style. This is strong routing guidance for an agent.

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/idempotentHint/destructiveHint annotations, the description discloses the delayed profile-attribute write, defines profile_ready via analysisTimeStamp, relates it to the gate catalog_download_table_profile uses, and adds the information_privacy/NLP enrichment behavior. This is substantial behavioral context, not schema repetition, and it does not contradict the 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 summary sentence is front-loaded and the second paragraph earns its length: it explains the race condition, defines the readiness flags, references the download gate, and ends with the exact polling action. No filler sentences are present.

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 only one parameter, an output schema, and safety annotations already supplied, the description covers the subtle timing gap, the meaning of profile_ready and information_privacy, and the correct invocation sequence. Nothing needed to call and act on this tool is missing.

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

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

Schema description coverage is 100% and the sole job_id parameter is already documented as 'The analysis job id returned by catalog_run_adhoc_analysis.' The tool description adds only an indirect note about 'when the job carries a resource,' so the schema carries the parameter-semantics burden; 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 opens with a specific verb-resource pair: 'Get the status of an ad-hoc analysis job, and whether its profile is ready.' It then sharpens the distinction from generic job-status tools by explaining that terminal status is not sufficient, so an agent can tell this apart from get_job_status and knows it is the readiness gate before catalog_download_table_profile.

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

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

The description gives clear context and a direct usage pattern: 'Poll until profile_ready is true, then download.' It also explains the race condition that motivates the tool. It does not explicitly name a when-not-to-use alternative such as get_job_status, but the polling instruction and download caveat make the intended usage unmistakable.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by explaining that each record reports run status and metadata population counts (enumerated/added/updated/removed), which helps the agent interpret results without contradicting 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 compact and front-loaded with the core purpose, followed by a concise explanation of the record contents and the practical use case. Every sentence contributes meaningful information without repetition or filler.

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, annotations cover the safety profile, and all parameters are documented in the schema, the description provides sufficient contextual glue: why to call it, what it returns at a high level, and how it relates to catalog_run_agent. Nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters, including defaults for limit and start and the agent_id reference to catalog_list_agents. The description adds high-level context about run history but does not add significant parameter-level meaning 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 states a specific verb and resource: 'Get the execution history of a catalog agent's runs.' It clearly distinguishes itself from sibling tools like catalog_run_agent by framing the purpose as confirming that a run started via catalog_run_agent finished and what it changed.

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

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

The description provides a clear use case: use this tool to confirm whether a catalog agent run finished and what metadata it changed. It references catalog_run_agent as the initiating tool, giving contextual guidance, though it does not explicitly list exclusions or alternatives beyond that.

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 mark this as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful domain behavior by explaining that agents discover assets and collect metadata into the catalog, and it clarifies that run outputs are accessed elsewhere.

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, front-loaded with the core purpose, and every sentence contributes context: what the tool lists, what an agent does, and which sibling tools handle related actions. There is no filler or repetition of schema details.

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

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

Given the output schema, full parameter schema coverage, and annotations that confirm a safe read-only operation, the description is complete for its complexity. It also situates the tool within the agent workflow, so an agent can correctly decide when to call 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?

All three parameters have descriptions in the input schema, including defaults and the substring-match behavior for filter_name. The description does not add additional parameter-level meaning, but since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description opens with a precise verb and object: 'List SAS Information Catalog discovery agents,' making the tool's purpose immediately clear. It also distinguishes the tool from its siblings by explaining that agents crawl data sources, while catalog_run_agent and catalog_get_agent_history are for starting agents and viewing results respectively.

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 routes the agent to related actions: 'Use catalog_run_agent to start one and catalog_get_agent_history to see what a run produced.' This tells the agent when to use alternatives, implying that this tool is for viewing the configured agent list rather than running or inspecting run history.

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 no meaningful hints (all false), so the description carries the burden of behavioral disclosure. It explicitly states the job runs asynchronously and may take a while, which is critical for an agent deciding whether to wait or poll. It also reveals that the three NLP parameters are enabled by default and drive semantic enrichment around informationPrivacy, nlpTerms, nlpTags, and mostImportantFields, including a performance tradeoff for disabling them. This goes well beyond the schema and 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 well-structured and front-loaded with the core action, followed by the profile contents, then the async workflow, then the NLP parameter guidance. Each sentence adds useful information and there is no filler. It is slightly longer than minimal, but every paragraph serves a distinct purpose.

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

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

For a tool with 8 parameters, an output schema, and asynchronous behavior, the description is complete: it explains what the job produces, how to retrieve the result, what the default NLP parameters do, and when to consider disabling them. The output schema covers return values, and the schema covers parameter syntax. Nothing needed for correct invocation or follow-up polling is missing.

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

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

The input schema already documents all 8 parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema, especially for the NLP booleans: it explains they drive semantic enrichment and affect job duration, and it clearly names the asset fields they populate. It does not add detail for every parameter, but the schema handles those adequately.

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 and resource: 'Submit an ad-hoc analysis (profiling) job for a table in the catalog.' It then clarifies what the job produces (data dictionary, column statistics, data-quality metrics) and explicitly distinguishes it from sibling tools like catalog_download_table_profile and catalog_get_adhoc_analysis. An agent can tell exactly what this tool does and how it fits into the catalog 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 clearly explains the asynchronous workflow: submit the job, receive a job id, and poll catalog_get_adhoc_analysis until the profile is ready. It also names catalog_download_table_profile as the tool whose output this job computes, giving context for when a precomputed profile might be the alternative. It does not explicitly state when to use one over the other, but the polling instruction and sibling references provide strong practical 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?

The description discloses key behavioral traits beyond annotations: the run is asynchronous, results are applied in the background, and completion requires polling. It also states the cannot-stop limitation, which is critical operational context. No contradiction with the 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 concise and front-loaded, with the core action in the first sentence. Every subsequent sentence adds useful context: background application, polling, and the stop limitation. No filler 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?

For a single-parameter tool with an output schema and annotations, the description fully covers what the tool does, how it behaves, how to track it, and its limitation. Nothing call-critical is missing.

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

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

Schema description coverage is 100%, and the agent_id parameter is already documented as the ID of the agent to run with a pointer to catalog_list_agents. The main description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: it 'Starts a catalog discovery agent run' and explains the agent will crawl its data source and populate/refresh metadata. This clearly distinguishes it from related tools like catalog_list_agents or catalog_get_agent_history.

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 explicitly says to poll catalog_get_agent_history to track completion, which gives the agent a follow-up path. It also notes that the API can only start an agent, not stop one, preventing misuse. It doesn't explicitly enumerate all sibling alternatives, but the usage 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?

Even with annotations declaring readOnlyHint, idempotentHint, and destructiveHint, the description adds substantial behavioral context: it explains that each hit includes a resource_uri and an attributes map with common metadata keys, and it details the catalog search grammar with examples. This goes well beyond the structured annotations and tells the agent what to expect from results.

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 long but every section earns its place: a one-sentence purpose, a return-value explanation, and a compact bulleted grammar guide with concrete examples. It is front-loaded with the most important scoping information and ends with a practical pointer to catalog_search_helper, with no filler.

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 search tool with a non-trivial query grammar, the description is complete: it explains when to use it, what results look like, how to interpret resource_uri, and how to learn valid facets. The output schema is reportedly present, and the description covers the return shape anyway, so an agent has everything needed to call and consume the tool correctly.

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

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

Schema coverage is 100%, so parameters like limit, start, and indices are already documented. The description adds significant meaning for the query parameter by specifying the search grammar, wildcards, facets, ranges, and combination syntax, which is essential for correct invocation. This raises it above the baseline 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 opens with a specific verb and resource ('Search the SAS Information Catalog for assets') and immediately distinguishes itself from siblings by explaining it is a metadata index across the whole Viya environment that finds assets without knowing the server/library first. It also clarifies how results connect to other tools via resource_uri, making the tool's role in the ecosystem unmistakable.

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

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

The description gives clear context for when to use this tool: when you need to find assets without knowing their server or library, or when you want to discover assets by name, facets, or ranges. It also points to catalog_search_helper for discovering valid facet names and values. It does not explicitly state when not to use it versus list_* tools, but the 'whole Viya environment' distinction implies the boundary.

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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context: no facet returns available facets, while a facet name returns suggested/valid values that actually exist, which helps the agent understand what the tool will do.

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 compact and front-loaded with a clear summary, followed by two sentences that explain the two modes and the downstream purpose. Every sentence contributes useful guidance without filler.

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

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

Given the simple parameter set, full schema documentation, output schema presence, and read-only annotations, the description is complete. It explains when to call, what the two behaviors are, and how the results should be used in catalog_search.

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 extra meaning by explaining that facet values are 'the asset types or review statuses that actually exist' and that results are intended for building catalog_search queries. It does not add detail for limit or query, but those are already well documented 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 opens with a specific verb and resource: 'Discover how to search the catalog: list facets, or values for one facet.' It clearly defines two modes and refers to catalog_search, making it easy to distinguish from the sibling catalog tools.

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 explicitly explains when to call with no facet versus with a facet, and tells the agent to use the results to build precise catalog_search queries. It does not explicitly state when not to use the tool, but the helper role relative to catalog_search 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?

Annotations already declare destructiveHint: true and idempotentHint: false. The description adds the return payload shape ({status, id, name, source_report_id}) and the copy-and-replace workflow, going beyond what annotations provide. It does not contradict the annotations, though it could have explained that on_conflict='replace' may overwrite an existing report.

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

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

Three sentences, front-loaded with the core action and result. The use-case sentence earns its place, and the return-format sentence is compact. 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?

Covers purpose, usage patterns, and return shape; with schema handling parameters and annotations handling destructive behavior, little is missing. A minor gap is not explicitly calling out that on_conflict='replace' can overwrite an existing report, though that is present in the schema.

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

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

Schema description coverage is 100% with detailed descriptions for all four parameters, so the baseline applies. The description does not add parameter-level details beyond what the schema already states.

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 a specific verb ('Copy'), resource ('Visual Analytics report'), and outcome ('returning the copy's id'). This clearly distinguishes it from sibling report tools such as create_report, delete_report, and get_report.

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

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

Provides concrete use cases: tailoring a report to a new audience and the copy-and-replace pattern, explicitly naming apply_report_operations as the follow-up. It lacks explicit exclusions or alternative copy tools, but the context is clear enough for an agent to select it.

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

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

Annotations only signal readOnlyHint=false, so the description carries the burden of explaining important behavior. It warns that the API accepts malformed expressions that generate broken DS2 code and specifies how boolean variables must be compared, giving the agent actionable knowledge beyond the 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 compact and front-loaded with the core operation. The following sentences each add valuable prerequisite or expression-format information without repeating schema content or including filler.

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 a fully described input schema and the presence of an output schema, the description covers the key prerequisites, conditional evaluation context, and the non-obvious expression pitfalls. It could mention revision locking or side effects, but this is a minor gap for a create tool with rich structured metadata.

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 already documents all 6 parameters, so the baseline is 3. The description adds expression-level constraints not present in the schema property descriptions: variable names must be included as left operands, and boolean values must use = 0/= 1. This directly improves the agent's ability to construct valid conditions and actions.

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 'Create a new rule inside an existing SAS Business Rules rule set,' which clearly identifies the verb, resource, and container. It effectively distinguishes this tool from the sibling create_business_ruleset tool and from the update/get/delete business rule tools.

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 'inside an existing ... rule set' establishes a clear prerequisite and tells the agent this tool is for adding to an existing rule set rather than creating one. It does not explicitly name an alternative like create_business_ruleset, but the context is sufficient for correct routing.

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 indicate non-read-only, non-idempotent, non-destructive; the description adds the key behavioral constraint that an empty rule set is unusable in a decision flow, which is not in the schema and useful for planning follow-up. It does not address duplicate-name behavior, but this is a minor gap given the 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 sentences with no filler; the first states the purpose and the second an important constraint and next step. Very 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?

With an output schema and fully documented parameters, the description provides the workflow caveat an agent needs to sequence create_business_rule afterward. It could be slightly more explicit about alternative tools, but for a simple create operation it is complete enough.

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% and includes full details for name, signature, and description. The tool description adds no parameter-specific semantics, so the baseline 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?

States the action ('Create a new') and the resource ('SAS Business Rules rule set') unambiguously. The follow-up mention of create_business_rule reinforces that this tool creates the container rather than the rules, distinguishing it from the sibling create_business_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?

Gives clear context: use this to create an empty rule set, then populate it with create_business_rule. It does not explicitly state when to prefer update_business_ruleset or delete_business_ruleset, but the workflow cue is sufficient for a create tool.

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

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

Annotations provide only negative hints (not read-only, not idempotent, not destructive), so the description carries the burden of behavioral context. It discloses that a resource is created and that it chains rule set steps, but it omits side effects, whether the flow is created in a draft state, and what happens on validation failure. This is minimal beyond the 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 a single front-loaded sentence with no filler or redundancy. It loses one point because 'chaining rule set steps' is grammatically awkward and could be clearer, but it remains appropriately 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?

The parameter schema is complete, and an output schema exists, so return values need not be documented. However, the description alone gives no usage context or prerequisites; the tool is usable only because the schema carries the detail. This is adequate but not 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%, so the schema fully documents all four parameters. The description adds no parameter-level detail beyond the schema, yielding the baseline score 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 names a specific action and resource: 'Create a new SAS Intelligent Decisioning flow.' It also identifies the defining behavior, 'chaining rule set steps,' which distinguishes this creation tool from related siblings like update_decision_flow, list_decision_flows, and create_business_ruleset.

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 explicit guidance about when to use this tool versus update_decision_flow or list_decision_flows. The phrase 'Create a new' implies it is for new flows only, but no alternatives, exclusions, or prerequisites are stated.

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 minimal annotations, the description discloses major behavioral quirks: attribute values are converted to Viya's accepted spelling, validation fails with attribute-specific errors before the HTTP call, terms are published by default even though the underlying API defaults to draft, and name uniqueness is enforced case-insensitively among siblings. This is far more than the 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?

The description is front-loaded with a one-line purpose, then uses bold labels and bullets to organize conversion rules, publish behavior, and uniqueness constraints. Although longer than average, every sentence carries operational information an agent needs to avoid failed calls.

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 8 parameters, a custom attributes object, a surprising publish default, and sibling workflow dependencies, the description covers all critical invocation details: prerequisites, value formats, failure behavior, publishing, and uniqueness. An output schema exists, so not restating 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 the input schema has 100% coverage, the description adds important meaning to the attributes parameter by specifying accepted Python forms for booleans, multi-selects, dates, date-times, and times. It also clarifies the publish parameter's default and effect, and explains name uniqueness for the name parameter beyond the schema text.

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 opening sentence uses a specific verb and resource: 'Create a business term in the SAS Business Glossary.' The rest of the description refers to term-specific behaviors (term type, attributes, publish) that separate it from sibling tools like create_glossary_term_type and update_glossary_term.

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 explicitly instructs callers to invoke get_glossary_term_type first because term types can impose mandatory attributes. It also names update_glossary_term(publish=true) for promoting drafts and notes that drafts are visible under list_glossary_terms only with include_drafts, giving clear workflow direction.

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 carry safety hints; the description adds meaningful behavior: it generates attribute identifiers the API requires, and it warns that the API rejects omission with a vague error. This gives an agent useful insight beyond structured fields.

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 front-loaded with the core purpose and uses a compact bullet list for attribute types. It is longer than minimal but every section adds necessary detail about the API's expectations.

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 an output schema present and complete parameter documentation, the description covers the unusual API quirks and design context sufficiently. Minor omissions such as explicit exclusions or edge cases are acceptable given the sibling list and schema richness.

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 all parameters, so baseline is 3. The description goes further by specifying the valid attribute types, optional attribute keys, and how allowed_values interacts with select types, which clarifies the loosely typed attributes parameter.

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 opening sentence 'Create a term type — the template that fixes what a term must carry' names the exact verb, resource, and purpose. It clearly distinguishes this from sibling tools like create_glossary_term and update_glossary_term_type by explaining that a term type defines attributes every term must hold.

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 the design context, noting that without this tool types can only be created in the SAS UI, so MCP users can design glossaries through it. It doesn't explicitly list when not to use it or name alternatives, but the role is clear enough.

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

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

Beyond the annotations, the description discloses that the tool verifies table memory scope before proceeding and returns an actionable error otherwise. It also explains how the data-table URI is constructed. This adds meaningful behavioral context that the annotations and schema do not provide. It does not mention the auto_run default side effect, but the core verification behavior is clearly 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 compact and front-loaded: the main purpose appears first, followed by a dense but relevant prerequisite paragraph. Every sentence contributes either purpose, precondition, error behavior, or parameter context. No filler or repetition is present.

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 9-parameter creation tool with a full schema and output schema present, the description covers the critical prerequisite, verification behavior, and URI construction. It does not explain the auto_run side effect or the meaning of prediction_type, but the schema already handles parameter definitions. The main gap is the lack of mention that creation may trigger automatic pipeline runs.

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 schema already documents all parameters. The description adds extra value by explaining that the data-table URI is built from server_id/caslib_name/table_name and by emphasizing the memory/scope requirement for the table. This helps the agent understand relationships between parameters beyond their individual 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 opens with a specific verb and resource: 'Create a new AutoML pipeline automation project from a CAS table.' This clearly distinguishes the tool from siblings like list_ml_projects, run_ml_project, and other create_* tools. The source is specified as a CAS table, which immediately orients the agent.

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 the precondition that the training table must be loaded into CAS memory at global scope, and references promote_table_to_memory and list_source_tables as the relevant helpers. It does not explicitly contrast with list_ml_projects or run_ml_project, but the prerequisite and pointer to alternative preparation tools provide strong 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?

The description adds meaningful behavioral details beyond the annotations: the atomic creation behavior, the empty default 'Page 1' prepended before operations, and the created summary carrying object names/labels that follow-up placement and exports target. These are non-obvious side effects an agent needs to know. It does not contradict the destructiveHint or readOnlyHint 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 dense but well-structured, front-loading the core purpose and then layering in return semantics, behavioral caveats, and verification guidance. A few details are repeated or could be trimmed given the output schema exists, but every sentence adds functional 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 tool with four parameters, an output schema, and a destructiveHint annotation, the description covers all the important operational aspects: creation modes, atomicity, default page behavior, return shape, follow-up editing, and verification guidance. There are no critical gaps that would prevent an agent from invoking 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that operations can 'bind data, add pages, add objects' and are applied atomically at creation, which clarifies the operations parameter's role versus using apply_report_operations later. It also frames the result as an empty shell when operations are omitted.

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 action ('Create a Visual Analytics report') and a concrete deliverable ('return its id for further edits'), distinguishing it clearly from sibling tools like list_reports, get_report, and delete_report. It also clarifies the two creation modes: an empty shell or a full atomic build via 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 explicitly tells the agent to feed the returned id to apply_report_operations for further editing, and to verify page-by-page with export_report rather than a whole-report export. It also explains when the operations parameter is preferable, namely to avoid leaving an empty report behind if later edits fail.

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 declare destructiveHint and idempotentHint. The description adds 'Permanently' to reinforce irreversibility and narrows the target to a single rule within a rule set, but does not disclose additional behavior such as effect on the parent rule set or response on repeated deletes.

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 focused sentence with the action and object front-loaded; no filler or repetition of structured fields.

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 two-parameter delete operation, the description, 100% schema coverage, idempotent/destructive annotations, and presence of an output schema cover the essentials. A brief note on prerequisite existence or effect on the ruleset would round it out, but nothing critical is missing.

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

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

Schema coverage is 100% and both parameters already have clear descriptions, including the important guidance that ruleset_id expects a UUID, not a name. The tool description itself adds no parameter information beyond what the schema provides, so baseline 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?

States a specific action ('Permanently delete') and a specific resource ('a rule from a SAS Business Rules rule set'), clearly distinguishing it from sibling tools like delete_business_ruleset or update_business_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?

The description implies the tool should be used when a rule must be permanently removed, and 'permanently' signals irreversibility, but it does not explicitly contrast with update/get/list alternatives or state any prerequisites 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 mark this as destructive and non-read-only; the description adds meaningful context by stating the deletion is permanent and that deletion of a referenced ruleset fails. This goes beyond the structured annotations without contradicting them.

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

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

The description is two sentences with no filler. The primary action is stated first, and the crucial warning is placed immediately afterward. Every sentence earns its place.

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

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

For a one-parameter destructive operation with annotations and an output schema, the description adequately covers the critical precondition and failure mode. An agent can correctly decide whether to call this tool or first verify decision-flow references.

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, including a clear explanation that ruleset_id is a UUID and not a name. The tool description itself adds no additional parameter-level detail, so the high schema coverage justifies the baseline score 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 verb 'delete' and the specific resource, 'SAS Business Rules rule set,' which distinguishes it from siblings like delete_business_rule and delete_decision_flow. The phrase 'Permanently delete' makes the action 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 gives an explicit precondition: only call once the rule set is confirmed unused by any decision flow, and it warns that deletion fails if still referenced. It does not name specific sibling tools to use for checking dependencies, so it stops short of full 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the description needs to add value beyond that. The word 'permanently' clarifies that deletion is irreversible rather than a soft delete or trash operation, and the parameter note '(not its name)' discloses that supplying a name will not work — both are genuine behavioral facts not present in the 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 a single eight-word sentence with the action front-loaded, and the parameter description packs three pieces of guidance into one compact sentence. There is no filler, repetition of schema details, or redundant phrasing.

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 single-parameter tool with full annotations (destructive, idempotent, read-only), an existing output schema, and a parameter description covering the main pitfall (UUID vs name), the definition is nearly complete. The only gap is unspecified cascade behavior, such as whether revisions or publish state affect deletion, which would be nice but is not essential at this complexity level.

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 decision_id description goes beyond a simple field label by specifying the required format (UUID), stating a negative constraint (not its name), and naming the sibling tool that returns both identifiers. This materially helps an agent invoke the tool correctly on the first attempt.

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 and resource: 'Permanently delete a SAS Intelligent Decisioning flow.' The qualifier 'permanently' adds meaningful nuance beyond a generic delete, and the resource is precise enough to distinguish this from sibling deletes like delete_business_ruleset, delete_glossary_term, and delete_report.

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

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

The main description gives no explicit when-to-use or when-not-to-use direction. However, the decision_id parameter description supplies indirect usage guidance by clarifying that a UUID is required, not a name, and pointing to list_decision_flows as the discovery path. This covers the prerequisite but omits exclusions such as alternatives for reversible deletion or interaction with lock/publish states.

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 and idempotentHint annotations, the description discloses concrete side effects: assignments to columns are removed while columns remain, there is no cascade, and the existence of children is a hard block with an exact error message. This is exactly the behavioral context an agent needs before invoking a destructive 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 front-loaded with the core action and then organizes caveats in a clear order: impact, precondition check, no-cascade rule, and remediation steps. The longer length is justified because every sentence conveys a distinct, decision-relevant fact for a destructive 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?

For a one-parameter destructive tool, the description covers side effects, prerequisites, failure modes, error text, and workarounds. The output schema exists, so return value documentation is not required, and the description leaves no material gap for an agent to invoke the tool correctly.

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

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

Schema coverage is 100% and the only parameter term_id is already described as 'The glossary term UUID.' The description does not add new meaning about how to obtain or format term_id, but it also does not need to; the schema carries the required semantic weight.

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 opening sentence uses a specific verb and resource: 'Permanently delete a business term.' This clearly distinguishes the tool from sibling glossary operations such as delete_glossary_term_type and update_glossary_term, while the rest of the description reinforces that it operates on a term and its assignments.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: check list_term_assets before deleting because a term with assigned assets is in use, and do not attempt deletion when the term has children ('cannot be deleted at all'). It also names actionable alternatives: delete the subtree leaf-first via list_glossary_terms(parent_id=...) or re-parent with update_glossary_term.

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 annotations (destructiveHint=true, readOnlyHint=false), the description discloses a key behavioral consequence: deleting the type takes the attribute definitions of terms using it with it. It also reveals that the tool refuses by default and only proceeds with force, which is not obvious from the annotations alone.

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 compact and front-loaded: it states the core action first, then adds necessary caveats and instructions in just three sentences. Every sentence earns its place; there is no redundant 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?

For a destructive tool with two parameters and full schema coverage, the description is complete enough. It explains the refusal behavior, the destructive side effect, the recommended prerequisite check, and the force option. The output schema is available, so return values do not need to be described.

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 provides 100% coverage for both parameters, including clear descriptions for term_type_id and force. The description adds context around force (passing it when you have already decided), but it largely duplicates the schema's semantic content rather than introducing new meaning.

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

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

The description opens with the specific action and resource: 'Delete a term type.' This clearly distinguishes it from sibling tools like delete_glossary_term (which deletes a term, not a term type) and from create/update glossary term type tools. It leaves no ambiguity about 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 explicitly states when the tool will refuse (while terms still use the type), what to do instead (check with list_glossary_terms and move/delete those terms first), and when to use the force parameter (if you have already decided). This provides actionable guidance and clears up the main decision point for using the tool.

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

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

Annotations already mark this as destructive and idempotent. The description adds useful context beyond that: it deletes the report's content, there is no per-object undo, and the API returns specific statuses like not_found and delete_failed. This enriches the behavioral model without contradicting 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 compact and front-loaded with the core action, followed by only the most decision-relevant behavioral details: no undo, copy-first workaround, and return statuses. Every sentence adds value and nothing is redundant.

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 one-parameter destructive tool, the description covers the scope of deletion, irreversibility, a practical workaround, and expected return states. With annotations providing destructiveness/idempotency and an output schema available, an agent has enough context to invoke this tool correctly.

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

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

The sole parameter report_id is already fully described in the input schema with 100% schema description coverage. The description does not add extra meaning to the parameter itself, which is acceptable since the schema provides sufficient 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 specific verb-resource pair: 'Delete a Visual Analytics report and its content.' This aligns with the tool name and distinguishes it from other sibling delete tools (e.g., delete_decision_flow, delete_business_ruleset, delete_glossary_term) by explicitly targeting reports.

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

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

The description gives clear usage context by noting there is no per-object undo, and suggests deleting and rebuilding or copying first as the way to discard an unwanted report. It implies copy_report as an alternative for preservation but does not explicitly name it or define exclusion conditions.

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 declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context: it reads a bundled catalog with no network access, making it a cheap and reliable lookup. This goes beyond the structured 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 compact and front-loaded: the core purpose appears in the first sentence, and the usage guidance follows in the second. Every sentence earns its place with no filler 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?

The description covers what the tool does, when to use it, how it behaves, and why it is preferable in this situation. Combined with full schema descriptions and an output schema, nothing essential is missing for an agent to select and 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?

Schema description coverage is 100%, and each parameter already has a meaningful description with examples. The tool description does not need to restate parameter-level details, so the baseline score of 3 is appropriate.

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

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

The description clearly states what the tool does: discover what a Visual Analytics report can contain—operations and objects. It uses a specific verb and resource, and distinguishes itself from apply_report_operations, 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 explicitly says to call this before apply_report_operations to learn how to build a report, and frames it as the cheap way to look up data roles instead of guessing. This gives the agent a clear selection rule relative to a key sibling tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns file content, but does not disclose additional behavioral details such as response format, size limits, or authentication needs. With annotations present, this is 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 a single, focused sentence with no wasted words. It front-loads the action and clearly states the resource context.

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?

This is a simple tool with one required parameter, complete schema coverage, rich annotations, and an output schema. The description sufficiently conveys the operation for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% and the single parameter file_id is already described as 'ID of the file to download.' The description adds no semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Download file content from the Viya Files Service.' This clearly identifies the action and the object, distinguishing it from list_files and upload_file, though it does not explicitly name those alternatives.

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

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

The description offers no guidance on when to use this tool versus alternatives such as list_files or upload_file. There is no mention of exclusions, prerequisites, or conditions under which a different tool should be selected.

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

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

The description discloses state persistence across calls, the creation and execution of a job definition, and the concrete risk of leftover session state causing double-counting on re-runs. This goes well beyond the annotations' destructiveHint and readOnlyHint flags, surfacing a non-obvious behavioral trap that could otherwise lead an agent to produce incorrect results.

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 front-loaded with a one-sentence purpose, then uses clearly marked IMPORTANT and Tip sections for operational guidance. Each paragraph earns its place: the state-persistence warning prevents a real failure mode, and the CAS tip saves an agent from avoidable log noise. There is no padding or repetition beyond the concise actionable restatement of the clean-session remedy.

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 runs arbitrary SAS code, the description covers the core action, the session-persistence failure mode, the clean-slate remedy, the job-definition lifecycle, and a practical CAS data-access recommendation. An output schema exists to document return values, and both parameters are fully described, so no critical invocation detail is missing.

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

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

The input schema already documents both parameters at 100% coverage. The description adds meaningful context for fresh_session by explaining the shared warm compute session and explicitly linking fresh_session=True to reset_compute_session, which helps an agent decide when to use the parameter. It does not add syntax-level detail for sas_code, but the schema description is already sufficient there.

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 first sentence states a clear verb (Executes), direct object (provided SAS code), environment (Viya), and outcome (returns information about the completed Job). It does not explicitly contrast with siblings like submit_batch_job or query_data, so an agent may need to infer selection from the name and schema rather than being told, but the core action is unmistakable.

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 IMPORTANT note gives concrete usage guidance: pass fresh_session=True when code must start clean, and mentions reset_compute_session as an equivalent alternative. It also offers a practical CAS data-access preference over caslib _all_ assign. However, it never states when to choose execute_sas_code over execution/data siblings such as submit_batch_job or query_data, so explicit exclusions are absent.

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 establish readOnly, idempotent, and non-destructive behavior. The description adds further useful behavioral context: it notes synchronous export endpoints, explains what each format produces (e.g., package bundles source files and query results), and documents pass-through options for PDF rendering. This goes beyond the annotations without contradicting them.

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 front-loaded with the core purpose and then organized into a compact, scannable format list. Every line conveys necessary operational detail, and the bullet structure makes format-specific rules easy to parse without unnecessary prose.

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

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

Given no output schema, the description could more explicitly state what the caller receives back (e.g., binary file content, download URL, or saved artifact). However, it covers the format-specific input constraints thoroughly and describes the exported artifacts well enough that an agent can invoke the tool correctly for most cases.

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 already describes all parameters at 100% coverage, and the description substantially enriches that meaning by tying each export_format value to the exact parameter requirements: package/pdf accept multiple objects, png/svg require image_size, csv/tsv/xlsx require exactly one object, and summary accepts none. This is high-value semantic guidance 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 states a specific action ('Export a Visual Analytics report') and resource ('report or specific report objects'), and enumerates the supported formats. It clearly differentiates this from siblings like list_reports and get_report, which manage or inspect reports rather than export their content.

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 when to use the tool for exporting report content in various formats, and even specifies per-format constraints such as image_size for png/svg and exactly one object for data formats. It does not explicitly name alternative tools or state exclusions, but the export-focused purpose is unambiguous relative to the listed siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description reinforces the read-only nature ('Fetch') but adds no extra behavioral detail such as not-found behavior or version handling, which is acceptable given the annotation coverage.

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 that states the action, target, and scope with no filler or repetition. It is concise yet fully 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?

The tool has only two required string parameters, full parameter descriptions, strong safety annotations, and an output schema. The description provides enough context for an agent to select and invoke the tool correctly; no critical information is missing.

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

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

Schema coverage is 100%; both parameters have clear descriptions (rule_id is the rule UUID, ruleset_id is the parent ruleset UUID and not its name). The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Fetch') and resource ('a single rule's definition') scoped to 'a SAS Business Rules rule set.' This clearly differentiates it from list_business_rules (plural/list) and get_business_ruleset (ruleset-level read).

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

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

The description gives clear context: the tool is for retrieving exactly one rule definition from a ruleset. It doesn't explicitly name alternatives like list_business_rules, but the singular 'rule' wording and the ruleset scope make the intended use case evident without 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds little behavioral context beyond 'single' and 'by ID,' but it does not contradict the 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 a single, front-loaded sentence with no filler. Every word contributes to stating what the tool does.

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 one-parameter, read-only, idempotent fetch operation with an output schema present and strong annotations, the description plus schema is fully sufficient for an agent to call the tool correctly.

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

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

The schema has 100% description coverage for the single parameter and clearly explains that ruleset_id is a UUID, not a name, and that list_business_rulesets returns both. The description itself adds no additional parameter meaning, so the baseline 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 uses a specific verb ('Fetch') with a clear resource ('a single SAS Business Rules rule set') and the retrieval criterion ('by ID'). This distinguishes it from list_business_rulesets (which lists many) and from get_business_rule (which fetches a rule, not a rule set).

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

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

The description implies the tool is used when you already have the rule set UUID and want a single rule set, and the parameter description notes that list_business_rulesets returns both names and UUIDs. However, the main description does not explicitly state when to use this tool versus alternatives like get_business_rule or list_business_rulesets.

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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context by explaining that a missing table returns a structured not_found with the two usual causes instead of a raw HTTP error, which is genuinely useful for an agent handling failures.

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 compact and front-loaded with the core purpose. The first sentence states exactly what the tool does, and the second adds a meaningful error-behavior note. No filler or redundancy is present.

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 read-only annotations, fully documented parameters, and presence of an output schema, the description covers the essential operational behavior well, including the missing-table edge case. It could be more complete by naming alternatives or clarifying when to prefer this over the similarly named column/table tools, but nothing critical is missing for calling the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds no additional parameter-level meaning beyond framing the operation as column metadata retrieval; it does not explain relationships, formats, limits, or edge cases for server_id, caslib_name, or table_name.

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 ('Get'), the resource ('column metadata for a CAS table'), and the specific fields returned ('names, types, labels, formats'). This is more precise than the bare title and distinguishes it from data-returning tools like get_castable_data, though it does not explicitly differentiate from sibling tools such as list_compute_columns.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like list_compute_columns, list_castables, or get_castable_info. There are no prerequisites, exclusions, or conditional routing hints; the usage context is only implied by the tool's purpose.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds little behavioral context beyond 'Fetch rows,' and does not discuss pagination behavior, limits, or output structure, but 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 a single concise sentence with no filler or repetition. It front-loads the core action clearly, though it could usefully mention pagination or the distinguishing data-returning nature relative to sibling tools.

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, comprehensive parameter schema, and supportive annotations, so many operational details are already structured. However, given the large sibling list with similar get_castable and query tools, the description is too sparse to fully disambiguate tool selection.

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 every parameter is already documented with type, requirement, and meaning. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Fetch rows from a CAS table with column names.' This clearly indicates the tool retrieves data rather than metadata. It does not explicitly differentiate itself from close siblings like get_castable_columns or query_data, so it falls short of a 5.

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 offers no guidance on when to choose this tool over alternatives such as get_castable_columns, get_castable_info, list_castables, or query_data. It does not mention exclusions, prerequisites, or preferred contexts, leaving the selection decision to inference.

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 aligns with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) by presenting a non-destructive read operation. It adds useful behavioral context by specifying the kind of metadata returned, such as row count and size, without contradicting any 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 a single, scannable sentence that front-loads the core purpose ('Get metadata') and immediately includes concrete output examples. Every word contributes value, and there is no redundant restating of the tool name or title.

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

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

For a simple read-only metadata lookup, the description is complete. The annotations declare safety, the schema documents all required parameters, and an output schema exists, so the description does not need to explain return values or side effects.

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 provides 100% description coverage for all three parameters (server_id, table_name, caslib_name). The tool description does not add further parameter-level meaning, but the baseline of 3 is appropriate since the schema carries the semantic burden.

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 ('Get'), a resource ('metadata for a CAS table'), and concrete examples ('row count, column count, size'). This clearly distinguishes it from sibling tools like get_castable_data or get_castable_columns, which retrieve table contents or column definitions rather than metadata.

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 when to use the tool: when you need table-level metadata rather than actual data or column lists. However, it does not explicitly name alternatives like get_castable_columns, get_castable_data, or list_castables, nor does it state when not to use this tool.

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

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

The annotations already declare readOnly, idempotent, and non-destructive, and the description enriches beyond that: it works through the compute session's data API (not SQL), formats values as SAS displays them, and exposes WORK tables from prior execute_sas_code calls. These are behavioral specifics that no annotation carries.

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 front-loaded with a concise one-line purpose, then two tightly written paragraphs that earn their place: one differentiates from siblings and states the trade-offs, the other clarifies session semantics. No filler or repeated schema 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?

For a read-only paginated fetch tool with a full input schema, the description is complete: it covers alternative tools, output format behavior ('dates as text, numbers with their format applied'), session visibility, and when to avoid this tool. No missing information an agent would need 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?

Schema coverage is 100%, so the baseline applies: the input schema already documents all five parameters with descriptions and defaults. The description adds useful session-level context (e.g., what compute_context_name means for visibility of WORK tables), but does not systematically add per-parameter meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Fetch rows from a table in a SAS library, with column names.' It immediately distinguishes itself from siblings: it is the compute-tier counterpart of get_castable_data and not query_data, clarifying exactly what this tool does differently.

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 context is explicit: it contrasts with get_castable_data and names query_data with target='compute' as the right choice when raw numerics, a WHERE clause, or a join are needed. It also notes the session-aware nature ('as the session sees it'), which tells an agent precisely when this is the right fetch operation.

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 declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description's 'Fetch' wording is consistent with these annotations, but it adds little behavioral detail beyond them, such as what exactly the current state includes or whether a missing/invalid decision_id produces a specific error. This is adequate given the annotation coverage, 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 one tight sentence with no filler or redundancy. It front-loads the core action and resource, and every word contributes to understanding what the tool does.

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 single-parameter read-only tool with a full output schema and complete annotations, the description is sufficient for basic invocation. The only slight gap is that it does not clarify the distinction from get_decision_flow_revision or get_decision_flow_code, but the sibling list and parameter hint partially compensate. Overall, nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 100%, and the single parameter is already well documented in the schema: it requires a UUID, explicitly warns against using the name, and points to list_decision_flows for retrieval. The tool description itself adds no additional parameter semantics, so the baseline of 3 applies per the rubric.

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 ('Fetch') and a clear resource ('current state of a SAS Intelligent Decisioning flow'), which immediately signals this is a read/detail operation rather than a create, update, delete, list, or code-generation tool. It is distinguishable from siblings like get_decision_flow_code and get_decision_flow_revision by the 'current state' phrasing, though it does not explicitly name those alternatives.

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

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

No explicit when-to-use or when-not-to-use guidance is present. The parameter description helps by clarifying that decision_id is the UUID (not the name) and points to list_decision_flows for obtaining both, which is useful contextual usage guidance. However, it does not explain how this tool differs from get_decision_flow_code, get_decision_flow_revision, or list_decision_flows in terms of 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no additional safety disclosure is needed. The description adds no extra behavioral traits such as output shape or error conditions, but it also does not conflict with the 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 a single sentence with no redundancy, front-loading the action and object. Every word contributes meaning.

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 single-parameter read-only tool with an output schema and strong annotations, the description fully identifies the resource. No essential context is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100% and the single parameter already carries a detailed explanation ('UUID (not its name — list_decision_flows returns both)'). The description adds no parameter-level information, matching the baseline when the schema fully documents 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 ('Retrieve') and names a specific resource ('generated DS2 execution code for a decision flow'). This clearly distinguishes it from siblings like get_decision_flow, which would return the flow definition rather than its compiled code.

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 makes the intended use case clear: call this when the generated DS2 code is needed. It does not explicitly name alternatives or state when not to use it, but the resource phrasing is specific enough that an agent is unlikely to confuse it with related decision-flow 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful context by specifying that the revision is 'locked,' which is a relevant behavioral constraint beyond the schema and 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 a single, front-loaded sentence with no filler or repetition. Every word adds meaning, and it conveys the essential purpose efficiently.

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 a simple interface, a complete output schema, and strong annotations, so the description is largely sufficient. The only minor gap is that it does not mention failure scenarios, such as what happens if the revision does not exist or is not locked, but for a straightforward read operation this is 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 description coverage is 100%, so both parameters are already fully documented in the schema. The description does not add further parameter-level meaning beyond the generic reference to a 'specific locked decision revision,' so the baseline 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 the verb 'Fetch' and the resource 'content of a specific locked decision revision.' This distinguishes it from sibling tools like get_decision_flow (which retrieves a flow) and list_decision_flow_revisions (which lists revisions).

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

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

The description implies the tool is for retrieving a specific locked revision's content but does not explicitly state when to use it over alternatives like list_decision_flow_revisions or get_decision_flow. No when-not-to-use guidance or alternative tool suggestions are provided.

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

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

Beyond the read-only and idempotent annotations, the description reveals the output transformation: attributes are resolved from UUID keys to UI labels, empty attributes are dropped, attribute_ids remains the raw unfiltered map, and the two intentionally disagree. It also explains the separate catalog_entity_id semantic. This is substantial added 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 front-loaded with the core purpose and then uses two short paragraphs to explain the non-obvious attribute resolution behavior. Every sentence adds necessary information, including the design rationale for the attributes/attribute_ids discrepancy, with no filler.

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 single-parameter, read-only, idempotent tool with an output schema, the description covers everything an agent needs to correctly interpret the result: resolved attributes, raw attribute_ids, empty-value semantics, and catalog_entity_id. No critical operational detail is missing.

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

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

Schema description coverage is 100%, and the parameter description already documents the term_id UUID and its distinction from catalog_entity_id. The tool description adds no further parameter-level meaning, so the baseline 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 opens with a specific verb and resource: 'Get one business term in full', and immediately states a distinguishing behavior — custom attributes are named rather than hashed. This separates it from get_glossary_term_type and the glossary list/search tools without requiring schema inspection.

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 first sentence makes the context clear: use this when you need exactly one full term. The parameter schema adds that term_id is the term UUID and notes search_glossary_terms returns both IDs, providing useful disambiguation, though it never explicitly states when not to use this tool or names an 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?

Beyond the annotations, the description reveals the exact contents of the response: every custom attribute, data type, requiredness, allowed values, and value_format, including the caveat that value_format is undocumented in the API. It also explains how the output vocabulary maps to create_glossary_term, which is 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?

The description is front-loaded with a one-sentence purpose, followed by a compact but dense usage callout. Every sentence earns its place, and the emphasis on 'before' is prominent.

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 a single well-documented parameter, an output schema, and read-only/idempotent annotations, the description supplies the missing contextual piece: why and when to call this before creating or updating a glossary term. No essential information for correct invocation appears absent.

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 the schema already explains that term_type_id accepts a UUID or name with list_glossary_term_types returning both. The description adds no further parameter-level detail, so the baseline 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 opening sentence names a specific verb and resource: get a term type and the attribute contract its terms must satisfy. It clearly differentiates this from sibling list_glossary_term_types by focusing on the detailed contract needed for term creation/updating, not just a list of types.

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 'Call this before creating or updating a term,' which anchors the primary use case. It does not explicitly state when not to use it or name alternatives like list_glossary_term_types in the tool description, though the schema references that tool for resolving IDs/names.

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