run_sas

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

Annotations provide no positive safety hints (readOnlyHint is false and destructiveHint is false), so the description carries the burden. It adds important behavioral context by stating 'Writes outside WORK are blocked by policy' and 'The session keeps state between calls,' plus it explains the meaningful triage categories. It could mention side effects on WORK data more explicitly, but the policy boundary significantly clarifies risk.

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 well-structured: purpose and output details come first, followed by the safety constraint and statefulness note. Every sentence contributes useful 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?

For a code-execution tool, the description covers the core action, output shape, safety boundary, and session statefulness, and an output schema handles return-value details. The main gap is the undocumented include_log parameter and the lack of explicit relationships to session-management siblings, but the overall picture is sufficient for correct use in 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?

Schema description coverage is 0%, so the description must explain the parameters. The 'code' parameter is covered implicitly by 'Submit SAS code,' but 'include_log' is never described beyond its schema title and default value. An agent gets little help understanding when or why to set include_log to true.

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 begins with a specific verb and target: 'Submit SAS code to the live session.' It then details what the tool returns, including triaged status, errors/warnings, NOTEs, row counts, and listing output. This clearly distinguishes it from siblings like get_last_log or run_sas_tests, even without naming them.

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

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

The intended use is implied: when you need to run SAS code against the live session, use this tool. However, there is no explicit guidance about when to prefer run_sas over run_sas_tests, or when not to use it, and no alternatives are mentioned.

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