Skip to main content
Glama

execute_pyspark_job

Run declarative PySpark transformations on DuckDB datasets for heavy aggregations, using a fixed set of validated operations like filter, select, groupBy, and orderBy.

Instructions

Run a declarative PySpark transformation pipeline against a DuckDB dataset -- for heavier aggregations/transformations than run_sql_query is meant for. NOT arbitrary code execution: each step must be one of a fixed set of operations, validated before running.

Supported operations (each a dict with an "op" key): {"op": "filter", "condition": ""} e.g. {"op": "filter", "condition": "revenue > 100"} {"op": "select", "columns": ["a", "b"]} {"op": "withColumn", "name": "new_col", "expression": ""} e.g. {"op": "withColumn", "name": "margin", "expression": "revenue - cost"} {"op": "groupBy_agg", "group_by": ["a"], "aggregations": {"b": "sum"}} aggregations map column -> function; functions: sum, avg, mean, count, min, max, stddev, variance {"op": "orderBy", "columns": ["a"], "ascending": true} {"op": "distinct"} {"op": "limit", "n": 100}

Steps run in the order given. A final row cap is always applied to the output regardless of what the pipeline itself requests.

Args: source_dataset: Exact table/view name, as returned by list_datasets. operations: Ordered list of pipeline steps (see above). row_limit: Desired max rows returned (capped at the server's max_row_limit).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
row_limitNo
operationsYes
source_datasetYes
Behavior5/5

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

With no annotations, the description carries the full burden and does so exceptionally. It discloses that steps run in order, an unconditional final row cap is applied, and row_limit is capped at server's max_row_limit. It also emphasizes the fixed op set and validation step, which prevents misuse.

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 every sentence earns its place. It is front-loaded with the core purpose and limitation, then systematically covers operations, ordering, row cap, and arguments. No fluff or redundancy; the structure is logical and scannable.

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 complex tool with no output schema, the description is remarkably complete. It details the full set of supported operations with examples, explains ordering and row cap behavior, and ties arguments to other tools (list_datasets). An agent has everything needed to invoke it correctly.

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?

Schema coverage is 0%, but the description compensates fully. Each parameter is explained: source_dataset is an exact table name from list_datasets, operations is an ordered list with a detailed enumeration of supported ops and examples, and row_limit is a desired max rows capped by server. This adds meaning far beyond the bare 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 clearly states a specific verb (run), resource (declarative PySpark transformation pipeline against DuckDB dataset), and scope (heavier aggregations/transformations). It explicitly distinguishes itself from run_sql_query, and the phrase 'NOT arbitrary code execution' further clarifies its purpose.

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 gives explicit guidance on when to use it: 'for heavier aggregations/transformations than run_sql_query is meant for'. It also explains constraints: each step must be one of a fixed set of operations, validated before running. This frames appropriate usage and sets expectations.

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/MostafaAI10/OmniData-MCP'

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