Skip to main content
Glama
martoc

MCP Spark Documentation Server

by martoc
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

License: MIT Python 3.12 MCP

MCP Spark Documentation Server

An MCP (Model Context Protocol) server that provides search and retrieval tools for Apache Spark documentation. This server enables AI assistants like Claude to search and read Spark documentation directly.

Features

  • Full-text search using SQLite FTS5 with BM25 ranking and Porter stemming

  • Section filtering to narrow search results by documentation category

  • Sparse checkout for efficient cloning of only the docs directory from apache/spark

  • Docker support for portable deployment across projects

  • STDIO transport for seamless MCP client integration

Related MCP server: Gemini Docs MCP Server

Quick Start

Using Docker (Recommended)

# Build the Docker image (includes pre-indexed documentation)
make docker-build

# Test the server
make docker-run

Using uv (Local Development)

# Initialise the environment
make init

# Build the documentation index
make index

# Run the server
make run

Configuration

Claude Code / Claude Desktop

Add to your .mcp.json or global settings:

{
  "mcpServers": {
    "spark-documentation": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "martoc/mcp-spark-documentation:latest"]
    }
  }
}

For a locally built Docker image:

{
  "mcpServers": {
    "spark-documentation": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "mcp-spark-documentation"]
    }
  }
}

For local development without Docker:

{
  "mcpServers": {
    "spark-documentation": {
      "command": "uv",
      "args": ["run", "mcp-spark-documentation"],
      "cwd": "/path/to/mcp-spark-documentation"
    }
  }
}

MCP Tools

Tool

Description

search_documentation

Search Spark documentation by keyword query with optional section filtering

read_documentation

Retrieve the full content of a specific documentation page

search_documentation

Search Apache Spark documentation using full-text search with stemming support.

Parameter

Type

Required

Default

Description

query

string

Yes

-

Search terms (supports stemming)

section

string

No

None

Filter by section (e.g., sql-ref, streaming, mllib)

limit

integer

No

10

Maximum results (1-50)

Common Sections: sql-ref, api, streaming, mllib, graphx, structured-streaming, configuration, tuning

read_documentation

Retrieve the full content of a documentation page.

Parameter

Type

Required

Description

path

string

Yes

Relative path to document (from search results)

CLI Commands

# Build/rebuild the documentation index
uv run spark-docs-index index
uv run spark-docs-index index --rebuild
uv run spark-docs-index index --branch master

# Show index statistics
uv run spark-docs-index stats

Development

make init       # Initialise development environment
make build      # Run full build (lint, typecheck, test)
make test       # Run tests with coverage
make format     # Format code
make lint       # Run linter
make typecheck  # Run type checker

Documentation

Licence

This project is licensed under the MIT Licence - see the LICENSE file for details.

Available Tools

2 tools
read_documentationA

Read the full content of a specific Spark documentation page.

Args: path: The relative path to the documentation file (e.g., 'sql-ref/sql-syntax.md' or 'api/python/index.md'). This path is returned in search results.

Returns: The full markdown content of the documentation page, or an error message if the page is not found.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that the tool reads full content and returns markdown or an error, implying a read-only operation. Adding an explicit read-only hint would improve transparency.

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 Args and Returns sections, but it is slightly verbose for a simple one-parameter tool. Each sentence adds value, so it earns a high score.

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 that an output schema exists, the description need not detail return structure. It covers the single parameter well and mentions the return type ('full markdown content'). Mentioning the sibling tool explicitly would improve completeness.

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?

Although the input schema has 0% description coverage, the description provides excellent context for the 'path' parameter with examples ('sql-ref/sql-syntax.md') and explains its origin from search results, fully compensating for the missing schema descriptions.

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 'Read' and the resource 'specific Spark documentation page', and distinguishes itself from its sibling 'search_documentation' by mentioning that the path comes from search results.

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 that the path should be a relative path to a documentation file and that it is returned by search results, providing clear context for when to use. However, it does not explicitly state when not to use or mention alternatives beyond the implied search tool.

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

search_documentationA

Search Apache Spark documentation by keyword query.

Args: query: Search terms to find in the documentation. Supports full-text search with stemming (e.g., "stream" matches "streaming", "streams"). section: Optional section to filter results. Common sections include: 'sql-ref', 'api', 'streaming', 'mllib', 'graphx', 'structured-streaming', etc. limit: Maximum number of results to return (default: 10, max: 50).

Returns: JSON-formatted search results with title, URL, snippet, and relevance score.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sectionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/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 discloses full-text search with stemming, optional section filtering, default and maximum limit, and the return format with fields. This provides sufficient behavioral context for an agent.

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 very concise: a single line for purpose, then parameter descriptions in a clear format. No wasted sentences; every line adds value. The structure is easy to parse.

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 the complexity (3 parameters, output schema present), the description covers all necessary aspects: input parameters with examples, output format, and behavioral details like stemming and default limits. It is complete for an agent to use 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?

The schema has 0% description coverage, so the description must compensate. It adds meaningful details: for 'query' it explains stemming, for 'section' it lists common values, for 'limit' it gives default and maximum. This fully compensates for missing schema descriptions.

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 Apache Spark documentation by keyword query. It specifies the resource (Apache Spark documentation) and verb (search), and the sibling tool 'read_documentation' suggests a complementary action, distinguishing this tool as the search interface.

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 explains the tool's purpose but does not explicitly state when to use this tool versus alternatives like 'read_documentation'. It implies usage for searching documentation, but lacks guidance on when not to use it or when to prefer the sibling tool.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: search_documentation finds relevant pages based on a query, while read_documentation retrieves the content of a specific page. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern: 'read_documentation' and 'search_documentation'. The naming is predictable and clear.

Tool Count4/5

With only two tools, the server is minimal but functional for its purpose of documentation access. While it could benefit from additional tools like listing sections or getting metadata, the current count is reasonable for a focused documentation server.

Completeness4/5

The server covers the essential operations for documentation browsing: searching and reading. However, it lacks features like listing available sections or navigating the documentation structure, which are minor but notable gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/martoc/mcp-spark-documentation'

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