Get Compute Table Data

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.