mcp-server

List data specs or jobs

list_data

Read-onlyIdempotent

List either the data specs (parsing + mapping rule sets, resource: "specs") or the data processing jobs (executions of a spec, resource: "jobs") defined in a workspace. Each spec includes its specId and current status — poll a specific one with get_status. Both resources are paginated (default 25/page, max 100, newest first); pass the returned nextCursor to fetch more.

A spec row also carries its stored input set — sourceType, sampleFileName, formatFileName, targetOption/targetTables/targetSchemaFileName, sourceTables, merge and additionalPrompt — which is exactly what AI code generation re-reads on every re-analysis. Read that set here BEFORE calling update_data_spec: an update regenerates the parser and mapping from all of it, not just from the fields you change, so it is the only way to tell which components are about to be reused as-is.

This is NOT a table listing — specs describe configured pipelines (parsing/mapping rules), not the live set of Iceberg tables in the workspace. Multiple specs can target the same table (e.g. one spec creates it, another merges more data into it), and specs can be deleted or fail without the underlying table being dropped. For "what tables exist in my workspace" or any question about actual current data, use submit_query with SHOW TABLES instead of inferring an answer from specs.

Input Schema

Name	Required	Description
`cursor`	No	Opaque `nextCursor` from a prior page (omit for the first page).
`pageSize`	No	Records per page (default 25).
`resource`	Yes	Which kind of resource to list
`workspaceId`	No	Workspace to act on. Defaults to your only workspace if you have exactly one.

Output Schema

Name	Required	Description
`jobs`	No	Present when resource is "jobs"
`count`	Yes	Number of items in this page, not the workspace total
`specs`	No	Present when resource is "specs"
`pageSize`	No
`nextCursor`	No	Opaque cursor for the next page; null when exhausted

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 10, 2026

addedOutput schema / properties / specs / items / properties / additionalPrompt

Added value: +{
+  "description": "Stored AI guidance, reused verbatim on every re-analysis",
+  "type": "string"
+}

addedOutput schema / properties / specs / items / properties / formatFileName

Added value: +{
+  "description": "sourceType \"file\" only: the stored format spec, if one was provided",
+  "type": "string"
+}

addedOutput schema / properties / specs / items / properties / lastRunTs
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

addedOutput schema / properties / specs / items / properties / sampleFileName

Added value: +{
+  "description": "sourceType \"file\" only: the stored sample the generated parser was built from",
+  "type": "string"
+}

addedOutput schema / properties / specs / items / properties / sourceTables

Added value: +{
+  "description": "sourceType \"tables\"/\"compaction\" only",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / specs / items / properties / sourceType

Added value: +{
+  "description": "\"file\" | \"tables\" | \"compaction\"",
+  "type": "string"
+}

First observedAug 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is freed to add contract detail the annotations cannot: pagination defaults (25, max 100), newest-first ordering, and the nextCursor continuation mechanism. It also discloses a non-obvious hazard — that update_data_spec regenerates the parser and mapping from the full stored input set, not just changed fields — which materially affects how an agent sequences calls.

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?

Purpose and both resource options are front-loaded in the first sentence, and the disambiguation paragraph is genuinely load-bearing rather than filler. The update_data_spec passage is somewhat lengthy, but it prevents a costly misuse, so it earns its space.

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 an output schema present, return values need not be documented, and the description instead covers the decision boundary (specs vs. tables vs. jobs), pagination behavior, and call sequencing. Nothing an agent needs to invoke this correctly 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 the baseline is 3, but the description adds real meaning: it defines what 'specs' and 'jobs' each represent, and explains cursor/page semantics beyond the schema's terse wording. The workspaceId default behavior is left to the schema.

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 (list) and resource pair (data specs vs. data processing jobs), and even names the internal resource strings 'specs' and 'jobs' that map to the enum. It explicitly distinguishes the tool from siblings get_status and submit_query, so an agent can route without opening the schema.

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 gives explicit when-to-use and when-not-to-use guidance: poll a single item with get_status, read the stored input set BEFORE update_data_spec, and use submit_query with SHOW TABLES for questions about actual tables. The negative case ('This is NOT a table listing') directly prevents a plausible misselection.

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

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?