Which integrations are available for this server?

Read-only Jira ticket lookup with full-text search, similar ticket search, and attachment text retrieval for OpenWiFi triage. Search the linux-wireless patch mirror, run LLM triage pipeline, and backport patches to the Linux kernel tree.

How do I use openwifi-mcp?

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., "@openwifi-mcp triage WIFI-15461" 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.

openwifi-mcp

by firasshaari

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

openwifi-mcp

Three MCP servers that turn Claude Code into an interactive OpenWiFi triage assistant. When registered in your project's .mcp.json, Claude gains native tools to search the linux-wireless patch mirror, look up Jira tickets, run the LLM triage pipeline, dry-run + apply upstream backports, and drive OpenWiFi builds — all from within the same conversation you're already having about a bug.

Nothing runs in the cloud. All state lives on your machine or the build host you already control.

What ships

Server	Purpose	Backing service
`openwifi-jira`	Read-only Jira ticket lookup + similar-ticket search	openwifi-ticket-index
`openwifi-patches`	linux-wireless FTS5 search + LLM triage + backport helpers	openwifi-kernel-patches
`openwifi-build`	`make build/status/tail/fetch/deploy` wrappers over SSH	Your OpenWiFi build project

All three are stdio-transport MCP servers written in Python with FastMCP.

Related MCP server: codex-mcp-server

Tools exposed

openwifi-jira (read-only):

jira_list_releases — synced Jira fixVersions with ticket counts
jira_search_tickets(q, fix_version?, status?, assignee?, limit?) — full-text search
jira_get_ticket(key) — full ticket incl. comments, attachments, changelog, cross-refs
jira_get_attachment_text(id) — text content of indexed attachments
jira_ticket_similar(anchor, limit?) — similar tickets by key or symptom

openwifi-patches:

patches_stats — DB stats + LLM availability
patches_search(q, subject_prefix?, author?, since?, until?, limit?)
patches_get(message_id) — raw RFC 5322 body
patches_expand_query(symptom) — LLM-generated FTS5 query preview
patches_triage(symptom | ticket, top_n?) — full pipeline (patches + LLM explanations + similar tickets)
patches_dry_run_backport(message_id, tree) — non-mutating apply check
patches_apply_backport(message_id, tree) — MUTATING — commits to the tree

openwifi-build — wraps your Claude-OpenWiFi make targets:

build_help, build_status, build_tail(tag, lines?), build_fetch(tag) (non-mutating)
build_start(branch, target, pr?) — MUTATING — kicks off a long-running build
build_deploy(tag, ap, confirm=False) — MUTATING — sysupgrades a real AP

Install

git clone https://github.com/YOU/openwifi-mcp.git
cd openwifi-mcp
./setup.sh

The setup creates a venv, installs the package editable, and writes .mcp.snippet.json you can drop into your project's .mcp.json (or ~/.claude.json for user-scoped access).

Point three env vars at your existing services:

TICKET_INDEX_URL    = http://<host>:20504   # openwifi-ticket-index
PATCH_SEARCH_URL    = http://<host>:20503   # openwifi-kernel-patches
CLAUDE_OPENWIFI_ROOT = /abs/path/to/Claude-OpenWiFi

Restart Claude Code and the tools appear in every session under that project.

Suggested permission allowlist

Add to your project's .claude/settings.json so read-only tools skip the confirmation prompt but mutating tools still require it:

{
  "permissions": {
    "allow": [
      "mcp__openwifi-jira__*",
      "mcp__openwifi-patches__patches_stats",
      "mcp__openwifi-patches__patches_search",
      "mcp__openwifi-patches__patches_get",
      "mcp__openwifi-patches__patches_expand_query",
      "mcp__openwifi-patches__patches_triage",
      "mcp__openwifi-patches__patches_dry_run_backport",
      "mcp__openwifi-build__build_help",
      "mcp__openwifi-build__build_status",
      "mcp__openwifi-build__build_tail",
      "mcp__openwifi-build__build_fetch"
    ]
  }
}

patches_apply_backport, build_start, and build_deploy are deliberately NOT allowlisted — they mutate real state and should always prompt.

Slash command / skill

Pair with a skill like this in .claude/skills/openwifi-triage/SKILL.md so the user can just type /openwifi-triage WIFI-15461 (see the example in Claude-OpenWiFi).

License

MIT. See LICENSE.

Available Tools

6 tools

build_deployA

MUTATING — sysupgrade a real access point with the image built under tag. This is destructive: it reflashes the AP's firmware and reboots it. Only call after the user has explicitly agreed.

ParametersJSON Schema

Name	Required	Description
`ap`	Yes	AP management IP address (e.g. "10.0.127.213").
`tag`	Yes	A tag from build_status / build_fetch.
`confirm`	No	Must be True to proceed. If False, returns a preview.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

No annotations exist, so description carries full burden. It declares 'MUTATING', 'destructive', 'reflashes firmware and reboots', fully disclosing the impact.

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), front-loaded with 'MUTATING' for quick scanning, and every sentence adds critical information without redundancy.

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 presence of an output schema (not shown) and the clear disclosure of behavior, inputs, and prerequisites, the description is complete for this destructive deploy 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 coverage is 100% with descriptions for each parameter. The description adds context by linking 'tag' to build_status/fetch and explains the confirm parameter's preview behavior, going 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 uses a specific verb 'sysupgrade' and identifies the resource as 'real access point', clearly distinguishing it from sibling tools like build_start or build_status which are for building or fetching.

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?

It explicitly states 'Only call after the user has explicitly agreed', providing a clear prerequisite. It doesn't explicitly list alternatives but context from siblings implies this is the deploy step.

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

build_fetchA

Copy build artifacts (kernel + userspace image + build metadata) back to the Mac under Claude-OpenWiFi/artifacts//. Non-mutating on the build host; only touches local disk.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Explicitly states it is non-mutating on the build host and only affects local disk, which is good behavioral disclosure. Missing deeper details like permissions or error states.

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?

Two efficient sentences convey purpose, specifics, and behavioral note with no redundant information.

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?

Covers key aspects: what is copied, destination, mutability. An output schema exists to describe returns. Slightly lacking on whether tag must pre-exist.

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 description uses 'tag' in the path, providing context that it is a folder name, but does not explain valid values or format. With 0% schema coverage, more would be beneficial.

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?

Description clearly states the tool copies build artifacts (kernel, userspace image, metadata) to a specific path on Mac, distinguishing it from sibling tools like build_start or build_deploy.

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?

No explicit guidance on when to use this tool versus alternatives. The action is implied but lacks context like prerequisites or typical workflow placement.

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

build_helpA

Print Claude-OpenWiFi's make help — the list of available build targets and their expected arguments. Use this before calling any other build tool if you're unsure of the syntax.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

No annotations provided, but the description fully covers the tool's behavior: it prints help text. It implies no side effects. The description is self-sufficient for this simple tool.

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?

Two sentences, no fluff. Critical information is front-loaded. Every word adds value.

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 tool's low complexity (no params, read-only), and the presence of an output schema, the description is complete. It explains purpose and usage adequately.

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 and schema coverage is 100%, so no parameter description is needed. The description doesn't add parameter info, but it's not necessary. Baseline 4 is appropriate.

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 that the tool prints the help output for build targets. It uses specific verb 'Print' and resource 'Claude-OpenWiFi's make help', which is distinct from sibling tools that perform builds.

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?

Explicit guidance: 'Use this before calling any other build tool if you're unsure of the syntax.' This tells the agent when to use this tool and implies it is a prerequisite for other build tools.

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

build_startA

MUTATING — start a wlan-ap build.

Every build parameter is explicit; nothing is defaulted. The build runs on the build host over SSH and takes 30-90 minutes. This tool returns as soon as the build is launched — poll with build_status or build_tail(tag) to track progress.

ParametersJSON Schema

Name	Required	Description
`pr`	No	Optional wlan-ap PR number to cherry-pick.
`branch`	Yes	wlan-ap branch, e.g. "main" / "stable-4.2.4" / "v4.2.4".
`target`	Yes	yuncore_ax820 / yuncore_fap655 / edgecore_eap101 / edgecore_eap105 / cig_wf196 / …

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations exist, so description carries full burden. It discloses the mutating nature, SSH execution, duration, and asynchronous behavior. Could mention error handling or permissions but is adequate for a build start tool.

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?

Four sentences, each adding value: mutation flag, explicitness, runtime, polling advice. No redundancy or fluff. 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 the tool's simplicity (3 parameters, 2 required), 100% schema coverage, and presence of an output schema, the description fully explains the asynchronous nature and how to track progress, making it complete.

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 coverage is 100%, so the schema already describes all parameters. The description adds the statement that nothing is defaulted, which reinforces but doesn't add significant new 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 starts with 'MUTATING — start a wlan-ap build', clearly stating the action (start) and resource (wlan-ap build). It distinguishes from siblings by mentioning polling with build_status or build_tail.

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?

Explicitly states the build runs over SSH, takes 30-90 minutes, returns immediately, and advises polling with build_status or build_tail for progress. Also notes that all parameters are explicit with no defaults.

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

build_statusA

Show running builds and recently-finished artifacts. Includes per-build tags (used with build_tail / build_fetch / build_deploy).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

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. It does not disclose behavioral traits such as authentication requirements, rate limits, or what 'recently-finished' means (e.g., time window). The description is too minimal for a tool that may have side effects or access restrictions.

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 only two sentences with no wasted words. The first sentence directly states the purpose, and the second adds essential detail about tags. It is front-loaded and efficient.

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 there are zero parameters and an output schema exists, the description is mostly complete. It explains the core functionality and relationships to siblings. However, it lacks specifics like the definition of 'recently-finished' or any pagination details, but these may be covered by the output schema.

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?

There are zero parameters, so no parameter documentation is needed. The baseline for 0 parameters is 4, and the description does not add any confusion. It correctly omits parameter info since none exist.

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 'Show' and the resources 'running builds and recently-finished artifacts'. It further distinguishes itself from siblings by mentioning 'includes per-build tags (used with build_tail / build_fetch / build_deploy)', which clarifies its unique role.

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 usage context by stating it provides tags for other tools, but it does not explicitly state when to use build_status versus alternatives like build_help or build_start. No when-not-to guidance is provided.

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

build_tailA

Show the tail of a build log. Use the tag returned by build_start or listed in build_status.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes
`lines`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided. Description only states purpose ('show'), with no disclosure of side effects, authorization needs, or confirmation that it's read-only. Carries the full burden but adds minimal behavioral context.

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?

Two concise sentences, front-loaded with purpose, followed by a usage note. No unnecessary words.

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?

Has output schema, so return value is documented elsewhere. Covers tag source and lines default, but does not explicitly mention that lines is optional or describe the output nature. Generally adequate for a simple 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?

Schema has 0% description coverage. Description adds meaning for 'tag' (source from other tools) but not for 'lines'. Partially compensates for the schema gap.

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 'Show the tail of a build log', a specific verb and resource. Distinguishes from sibling tools like build_start, build_fetch, etc.

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?

Explicitly tells where to get the tag: 'Use the tag returned by build_start or listed in build_status'. Provides clear context but no exclusions or when-not-to-use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 28, 2026
- First observedbuild_deploy
- First observedbuild_fetch
- First observedbuild_help
- First observedbuild_start
- First observedbuild_status
- First observedbuild_tail

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a distinct and unambiguous purpose: help, status, start, tail, fetch, and deploy. No two tools overlap in functionality, ensuring an agent can easily select the correct one.

Naming Consistency5/5

All tools follow a consistent 'build_<verb>' pattern with imperative verbs (help, status, start, tail, fetch, deploy). This makes the tool surface predictable and easy to navigate.

Tool Count5/5

With 6 tools, the set is well-scoped for the domain of building and deploying OpenWiFi firmware. It covers the entire workflow without being excessively large or insufficient.

Completeness4/5

The tools cover the core lifecycle: help, start build, monitor progress (status, tail), fetch artifacts, and deploy. Minor omissions like a cancel or cleanup tool exist, but the essential path is complete.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

AgentSEO B
dev.agentseo.www
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Marketing Browser Automation
454
AI Worlds CLI Knowledge A
com.claude-world
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Command Line Developer Tools Documentation Access
121
OpenClaw Direct AOAuth
direct.openclaw
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Agent Orchestration Autonomous Agents Monitoring
2
WHOOP — MissingMCPOAuth
com.missingmcp
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Health & Wellness Fitness Tracking
24

Related MCP Servers

Claude Code Starter Kit MCP
Testing & QA Tools Code Analysis Penetration Testing
dachivadachkoria
A
license
C
quality
C
maintenance
Enables AI-powered automated testing, security scanning, code review, and maintenance tasks directly within Claude Code or desktop.
Updated 6 months ago (2026-03-08 21:09 UTC)
12
4
MIT
codex-mcp-server
Code Analysis Coding Agents
tuannvm
A
license
A
quality
C
maintenance
Bridges Claude and OpenAI's Codex CLI for AI-powered code analysis, generation, and review, with support for session management, web search, and structured output.
Updated 3 months ago (2026-05-25 02:12 UTC)
6
674
630
ISC
gitlab-review-mcp
Version Control Project Management Developer Tools
midodimori
A
license
A
quality
C
maintenance
Enables interaction with GitLab projects, merge requests, issues, and code reviews through Claude AI, providing tools for code review and project management.
Updated a year ago (2025-10-16 05:17 UTC)
14
1
MIT
Cursor MCP Server
Developer Tools Code Analysis Version Control
tariqnasheed
F
license
Not graded
quality
D
maintenance
Turns Claude Desktop into a Cursor-like assistant for code browsing, editing, searching, linting, formatting, and version control.
Updated 3 months ago (2026-06-10 11:47 UTC)
-

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/firasshaari/openwifi-mcp'

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