PySpark MCP Server

by AnnasMazhar

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.0.4
Disambiguation5/5
Each tool has a clearly distinct purpose, from context storage to conversion, analysis, optimization, Glue job generation, schema management, S3 optimization, data processing, refactoring, search, batch monitoring, S3 source analysis, and analytics. Sub-modes further clarify without overlap.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern (e.g., glue_job, batch_status). The naming is predictable and readable, with verbs and nouns clearly indicating function.
Tool Count5/5
With 14 tools, the server is well-scoped for its purpose. Each tool covers a necessary aspect of the PySpark conversion and Glue workflow, and the count is neither too sparse nor excessive.
Completeness5/5
The tool set covers the full lifecycle: context management, conversion, analysis, optimization, code review, Glue job generation, schema handling, S3 optimization, data processing, refactoring, search, batch monitoring, and analytics. No obvious gaps for the stated domain.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on May 9, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits such as side effects, data freshness, or access requirements. It only describes modes and parameters, lacking any explanation of behavior (e.g., whether it is read-only, or if it aggregates data over time).
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 description is structured with clear sections and bullet points, making it easy to scan. It is reasonably concise, though some repetition could be eliminated. Front-loaded with purpose, then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, no enums, and an output schema present (which covers return values), the description still fails to explain parameter semantics and lacks guidance on when to choose each mode. It feels incomplete for a multi-mode analytics tool.
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 0% schema description coverage, the description must explain parameters. It lists parameters for each mode (e.g., optimization_type, limit) but does not define what optimization_type accepts (e.g., string values), its default, or the effect of limit. This is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides analytics on optimization effectiveness and usage patterns, and it distinguishes two modes (optimization and usage), which helps differentiate it from sibling tools like 'optimize' or 'review' that focus on performing actions.
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 implicitly gives usage guidance by specifying which parameters go with which mode, but it does not explicitly state when to use this tool versus alternatives like 'optimize' or 'search', nor does it provide any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains that the tool analyzes code but does not state whether it is read-only, destructive, or requires authentication. No side effects or limitations are mentioned.
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 description is well-structured with a clear opening line and bullet-pointed modes. It is front-loaded with the general purpose. Some redundancy exists (repeating 'Parameters:' for each mode), but overall it is reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-mode, 11 parameters) and lack of annotations, the description is incomplete. It does not describe return values despite an output schema existing, and it omits details for several parameters such as 'workspace_path' and 'include_project_structure'.
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. While parameters are grouped by mode, their meanings are not explained beyond names (e.g., 'sql_content', 'selected_text'). The description adds little value for understanding parameter usage or constraints.
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 tool analyzes SQL or PySpark code for context, data flow, or optimization opportunities. It further defines four distinct modes (sql_context, data_flow, codebase, workspace), each with a specific purpose, which distinguishes it from sibling tools like 'context' or 'optimize' that might be more focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists modes and associated parameters but provides no guidance on when to use this tool versus alternatives like sibling tools 'context', 'optimize', or 'review'. There is no mention of prerequisites, exclusions, or decision criteria for choosing a mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It states the tool converts SQL to PySpark but does not disclose side effects (e.g., read-only or destructive nature), permissions, or output details. The presence of an output schema mitigates some missing return info, but the description omits important behavioral traits like input validation or error handling.
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 description is concise and well-structured with bullet-pointed modes. It front-loads the main purpose and uses a clear hierarchical format. Every sentence adds value, though some parameter descriptions could be expanded without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 modes, 12 parameters) and lack of annotations, the description is incomplete. It explains what each mode does but fails to cover parameter constraints, expected output, error conditions, or pre-requisites. The output schema exists but the description doesn't reference it, leaving gaps for robust tool 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 description coverage is 0%, so the description must compensate. It lists parameters per mode but adds minimal meaning beyond their names (e.g., 'table_info' and 'optimization_level' have no explanation of their purpose or allowed values). It does indicate which parameters are required in each mode, which is useful, but overall semantic depth is insufficient for a 12-parameter tool.
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 tool's purpose: 'Convert SQL to PySpark code or process SQL files in batch.' The verb 'convert' and resource 'SQL to PySpark' are specific. It distinguishes from sibling tools (none of which perform conversion) and outlines four distinct modes, making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not address when not to use it, nor does it compare with sibling tools. The modes are described, but no criteria are given to help an agent decide which mode to select, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes what each mode does but fails to mention side effects, auth requirements, read-only status, or return value details. The tool's behavioral traits beyond function are vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with mode headings and bullet-like parameter lists, making it scannable. However, it is somewhat verbose and could be more concise by shortening parameter lists or merging redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (16 params, multiple modes) and lack of annotations, the description should be comprehensive. It covers mode purposes and parameter names but lacks parameter details, behavioral context, and output explanation. An output schema exists but is not leveraged in the description.
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%, requiring the description to compensate. It lists parameters per mode but does not explain their meaning (e.g., dialect, sql_content). For 16 parameters, this is insufficient; only names and required status are given.
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 tool refactors PySpark code and generates pipeline structures, with three distinct modes (patterns, utilities, pipeline) each explained. This specific verb+resource and mode differentiation distinguish it from sibling tools like analyze or convert.
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 context for when to use each mode, e.g., 'Refactor code by replacing duplicate patterns' for patterns mode. However, it does not explicitly state when not to use the tool or suggest alternatives, lacking exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It uses the ambiguous verb 'generate' without clarifying whether it actually creates AWS resources, requires permissions, or has side effects. There is no mention of what happens upon invocation or the nature of the generated artifact.
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 description is well-organized with a clear opening line stating the tool's purpose, followed by mode-specific bullet points listing parameters. It efficiently packs a large amount of information without redundancy or fluff, though it could be slightly shorter.
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 three modes and their parameters adequately. However, it lacks explanation of what the tool returns (output schema exists but not described) and behavioral implications like whether the jobs are actually deployed or just configuration generated. Some operational context is missing given the tool's complexity (14 params, 3 modes).
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 input schema has 0% description coverage, but the description groups parameters by mode and indicates which are required for each mode (e.g., 'source_database (required)'), adding crucial context beyond the schema structure. Default values like 'cdc_column=last_modified' are also mentioned, helping the agent select correct 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 first sentence clearly states 'Generate AWS Glue data processing jobs — incremental, CDC, bookmarks', specifying the verb (generate) and resource (Glue data processing jobs) and listing three distinct modes. This distinguishes it from sibling tools like glue_job and glue_schema which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus sibling tools (e.g., glue_job) nor when to choose between the three modes. It only lists parameters per mode without comparative context or usage scenarios. The agent must infer usage from mode names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It describes modes and parameters but does not mention side effects, read-only nature, required permissions, failure behavior, or any automation context. The tool likely performs read-only analysis, but this is not explicitly stated.
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 concise and well-structured with a header and bullet points for each mode. Every sentence adds value, no fluff. It front-loads the main purpose and quickly provides mode-specific detail.
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?
Given the tool's complexity (two modes, 5 parameters, output schema exists), the description is partially complete. It covers mode purposes and required parameters but omits output format, permissions, behavioral traits, or any caveats. Adequate but with notable gaps for a production 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?
With 0% schema description coverage, the description adds meaning by listing mode-specific parameters (s3_path, include_schema_inference, table_path, analyze_history) and their required status. However, the 'mode' parameter is not explained, and boolean parameters lack contextual detail beyond their names.
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 tool analyzes S3 data sources and Delta tables, breaking into two distinct modes with specific verbs and resources. It differentiates from siblings by focusing on S3/Delta analysis, which is not covered by other sibling tools like 'context', 'convert', or 'optimize'.
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 use cases (analyze S3 structure or Delta tables) but does not provide explicit guidance on when to choose this tool over alternatives like 'analyze' or 'review'. No exclusions or context for 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes each mode's purpose (e.g., 'Detect schema from sample data and generate table definition') but fails to clarify side effects such as whether the tool actually creates resources in AWS, requires specific permissions, or has rate limits. This ambiguity is a significant gap for a tool that likely interacts with cloud services.
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 description is well-structured with markdown headers and bullet points, making it easy to parse. It front-loads the overall purpose and then details each mode efficiently. No unnecessary sentences are present, though the mode-specific lists could be more compact.
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?
Given the tool's complexity (14 parameters, 3 modes) and lack of annotations, the description is moderately complete. It covers the modes and their parameters but omits behavioral details (e.g., side effects, return values) and does not explain how the modes interrelate. The existence of an output schema reduces the need to describe return values, but other gaps remain.
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 input schema has 0% description coverage, so the description must compensate. It groups parameters by mode and indicates which are required per mode, adding meaningful context. However, it labels some parameters as 'required' that are not in the schema's required list (only 'mode' is required), which could cause confusion. Overall, it adds substantial value 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 explicitly states the tool manages Glue Data Catalog schemas with three distinct modes: detect, evolve, and catalog. Each mode has a specific verb and resource, making it clear what the tool does. Although sibling tools are not explicitly differentiated, the name and description set it apart as a schema-focused utility.
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 provides some usage context by listing modes with their parameters, but it does not offer guidance on when to use this tool versus alternatives like glue_job or glue_data. There is no mention of when not to use it or comparison with sibling tools, leaving the agent with implicit guidance at best.
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?
No annotations are provided, so the description must convey behavioral traits. It describes the tool as generating configurations and templates, implying it is non-destructive. However, it does not explicitly state that it does not modify AWS resources or require specific permissions, leaving transparency gaps.
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 well-organized with headers and bullet points, making it easy to scan. It efficiently communicates modes and associated parameters without unnecessary verbosity.
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?
Given the tool's complexity (23 parameters, 4 modes), the description provides a high-level overview but lacks details on parameter constraints, output format, or error handling. The existence of an output schema mitigates some missing return value info, but parameter semantics remain underdescribed.
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?
The input schema has 0% coverage for parameter descriptions. The description lists parameter names per mode but does not explain their meanings, valid values, or constraints beyond defaults. This is insufficient for a tool with 23 parameters, as agents need semantic guidance to select correct values.
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 tool's purpose: 'Generate and manage AWS Glue job configurations and templates.' It then lists four distinct modes (template, dynamic_frame, properties, sql_conversion) with specific use cases, effectively distinguishing the tool from siblings.
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 guidelines on when to use each mode by listing the parameters specific to each. While it does not explicitly contrast with sibling tools, it implies appropriate usage through mode descriptions. No explicit 'when not to use' guidance is given.
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?
No annotations exist, so the description must carry the full burden. It describes the modes but does not explicitly state side effects, permissions, or that it is read-only. Given the output schema exists, some behavioral context is implied but not explicit.
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 concise and well-structured with clear headers and backticks for modes. Every sentence adds value, and the main purpose is front-loaded.
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?
Given the output schema exists, return values need not be explained. The description covers the three modes and parameter dependencies. It could mention limitations or prerequisites, but overall it is complete for the tool's complexity.
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 description coverage is 0%, so the description compensates by explaining the role of each parameter per mode (e.g., 'code' required in code mode, 'code_samples' in patterns/duplicates). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reviews PySpark code for issues, patterns, and refactoring opportunities. It differentiates three modes, but does not explicitly distinguish it from the sibling tool 'analyze', which could be seen as similar.
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 explicit modes and the parameters required for each, guiding when to use each mode. However, it does not specify when not to use this tool or mention alternative sibling tools.
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?
Describes main behaviors (store, get, assist) and their parameters. No annotations provided, so description carries full burden. Missing details on persistence, side effects, or errors; partially compensates but could be more transparent.
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?
Concise and well-structured with markdown headers and bullet points. Each sentence serves a purpose; no fluff. Efficiently presents three modes and their parameters.
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?
Covers core functionality and parameter usage per mode. Lacks description of return values (though output schema exists) and error behavior. With moderate complexity, more detail on outputs would improve completeness.
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 adds essential meaning by mapping parameters (conversion_id, context_data, sql_query, selected_text) to specific modes. Could include more detail on expected formats (e.g., context_data as JSON).
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?
Clearly states verb and resource: 'Store, retrieve, and work with SQL/PySpark conversion context.' Lists three distinct modes with specific purposes, differentiating it from sibling tools like convert and analyze.
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?
Provides explicit guidance on when to use each mode (e.g., store for additional context, get for retrieval, assist for real-time SQL help). Lacks explicit when-not-to-use or alternative tool references, but usage context is clear.
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 no annotations, the description carries full burden. It discloses each mode's behavior: analyze is read-only exploratory, optimize generates a strategy, consolidate generates a Glue job. However, it does not explicitly state that the tool does not execute actions or require specific AWS permissions.
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 description is well-structured with a concise overall statement followed by a clear breakdown of three modes, each with a sentence and parameter list. It could be slightly more concise but is easy to scan and understand.
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?
Given 15 parameters and 3 modes with no annotations, the description provides a good overview of tool behavior and mode-specific parameter sets. It does not describe return values, but an output schema is present. The description could be more complete by clarifying optional parameters and output types, but it is largely adequate.
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 add parameter meaning. It lists parameters per mode and marks required ones, but does not explain parameter details beyond their names (e.g., no allowed values for data_format or compression_type). This adds some value but is insufficient for full clarity.
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 tool's purpose: 'Analyze and optimize S3 data layouts for AWS Glue.' It lists three distinct modes (analyze, optimize, consolidate) with specific verb+resource combinations, distinguishing it from sibling tools like glue_job or glue_schema.
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 context for when to use each mode (analyze for analysis, optimize for strategy, consolidate for job generation) but does not explicitly state when not to use this tool or mention alternatives among siblings.
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?
With no annotations, the description carries the full burden. It discloses that the tool applies optimizations, recommends join strategies, and suggests partitioning, but lacks detail on side effects (e.g., whether code is modified or just suggestions), permissions, or output format. The output schema may cover return values, but behavioral traits remain incomplete.
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 description is well-structured with clear mode headings and parameter lists. It is mostly concise but repeats 'Parameters:' for each mode, which is slightly redundant. Still, it is easy to scan and front-loads the key functionality.
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?
Given the complexity (multiple modes, 5 parameters) and the presence of an output schema, the description covers the essential functionality and parameter usage adequately. It could be enhanced by mentioning prerequisites or limitations, but overall it is sufficient for an agent to decide when to use this tool.
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 description coverage is 0%, so the description must compensate. It does so by associating each mode with its specific parameters (e.g., 'code' mode uses 'code' and 'optimization_level'), adding meaning beyond the generic schema. However, it does not describe value constraints (e.g., allowed values for 'optimization_level').
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 tool optimizes PySpark code and recommends performance improvements, with distinct modes (code, joins, partitioning, comprehensive) that differentiate it from siblings like 'analyze' or 'refactor'. Each mode has a specific verb and resource.
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 for each mode, including which parameters are required. However, it does not explicitly state when not to use this tool or compare it to sibling tools like 'analyze' or 'review', leaving some ambiguity.
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?
With no annotations provided, the description carries the full burden. It discloses that 'cancel' is destructive but lacks details on prerequisites, reversibility, or permission requirements. The read-only modes are clear, but overall transparency is adequate but not thorough.
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 efficiently structured with a header and bullet lists. Each mode is described succinctly in a sentence. No redundant or wasted wording.
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 all modes and parameters; the presence of an output schema means return values are handled externally. Missing details about error handling or prerequisites, but overall complete for a multi-mode tool with good parameter mapping.
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?
Despite 0% schema description coverage, the description adds significant meaning by mapping parameters to specific modes (e.g., job_id for status/cancel, limit+status for recent). It also provides default values. This compensates well for the lack of schema documentation.
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 'Monitor and manage batch processing jobs' and lists distinct modes (status, cancel, active, recent) with specific purposes. This distinguishes it from sibling tools which likely focus on other domains.
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 context for when to use each mode (e.g., 'Get the status of a specific batch job' for status mode). However, it does not explicitly explain when not to use this tool vs. alternatives, though the distinct focus on batch jobs makes it unambiguous.
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?
No annotations are provided, so the description bears full burden. It describes behavioral traits such as returning recent history when query is empty, but does not disclose whether the tool is read-only, requires authentication, or has rate limits. The description is somewhat informative but leaves gaps.
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 well-structured with clear mode sections, front-loads the purpose, and uses bullet points for readability. Every sentence adds necessary information without redundancy.
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?
Given 6 parameters, no annotations, and an existing output schema, the description covers all parameters via modes and provides behavioral context. It does not explain return values (handled by output schema), so it is fairly complete for a search tool.
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 description coverage is 0%, so the description must compensate. It explains each mode's relevant parameters (query, limit, min_usage_count, conversion_id, key) and their behavior (e.g., empty query returns history). This adds meaning beyond the raw schema, though not all parameters are equally detailed.
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 it searches stored conversions, code patterns, and context data, and distinguishes three modes with specific purposes. This differentiates it from sibling tools like 'context' (which likely retrieves context directly) and 'convert' (which performs conversions).
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 explains when to use each mode (conversions, patterns, context) and provides parameter hints (e.g., empty query returns recent history for conversions). However, it lacks explicit guidance on when not to use this tool versus alternative tools like 'context' or 'analyze'.
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:

[![pyspark_mcp MCP server](https://glama.ai/mcp/servers/AnnasMazhar/pyspark_mcp/badges/card.svg)](https://glama.ai/mcp/servers/AnnasMazhar/pyspark_mcp)

Score Badge

Copy to your README.md:

[![pyspark_mcp MCP server](https://glama.ai/mcp/servers/AnnasMazhar/pyspark_mcp/badges/score.svg)](https://glama.ai/mcp/servers/AnnasMazhar/pyspark_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/AnnasMazhar/pyspark_mcp'

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