How do I use chapel-support?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@chapel-support list the available Chapel primers" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

chapel-support

by DanilaFe

Overview Schema Related Servers Score Discussions

Python

Local

Chapel Support for MCP

A Model-Context-Protocol (MCP) server for the Chapel programming language, providing tools for working with Chapel code, accessing primers and examples, and integrating Chapel functionality with AI assistants and other tools.

What is Chapel?

Chapel is an open-source parallel programming language designed for productive parallel computing at scale. It aims to improve the programmability of parallel computers while matching or beating the performance and portability of current programming models like MPI, OpenMP, and CUDA.

Related MCP server: MCP Server for VS Code

Features

This MCP server provides the following Chapel support functionality:

Chapel Primer Access: Browse and access Chapel's educational primer examples
Code Compilation: Compile Chapel code directly through the API
Linting: Check Chapel code for style and best practices using chplcheck and apply automatic fixes
Smart CHPL_HOME Detection: Automatically locate Chapel's installation directory

Prerequisites

Python 3.13 or higher
Chapel programming language installed (see Chapel installation guide)
(Optional) chplcheck for linting functionality

Installation

Clone this repository:

git clone <repository-url>
cd chapel-support

Create and activate a virtual environment with UV:

uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

Synchronize the environment with project dependencies:
```
uv sync
```

Configuration

The MCP server needs to know the location of your Chapel installation (CHPL_HOME). It will try to find it in this order:

From the CHPL_HOME environment variable
From a .env file in the project root
By running chpl --print-chpl-home if the Chapel compiler is in your PATH

To use a .env file, create one in the project root with:

CHPL_HOME=/path/to/your/chapel/installation

See .env.example for a template.

Usage

Running the MCP Server

uv run chapel-support.py

This will start the MCP server in stdio transport mode using your virtual environment.

Integrating with AI Assistants or Tools

To use this MCP server with AI assistants or other tools, configure them to connect to this server. For example, in a client configuration file:

{
  "context_servers": {
    "chapel-support": {
      "command": {
        "path": "uv",
        "args": [
          "run",
          "--directory",
          "/path/to/chapel-support",
          "chapel-support.py"
        ],
        "env": {}
      },
      "settings": {}
    }
  }
}

Note: Adjust the directory path to the location of your chapel-support installation.

Available Tools

`list_primers()`

Gets the list of available Chapel primers.

Returns: A list of paths to primer files relative to CHPL_HOME.

`get_primer(path: str)`

Retrieves the content of a specific Chapel primer.

Parameters:

path: The path to the primer, as returned by list_primers()

Returns: The content of the primer as a string.

`compile_program(program_text: str, program_name: str = "program.chpl")`

Compiles a Chapel program.

Parameters:

program_text: The Chapel code to compile
program_name: Optional name for the program file (default: "program.chpl")

Returns: A tuple containing:

Success status (boolean)
Compiler output/errors (string)

`list_chapel_lint_rules()`

Lists all available Chapel linting rules from chplcheck.

Returns: A list of dictionaries with rule information:

name: Rule name
description: Rule description
is_default: Whether the rule is enabled by default

`lint_chapel_code(program_text: str, program_name: str = "program.chpl", fix: bool = False, custom_rules: Optional[List[str]] = None)`

Lints Chapel code and optionally applies fixes.

Parameters:

program_text: The Chapel code to lint
program_name: Optional name for the program file (default: "program.chpl")
fix: Whether to apply automatic fixes (default: False)
custom_rules: List of specific rules to enable (default: None, uses default rules)

Returns: A dictionary containing:

warnings: String containing linting warnings
fixed_code: The fixed code if fix=True
error: Error message if something went wrong
stats: Statistics about the linting process

Contributing

Contributions are welcome! Please feel free to submit pull requests or open issues.

Available Tools

5 tools

compile_programD

ParametersJSON Schema

Name	Required	Description	Default
`program_text`	Yes
`program_name`	No		program.chpl

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

get_primerA

Gets a primer at the given path. The path must be an element of the list returned by list_primers.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

A3.7/5.0

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 disclosing behavior. It indicates a read operation ('gets'), but omits details like error handling, required permissions, or whether the operation is safe. Minimal behavioral context beyond the basic action.

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 extremely concise: two sentences with no redundant wording. The key verb is front-loaded ('Gets'), and the constraint is stated immediately. Every sentence serves a clear purpose.

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 tool is simple (get a primer by path), and the description covers purpose and a necessary constraint. However, it does not explain what a primer is, the output format, or error scenarios. For a basic getter, it is adequate but not thorough.

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?

The input schema lacks a description (0% coverage). The description adds value by explaining that the path must be an element of list_primers, providing a domain constraint. However, it does not specify path format, examples, or validation rules, leaving some ambiguity.

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 'Gets a primer at the given path,' which specifies a distinct action (getting) on a resource (primer). It distinguishes itself from sibling tools like list_primers (which lists) and compile_program (which compiles).

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 a crucial precondition: the path must come from list_primers. This guides users to first list primers and then use this tool. However, it does not explicitly state when not to use it or mention any alternatives for fetching primers.

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

lint_chapel_codeA

Lints Chapel code using chplcheck and returns warnings and fixed code.

Args: program_text: The Chapel code to lint program_name: The name of the program file fix: Whether to apply automatic fixes to the code custom_rules: List of specific rules to enable (if None, uses default rules)

Returns: A dictionary containing linting results, which may include: - 'warnings': String containing linting warnings - 'fixed_code': The fixed code if fix=True - 'error': Error message if something went wrong - 'stats': Statistics about the linting process

ParametersJSON Schema

Name	Required	Default
`program_text`	Yes
`program_name`	No	program.chpl
`fix`	No
`custom_rules`	No

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 the full burden. It discloses that the tool uses chplcheck, returns warnings and fixed code, and provides a dictionary with keys like warnings, fixed_code, error, and stats. It does not mention destructive behavior, which is appropriate for linting, but could be more explicit about side effects or safety.

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. It begins with a one-line purpose, followed by an 'Args:' list and a 'Returns:' section. Every sentence adds value, and the format is front-loaded with the most important information.

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 lack of output schema, the description includes a comprehensive list of return values (warnings, fixed_code, error, stats). All four parameters are described, with one required. The description provides enough detail for an agent to understand the tool's inputs and outputs completely.

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 description coverage is 0%, so the description must compensate. It does so excellently by explaining each parameter: 'program_text' is the Chapel code to lint, 'program_name' is the name of the program file, 'fix' indicates whether to apply automatic fixes, and 'custom_rules' is a list of specific rules. This adds crucial meaning beyond the schema's types and defaults.

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 lints Chapel code using chplcheck and returns warnings and fixed code. The verb 'Lints' and resource 'Chapel code' are specific. It distinguishes from sibling tools like 'compile_program', 'get_primer', 'list_chapel_lint_rules', and 'list_primers' by focusing on linting.

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 does not explicitly state when to use this tool versus alternatives. It provides parameter details but lacks guidance on context, such as when to lint versus compile. The sibling tools are mentioned but not compared, leaving the agent to infer usage.

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

list_chapel_lint_rulesA

Lists all available Chapel linting rules from chplcheck.

Returns: A list of dictionaries, each containing: - 'name': The rule name - 'description': The rule description - 'is_default': Whether the rule is enabled by default

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so the description fully bears the burden. It explicitly details the return format (list of dicts with 'name', 'description', 'is_default'), which is beyond simple output types. No side effects or contradictions.

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 two sentences: first states purpose, second details return fields. Every sentence earns its place, no wasted words, front-loaded with key purpose.

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 no parameters and no output schema, the description fully covers what the tool does and what it returns. It is complete for a simple listing 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?

The tool has zero parameters, so schema coverage is 100%. The baseline for 0 params is 4, and the description does not need to add parameter info.

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 'Lists all available Chapel linting rules from chplcheck,' specifying the verb, resource, and source. This distinguishes it from sibling tools like 'lint_chapel_code' (applies linting) and 'compile_program' (compilation).

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 lacks explicit guidance on when to use this tool versus alternatives. The purpose is implied but no 'when-not-to-use' or comparisons to siblings like 'lint_chapel_code' are provided.

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

list_primersB

Gets the list of available Chapel primers.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It fails to mention return format, pagination, or side effects. The minimal description does not add transparency beyond the bare purpose.

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 a single concise sentence with no wasted words. However, it is slightly under-specified for the overall context.

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 no parameters, no output schema, and no annotations, the description is minimal. It does not explain what a primer is or the structure of the list, but for a simple listing tool, it meets minimum viability.

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?

Tool has zero parameters, so schema description coverage is 100%. Baseline score of 3 is appropriate since the description adds no additional parameter meaning beyond 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 clearly states 'Gets the list of available Chapel primers', which is a specific verb and resource. It distinguishes from sibling tools like get_primer (singular) and compile_program (different action).

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?

No guidance on when to use this tool versus alternatives, such as get_primer. The description lacks context about appropriate usage scenarios.

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

B3/5.0

Disambiguation5/5

Each tool targets a distinct operation: compilation, primer retrieval, linting, and listing rules or primers. Even though compile_program lacks a description, its name clearly distinguishes it from the others.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern with underscores (e.g., compile_program, get_primer, list_primers). Minor inconsistency: lint_chapel_code and list_chapel_lint_rules include 'chapel' while others omit it, but overall pattern is clear.

Tool Count5/5

With 5 tools, the server is well-scoped for a Chapel support utility. Each tool serves a clear purpose without redundancy or excess.

Completeness4/5

The tool set covers core Chapel operations: compilation, linting, and educational primers. A minor gap is the lack of a run or debug tool, but for a support-focused server the surface is adequate.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

salesforce-devops
cloud.serpent
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
CI/CD & DevOps Version Control CRM
2
hypertune A
io.usefulapi
Evaluate and inspect your Hypertune feature flags from your AI assistant.
Feature Flags Developer Tools
52
Writingmate MCP
ai.writingmate
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
AI & Machine Learning Image & Video Processing
1
Cypress Cloud MCP B
io.cypress.mcp
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Testing & QA Tools CI/CD & DevOps
24

Related MCP Servers

Almide MCP Server
Code Execution Developer Tools Code Analysis
almide
F
license
Not graded
quality
Not graded
maintenance
Enables AI agents to compile, execute, and check Almide code for syntax or compilation errors. It provides tools for generating ASTs and accessing language grammar resources.
Updated 6 months ago (2026-03-08 01:41 UTC)
MCP Server for VS Code
Developer Tools Code Execution Code Analysis
malvex
A
license
Not graded
quality
F
maintenance
Enables AI assistants to interact with VS Code for language intelligence, debugging, and code execution.
Updated 7 months ago (2026-01-26 08:45 UTC)
17
MIT
Arduino MCP Server (Simple)
Embedded system Command Line
amahpour
A
license
Not graded
quality
D
maintenance
Enables AI agents to interact with Arduino boards for compiling, uploading sketches, and serial communication.
Updated 5 months ago (2026-03-25 03:24 UTC)
6
MIT
Fortran Companion MCP Server
Developer Tools Code Analysis Code Execution
enkiEng
A
license
A
quality
C
maintenance
Enables AI models to write, format, compile, lint, and structure modern Fortran code using best practices and industry design patterns.
Updated 2 months ago (2026-06-26 03:30 UTC)
24
MIT

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/DanilaFe/chapel-support'

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