Check a running SAS or Python-in-SAS notebook cell by run ID, optionally waiting for completion, then retrieve its outputs or current status.
A running Python in SAS cell (notebook_sas_python) or SAS cell (notebook_sas_cell): its outputs once done
(waits up to wait_ms, at most 25 s), else its status.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| wait_ms | No |
Changes observed during successful MCP inspections.
v0.11.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes the safety profile, but the description adds a genuinely useful behavior the annotations don't: the call blocks up to wait_ms and is capped at 25 s. It does not disclose what the non-done status looks like, whether outputs remain retrievable on subsequent polls, or what happens if wait_ms exceeds 25 s (clamped vs. error).
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?
It is short and the key constraint (wait behavior) is present, but the sentence is grammatically fragmented with colon-and-else syntax that costs a reading pass. Terseness here trades clarity for brevity rather than earning it.
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 two parameters, no output schema, and no parameter descriptions, the definition should cover the run_id origin and the shape of the returned status/outputs. It covers the timing semantics but leaves the agent guessing about state values and result persistence.
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 bears the burden. It explains wait_ms behavior including the 25 s ceiling, but says nothing about the required run_id (presumably the id returned by notebook_sas_python/notebook_sas_cell) or that wait_ms defaults to 0.
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 resource (the status of a cell submitted via notebook_sas_python or notebook_sas_cell) and tells the agent it returns outputs once finished or status otherwise. That distinguishes it from the launching siblings, though the elliptical phrasing ('A running Python in SAS cell ... : its outputs once done, else its status') makes the agent parse a fragment rather than a sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this after starting a cell to poll for results. It never states when not to use it (e.g. versus notebook_poll or notebook_kernel_state) and doesn't say that wait_ms=0 returns immediately, so the agent must infer the polling pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.