Lists CAS server caslibs with their type, description, path, and database for SingleStore caslibs to help inspect available data sources.
Caslibs on the CAS server: type, description, path and, for SingleStore caslibs, the database.
| Name | Required | Description | Default |
|---|---|---|---|
| connection | No |
Changes observed during successful MCP inspections.
v0.11.0Input schema / properties / connectionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Connection"
+}v0.10.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already establishes this as a safe read, so the description is not carrying the safety burden. It does add useful context about what the response contains, including a SingleStore-specific field, but it says nothing about whether results are scoped to the active session, whether a server connection is required, or how large the listing may be.
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 a single compact sentence with no filler, and the resource is front-loaded. The colon-list construction is slightly terse and reads like a return-field summary rather than a purpose statement, but nothing is wasted.
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 no output schema, the description usefully enumerates returned fields, which is the main thing an agent needs. However, for a tool with an unexplained connection parameter and multiple adjacent caslib/library tools, it leaves gaps about invocation context and scope.
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?
The schema has one parameter, connection, with 0% description coverage, and the description never explains what it means or what happens when it is omitted (apparently the current/default connection). The phrase 'on the CAS server' hints at the concept but adds no usable meaning for the parameter.
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 identifies the resource (caslibs) and the server (CAS) and enumerates the attributes returned (type, description, path, SingleStore database), so an agent understands it is a caslib metadata listing. There is no explicit verb and no differentiation from closely related siblings such as cas_caslib_code or sas_libraries, so it stops short of a 5.
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?
There is no when-to-use guidance, no statement of prerequisites, and no mention of the alternative tools an agent might pick instead (cas_caslib_code for a caslib's code, sas_libraries for SAS 9 libraries, cas_tables for tables within a caslib). Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.