sas-mcp

by matise-joe-norc

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools target a distinct resource and action: config selection, code execution, dataset metadata, file transfer, and comparison. A few overlapping boundaries exist—session_status overlaps with list_libraries/list_datasets for a quick overview, and run_sas vs. run_sas_tests both submit code—but the descriptions make the intended use clear.
Naming Consistency4/5
The majority follow a clear verb_noun pattern such as list_datasets, describe_dataset, compare_datasets, and download_from_sas. The exceptions are session_status and sas_doctor, which are noun-led and break the otherwise predictable scheme.
Tool Count4/5
Sixteen tools is slightly above the typical 3–15 sweet spot, but each tool maps to a distinct part of the SAS workflow: connection management, session state, code execution, file transfer, metadata inspection, and validation. The count feels justified rather than bloated.
Completeness4/5
The surface covers the core SAS lifecycle well: configure/connect, inspect session and datasets, run code, retrieve logs, transfer files, compare tables, and run tests. Minor gaps exist—no explicit disconnect tool or direct file deletion—but these do not create dead ends since run_sas and session management cover most of them.
Average 4.2/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on September 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: assertions are returned as pass/fail results along with log triage, and the assertion macro library is available. However, annotations provide no safety profile (all hints false), and the description does not address side effects, session state, error behavior, or whether execution is isolated.
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?
The opening sentence front-loads the purpose and return behavior, and the macro list is useful despite being somewhat lengthy. Every element earns its place, though the macro enumeration could be trimmed or summarized without much loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return values do not need full explanation in the description. The description is complete enough for selecting and invoking the tool: it covers purpose, available macros, and the intended validation use case. Minor gaps remain around `include_log` and interaction with session state, but these are not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly clarifies that `code` holds SAS code with assertions, but `include_log` is never mentioned or explained. The description adds meaning for only one of the two parameters and leaves the boolean parameter's behavior to inference.
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 names a specific verb and resource: 'Run SAS code' with the assertion macro library available, and states the distinct return of assertion pass/fail results alongside log triage. This clearly separates it from sibling tools like run_sas, which lacks the assertion-specific output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'Use this to validate code you have written.' It lists the available assertion macros, so an agent knows what kinds of validation are supported. It does not explicitly say when not to use it or name run_sas as the alternative for plain execution, but the intended use case is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate non-read-only, non-idempotent, non-destructive behavior. The description adds useful context about the transfer-directory constraint and the SAS connection, but does not disclose overwrite behavior, collision handling, or failure modes. With annotations present, the bar is lower, and the description provides reasonable but not rich extra context.
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?
Two sentences with no filler: the first states the operation, the second states the boundary and fallback. The key constraint is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the source constraint and the transfer direction, and an output schema is present. However, it omits important operational details such as remote_path format, what overwrite=true actually does, and what happens on failure, leaving an agent to guess in realistic scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden of explaining parameters. It clarifies that local_name refers to a file in the transfer directory, but remote_path and overwrite semantics are not addressed at all. The schema only provides names and a default, which is insufficient for reliable invocation.
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 states a specific action—'Send a file from this server's transfer directory to the SAS server's filesystem'—with clear directionality, source, and destination. It distinguishes itself from sibling tools like download_from_sas by making the upload direction explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context and a hard precondition: only files already in the transfer directory can be sent, and other files must be copied there first. It does not explicitly name alternatives, but the constraint and fallback instruction effectively guide an agent on when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds behavioral detail beyond that by specifying the structured output: whether data sets are identical, whether differences are in data or metadata, and the specific kinds of differences. It does not contradict the annotations.
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?
Two sentences with no unnecessary words. The first sentence front-loads the core function and output; the second provides the key use case. It is concise, structured, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output, and primary use case, and the output schema can define the return structure. However, given 0% schema parameter coverage, the optional `by` and `criterion` parameters are left unexplained, and there is no mention of SAS session prerequisites or behavior when the session is unavailable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It clarifies that base and compare are the two data sets, but it gives no explanation of `by` or `criterion`. These optional parameters are left ambiguous despite being important for controlling how the comparison is performed.
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 uses a specific verb and resource: 'Run PROC COMPARE between two data sets' and clearly states what the tool returns: a structured diff with identity, data-vs-metadata distinction, and difference kinds. It distinguishes itself from sibling tools like run_sas and describe_dataset by focusing on comparison-based validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear primary use case: 'the primary way to validate that a rewrite produces the same result as the original.' This provides meaningful context for when to choose this tool, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so the safety profile is covered. The description adds behavioral context: the log is 'full raw' (not triaged), it's from the 'most recent submit', and it warns that logs 'consume a lot of context' — a useful cost signal beyond the annotations. It does not describe output format, but that is covered by the output schema.
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?
Two sentences with zero waste. The primary action is front-loaded, and the advisory note is concise. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two optional parameters), and an output schema exists, but the complete lack of parameter guidance is a notable gap. The description clearly states purpose, usage, and cost, so the agent can decide when to call it, but may not know how to tailor calls (e.g., max_lines) without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description does not mention 'from_end' or 'max_lines' at all, leaving the agent to guess their meaning. While the names are somewhat self-explanatory, the tool description adds no value beyond the schema, failing to compensate for the low 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 states a specific verb and resource: 'Return the full raw SAS log from the most recent submit.' It clearly distinguishes itself from run_sas by contrasting the raw log with the 'triaged output' from run_sas, so an agent can tell them apart.
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?
The description explicitly states when to use this tool: 'Use only when the triaged output from run_sas was not enough to diagnose the problem.' It also gives a reason (logs consume a lot of context), which helps the agent avoid unnecessary calls. This directly addresses usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds useful context by specifying exactly what the listing includes (row counts, column counts, modification dates). This goes beyond the schema and gives the agent a clearer picture of the tool's output behavior.
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?
A single, front-loaded sentence with no filler. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and details of the output, and an output schema is present to define return format. It does not mention practical caveats like requiring an active session or behavior on invalid libref, but these are minor for a simple read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly describes the only parameter (libref) by mentioning 'SAS library', but it does not explicitly define libref as the library name or clarify any formatting requirements.
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 uses a specific verb ('List'), a clear resource ('data sets in a SAS library'), and adds distinguishing detail (row counts, column counts, modification dates). This makes it easy to differentiate from siblings like list_libraries (libraries) and describe_dataset (single dataset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs an inventory of datasets in a library, but it does not explicitly state when to use it versus alternatives like list_libraries or describe_dataset, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description aligns by describing a non-mutating inspection operation. It adds useful behavioral context by specifying the returned information and framing the tool as a preliminary inspection step. No contradiction.
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?
Two sentences with no filler. The primary output is stated first, and the second sentence provides a practical usage guideline. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small read-only tool with an output schema, the description covers what it returns and when to call it. The main gap is parameter semantics, but the simple required parameters and the output schema keep it sufficiently complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 0%, and the description does not explain what 'libref' and 'table' mean beyond the phrase 'SAS data set.' An agent must rely on parameter names and SAS domain knowledge to understand that libref is the library reference and table is the dataset name.
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 states a specific action ('Return the columns of a SAS data set') and a specific resource, enumerating the metadata fields plus row count. This distinguishes it from sibling tools like list_datasets or sample_rows by describing a metadata introspection operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage recommendation: 'Call this before writing code against a table you have not already inspected.' It does not name alternative tools or explicitly state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds useful context about the tool's role in verifying actual output locations on the server filesystem. It does not contradict the annotations and gives enough behavioral framing for a read-only list operation.
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 two sentences with no filler. The first sentence states the core function, and the second provides actionable usage guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool with an output schema present, the description covers what the tool does and when to use it. The only notable gap is the lack of path specification details, but the presence of an output schema mitigates the need for describing return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'path' parameter's expected format, whether it is absolute/relative, or any constraints. Saying 'directory on the SAS server's filesystem' is only minimally helpful; the description should compensate for the lack of schema documentation but does not.
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 uses a specific verb ('List') and resource ('a directory on the SAS server's filesystem'), clearly distinguishing this from siblings like list_libraries and list_datasets, which operate on SAS logical structures rather than the filesystem. It also connects the tool to a concrete workflow: confirming where a step wrote output before downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives a clear use case: 'Use it to confirm where a step actually wrote its output before downloading.' This provides context for when to invoke the tool, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the operation is safe, and the description's 'Return' is consistent with that. Beyond the annotation, the description adds that the result is a prefix of rows ('first N') and that it exposes raw content like actual values and missingness, helping the agent anticipate the output nature.
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 a single, action-first sentence with no filler. It states what the tool returns and why, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, read-only sampling tool with an output schema and readOnlyHint annotation, the description covers the essential invocation intent and expected return. The main gap is explicit libref/table semantics, but the schema names both as required string fields, so an agent can still invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden of explaining parameters. It clarifies that 'n' is the number of rows to return, but it does not explain 'libref' or 'table' beyond naming a SAS data set generally. The two required parameters remain under-specified.
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 states a specific verb ('Return'), a concrete resource ('first N rows of a SAS data set as records'), and an explicit purpose ('inspect actual values, coding schemes, and missingness'). It is clearly distinguishable from sibling tools like describe_dataset, which would describe metadata rather than raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates when to use this tool: when an agent needs to inspect actual data values, coding schemes, or missingness. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for selection among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations all false, the description carries the burden and adds meaningful behavior: it returns the local path, writes into the server's transfer directory, and rejects arbitrary local paths. It also clarifies that the operation is a copy over the SAS connection, consistent with destructiveHint=false, and no contradiction exists.
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?
Four short sentences, with the core action and destination front-loaded. Every sentence earns its place: what it does, when it works, what it returns, and where files are placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential workflow, return value, and a critical path restriction. Because an output schema exists, omitting a return format is acceptable; it could add overwrite behavior, but the remaining gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that remote_path is a file on the SAS server's filesystem and constrains local destination behavior (transfer directory only, no arbitrary paths), but it does not mention overwrite or explain the local_name parameter explicitly.
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 and resource: 'Copy a file from the SAS server's filesystem to this machine, over the SAS connection.' It makes the transfer direction unmistakable and clearly differentiates this tool from upload_to_sas and list_sas_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: it is the right choice when a file must cross from SAS to this machine, especially when there is no shared filesystem (e.g., PROC EXPORT output on SAS ODA). It does not explicitly name exclusion conditions or alternatives, but the transfer direction and cross-filesystem note are enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds relevant behavioral context by stating the tool diagnoses 'without connecting' and listing the diagnostic areas it inspects. There is no mutation implied and no contradiction with annotations. It does not describe output details, but an output schema exists to carry that burden.
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 compact and front-loaded: one dense sentence enumerates the diagnostic scope, and a short imperative sentence gives usage guidance. There is no filler, and every phrase adds distinctive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only diagnostic tool with an output schema, the description covers scope and usage well: it names the diagnostic categories, says to run it first on connection failure, and clarifies it does not connect. The only notable gap is that the optional probe_network parameter is only implied rather than explicitly tied to the parameter name, but the schema and default mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single probe_network parameter. The phrase 'network reachability' maps plausibly to probe_network, but the parameter is never named and its effect when set to false is left to inference. The schema's default helps, but the description adds only partial semantic value.
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 uses a specific verb ('Diagnose') and a clear resource ('SASPy configuration'), then enumerates exactly what is checked: config file, connection method, Java runtime, .authinfo, ODA hostname, network reachability, and encoding. It also distinguishes itself from siblings with 'Run this first whenever a connection fails,' so an agent can separate it from run_sas or session_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use instruction: 'Run this first whenever a connection fails.' It also clarifies that it operates 'without connecting,' which sets expectations for pre-connection diagnostics. It does not name alternatives or explicitly state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation, and the description aligns with that. It adds meaningful behavioral nuance by distinguishing between what SAS considers read-only and what the server policy permits writing to, which is valuable context beyond the annotations.
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?
A single, well-structured sentence communicates the action, resource, and returned fields without unnecessary words. The key verb and resource are front-loaded, making the description scannable and efficient.
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 that the tool is parameterless, has an output schema, and is annotated as read-only, the description provides sufficient context for correct invocation. The mention of assigned libraries and policy details helps the agent understand the scope and semantics without needing additional explanation.
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?
The tool has zero parameters, so there are no parameter semantics to clarify. The description appropriately focuses on what the tool returns rather than on inputs, and no parameter documentation burden exists.
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 clearly states that the tool lists assigned SAS libraries and enumerates the specific attributes returned: path, engine, SAS read-only status, and server policy write access. This is a specific verb+resource combination that distinguishes it from sibling tools like list_datasets, which operate on datasets rather than libraries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear, so an agent can infer it is appropriate when needing an overview of available libraries. However, it does not explicitly mention when not to use it or contrast it with sibling tools such as list_datasets or describe_dataset, leaving usage boundaries implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is established. The description adds value by mentioning the output contains access method and target server, which is useful context. There is no contradiction with annotations, but the description does not disclose any other behavioral traits beyond what annotations provide.
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?
Two sentences with no redundancy. The first sentence states the core function and output, the second gives usage guidance. Every word earns its place; it's tightly written and well-structured.
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 parameter-less tool with an output schema (present), the description fully covers purpose and usage. There is no missing information that would impede an agent from correctly deciding when to call this tool and what to expect from it.
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?
The tool has zero parameters, and the input schema is empty with 100% coverage. Per the baseline for 0 params, the score is 4. The description does not need to elaborate on parameter semantics.
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 clearly states the verb 'list' and the resource 'SAS configurations', and specifies the information returned (access method and target server). It distinguishes this tool from siblings like use_sas_config (which selects a config) and list_sas_files (which lists files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Call this when connecting reports that a configuration must be chosen, or when the user mentions a specific SAS environment by name.' It does not explicitly list alternatives or exclusions, but the trigger conditions are concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description's verb 'Report' aligns with that. The description adds useful output-scope context, such as the active write policy and WORK datasets, but does not disclose deeper behavioral details like connection behavior or side effects; the read-only annotation lowers the burden and the description does not contradict it.
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 two sentences with no wasted words. The first sentence front-loads the complete list of reported items, and the second sentence adds a practical use case. Every part earns its place.
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?
With no parameters and an output schema available, the description covers the essential context: what the tool reports and when to use it. Nothing an agent needs to decide whether to invoke this tool 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?
The tool has zero parameters, so there is nothing for the description to clarify beyond what the schema already shows. Baseline 4 applies because no parameter documentation is needed.
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 uses a specific verb ('Report') and clearly identifies the resource: the SAS session. It enumerates the exact facets reported (liveness, version, encoding, librefs, WORK datasets, write policy), which distinguishes it from siblings like list_libraries and list_datasets that cover only subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Useful for reorienting after a long conversation.' It provides clear context but does not explicitly mention alternatives or when not to use it, so it stops short of the strongest guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable behavioral detail beyond the annotation: it specifies that librefs and the connection are preserved, and clarifies the exact scope (only WORK datasets). This extra context helps the agent understand side effects.
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?
Two concise sentences, with the action and scope front-loaded. Every word earns its place: the operation, what is preserved, and the rationale for use. No redundancy or filler.
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 zero-parameter destructive tool, the description covers purpose, scope, preservation behavior, and when to use it. The output schema exists, so no need to explain return values. The description is complete for an agent to call it correctly.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. Schema coverage is trivially 100% since there are no parameters.
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 clearly states the action (delete every data set in WORK) and the resource (WORK library), plus the purpose (clear accumulated state). It is distinct from sibling tools like run_sas or session_status, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives a use case: 'Use when earlier intermediate tables are causing confusion.' This provides clear context for when to invoke the tool. It does not mention alternatives or when not to use, but the guidance is sufficient for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a critical side effect: 'Ends any current SAS session, so WORK data sets and librefs from the previous configuration are lost.' This goes beyond the destructiveHint annotation by specifying exactly what is lost, which is essential for an agent to warn the user or verify intent.
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?
Two sentences with no filler. The purpose is front-loaded, followed by the side effect, then usage guidance. Every sentence earns its place and is highly efficient.
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 single-parameter, destructive tool with an output schema, the description covers purpose, usage, and side effects. No additional information is needed for an agent to invoke it correctly; the side-effect warning is particularly valuable for safety.
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?
With 0% schema description coverage, the description compensates by implying the 'name' parameter is the configuration name ('by name', 'names a SAS environment'). It does not explicitly state 'name' is the config name, but the context is strong enough for an agent to infer it. Slight deduction for not being fully explicit.
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 states a specific action (select/connect) on a specific resource (SAS configuration) by name, which clearly distinguishes it from siblings like list_sas_configs (listing) and run_sas (execution). It is not a tautology and provides precise scope.
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?
Explicitly states when to use: 'Use when the user names a SAS environment, or after list_sas_configs shows several.' This gives direct invocation conditions and references a sibling tool for context, making the decision clear without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sas-mcp MCP server](https://glama.ai/mcp/servers/matise-joe-norc/sas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/matise-joe-norc/sas-mcp)

Score Badge

Copy to your README.md:

[![sas-mcp MCP server](https://glama.ai/mcp/servers/matise-joe-norc/sas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/matise-joe-norc/sas-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/matise-joe-norc/sas-mcp'

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