Skip to main content
Glama
Sign In
SAS MCP Server

SAS MCP Server

Official
by sassoftware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Drop Castable

drop_castable
DestructiveIdempotent

Drop a loaded CAS table from memory while keeping its source file on disk. Refuses tables with no saved source unless explicitly allowed, preventing data loss.

Instructions

Drop a table from CAS memory, keeping its source file.

Frees the memory a loaded table takes; promote_table_to_memory loads it again from its source. Nothing on disk is deleted. A table with no source file in its caslib exists only in memory, so dropping it would lose its data: such a table is refused unless allow_unsaved is true. Save it first with save_castable, or ask the user before dropping it. A table that is not loaded is left as it is.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "caslib_name": "<caslib_name>",
      "table_name": "<table_name>"
    },
    "name": "drop_castable"
  }
}

Input Schema

NameRequiredDescriptionDefault
server_idNoCAS server (default ``cas-shared-default``).cas-shared-default
table_nameYesThe table to drop from memory.
caslib_nameYesCaslib of the table.
allow_unsavedNoDrop it even when no source file holds its data (default false). Only with the user's say-so.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.19.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the description only needs added context — and it supplies exactly that: nothing on disk is deleted, unsaved tables are refused unless allow_unsaved, and a not-loaded table is left untouched (no error). Those are the details an agent cannot infer from the flags.

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

Conciseness4/5

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

Front-loaded with the action and the safety-relevant qualifier, then the refusal rule, then the no-op case. Every sentence carries information, though "Frees the memory a loaded table takes" restates the opening clause and could be trimmed.

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?

For a destructive mutation with four parameters and an output schema, the description covers the risk profile, the refusal path, the recovery path via ``save_castable``, and the no-op case. Nothing an agent needs before calling it is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description goes beyond by explaining the consequence of ``allow_unsaved`` (data loss risk, requires user consent) rather than just restating its name. It does not add syntax or default detail for server_id/table_name, which the schema already covers.

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?

States a specific verb and resource ("Drop a table from CAS memory") plus the crucial scope qualifier "keeping its source file", which separates it from a destructive delete. The follow-up sentence naming ``promote_table_to_memory`` and ``save_castable`` makes the boundary against siblings explicit.

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?

Gives explicit when-to-use (free memory of a loaded table), when-not (a table with no source file, unless allow_unsaved), and names the concrete alternatives: ``promote_table_to_memory`` to reload, ``save_castable`` to persist first. It even prescribes asking the user before an unsafe drop.

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

Deploy Server

Other Tools