Skip to main content
Glama
sassoftware

SAS MCP Server

Official
by sassoftware

apply_report_operations

Apply atomic batches of operations to SAS Visual Analytics reports: add pages, objects, set parameters, and change data sources with validation.

Instructions

Apply an ordered batch of operations to a report — the authoring workhorse.

This is how you add pages, add objects (any of the ~60 VA visual, control, and content types), set parameters, and swap data sources. operations is the native SAS Visual Analytics operations array; the whole batch is applied atomically (all succeed or nothing changes).

Operation keys (one per array element): addData, addPage, addObject, updateObject, setParameterValue, updateData, changeData, applyDataView. Call describe_report_objects for each operation's shape (operation="addData" covers formats, aggregations, and geography via dataItems) and each object's data roles, and get_castable_columns to map columns onto those roles.

Layout & titles (see describe_report_objectsplacement / layout_recipes for details):

  • Page title — give addPage a title (e.g. {"addPage": {"pageName": "Overview", "title": "Sales Overview"}}); it becomes a text band at the top of that page's body. Page/report headers accept ONLY control objects — never text or visuals.

  • Chart titles — pass {"options": {"object": {"title": "..."}}} inside the object spec at add time (all types except standardContainer, which takes no options at add time).

  • One-batch multi-page — create pages inline with placement {"report": {"context": "new_page", "pageName": "Trends", "pagePosition": 1}} (numeric position) and target that pageName from later operations in the same batch.

  • Grids/columns — relativeToObject with left/right/top/bottom (geometric) or before/after (flow order) against an EXISTING object's name; same-batch forward references fail, so chain across calls using the names each result returns. Objects are auto-named and auto-sized; placement and dataRoles are write-once (updateObject changes options only).

  • Read structure back anytime with get_report_outline; verify visually with export_report page-by-page (see verify_hint in the result).

The tool validates every operation against the object catalog before any HTTP call (unknown/typo'd object type, non-addable object, bad data-role names or arity, disallowed object/placement keys) and reports ALL invalid operations at once. It also handles the ETag optimistic-concurrency handshake for you, retrying once transparently on a concurrent edit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoValidate and return the normalized payload (plus any soft warnings about missing common roles) without writing anything.
report_idYesTarget report id (from ``create_report`` or ``list_reports``).
operationsYesOrdered native operations array. Example element: ``{"addObject": {"object": {"barChart": {"dataSource": "CARS", "dataRoles": {"category": "Origin", "measures": ["MSRP"]}, "options": {"object": {"title": "MSRP by Origin"}}}}, "placement": {"page": {"target": "Overview"}}}}``.
result_folderNoSave-as target folder URI; omit for My Folder.
response_formatNo``concise`` (default) returns the created page/object/ data-source names+labels; ``detailed`` also echoes the full VA response.concise
result_report_nameNoSave-as — apply the operations to a NEW report with this name, leaving the source report untouched (atomic template instantiation; pairs with ``changeData``).
result_name_conflictNoSave-as name-conflict policy — ``rename`` (default), ``abort``, or ``replace``.rename

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so exceptionally. It reveals atomicity ('all succeed or nothing changes'), pre-HTTP validation with all-invalid-operation reporting, ETag optimistic-concurrency handling with transparent retry, write-once placement/dataRoles, auto-naming/sizing, and the restriction that page/report headers accept only control objects. These are non-obvious traits critical for invocation.

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

Conciseness5/5

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

The description is long but meticulously structured with a leading summary, bulleted layout/title sections, and a final validation/concurrency paragraph. Every section earns its place by addressing a distinct invocation concern for a complex tool with ~60 object types. The front-loaded purpose ensures the agent immediately knows what the tool does.

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

Completeness5/5

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

Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers the full operation lifecycle, layout constraints, multi-page workflow, validation behavior, and concurrency. It deliberately defers exhaustive per-operation shapes to describe_report_objects, which is an appropriate and efficient division of labor. Nothing essential for correct selection or invocation is missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning beyond the raw schema. It explains the operations array structure with a concrete example, enumerates valid operation keys, details layout placement semantics (including geometric vs. flow order, same-batch forward reference failures), and clarifies the save-as behavior via result_report_name. This far exceeds the baseline for high schema coverage.

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

Purpose5/5

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

The description opens with a specific verb+resource: 'Apply an ordered batch of operations to a report.' It immediately distinguishes itself as the authoring workhorse, explicitly enumerating capabilities (add pages, add objects, set parameters, swap data sources) and positioning it uniquely among report-focused siblings like create_report, delete_report, and copy_report.

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

Usage Guidelines5/5

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

It provides clear when-to-use guidance ('This is how you add pages...') and explicitly names companion tools for sub-tasks: describe_report_objects for operation shapes and data roles, get_castable_columns for column mapping, get_report_outline to read structure, and export_report for visual verification. This gives the agent a complete decision tree for related tool alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sassoftware/sas-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server