Which integrations are available for this server?

Provides guided workflow for building and deploying FTC robot code using Android Studio, including troubleshooting common build issues. Delivers comprehensive knowledge of the FIRST Tech Challenge (FTC) robot controller ecosystem, including hardware APIs, software libraries, and best practices for competition programming. Provides detailed documentation and configuration examples for Gradle build system in FTC projects, including Maven coordinates and dependency management. Provides API documentation and initialization patterns for SparkFun OTOS (Optical Tracking Odometry Sensor) hardware used in FTC robot localization.

How do I use ftc-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., "@ftc-mcp write a basic TeleOp for mecanum drive using Pedro Pathing" 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.

ftc-mcp

by jackulau

Overview Schema Related Servers Score Discussions

TypeScript

Local

ftc-mcp

MCP server that gives AI coding assistants deep knowledge of the FTC Robot Controller ecosystem. Enables teams to "vibe code" their robots through natural language while producing correct, optimized, competition-ready Java code.

The problem: AI assistants hallucinate wrong Pedro Pathing APIs (training data is outdated), don't know the @Config + public static dashboard pattern, use wrong import paths, and can't see your project structure.

The fix: This MCP server injects 9,500+ lines of verified FTC documentation, API references, and working code examples directly into your AI assistant's context.

One-Click Install

Install in Cursor

Claude Code

claude mcp add ftc -- npx ftc-mcp

Cursor (Manual)

Or use the one-click button above.

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "ftc": {
      "command": "npx",
      "args": ["-y", "ftc-mcp"]
    }
  }
}

VS Code (Copilot)

Install in VS Code

Or add to .vscode/mcp.json:

{
  "servers": {
    "ftc": {
      "command": "npx",
      "args": ["-y", "ftc-mcp"]
    }
  }
}

Windsurf

Add to your Windsurf MCP config:

{
  "mcpServers": {
    "ftc": {
      "command": "npx",
      "args": ["-y", "ftc-mcp"]
    }
  }
}

Any MCP Client (`.mcp.json`)

Drop this file in your project root:

{
  "mcpServers": {
    "ftc": {
      "command": "npx",
      "args": ["-y", "ftc-mcp"]
    }
  }
}

From Source

git clone https://github.com/jackulau/ftcMCP.git
cd ftcMCP
npm install
npm run build

# Then add to your AI client:
claude mcp add ftc -- node /path/to/ftcMCP/build/index.js

Related MCP server: OmniDocs MCP

What It Provides

49 Resources (Documentation)

Contextual docs the AI pulls in when writing FTC code:

Category	Resources	Coverage
Pedro Pathing 2.1	7	Complete API (Follower, PathBuilder, PathChain, BezierLine/Curve), Constants builder pattern, coordinate system [0,144], auto FSM structure, TeleOp drive, callbacks, v2.1 release notes (predictive braking, swerve, auto-offsets tuner)
FTC Dashboard	6	`@Config` + `public static` pattern, copy semantics pitfall, MultipleTelemetry, TelemetryPacket, Canvas field overlay API, camera streaming, setup
Panels (by Lazar)	8	Overview & comparison with FTC Dashboard, setup & Gradle config, `@Configurable` live tuning, `PanelsTelemetry`, `PanelsField` canvas drawing, Limelight proxy, plugin architecture, gamepad support
Gradle	5	Project file structure, adding libraries step-by-step, exact Maven coordinates for every library, common issues (compileSdk 34 for Pedro), build process
Hardware	17	DcMotor/DcMotorEx full API, RunModes, motor specs (every goBILDA/REV CPR), servos, IMU, distance/color/touch sensors, encoders (port 0+3 vs 1+2), GoBilda Pinpoint, SparkFun OTOS, REV Hub internals, bulk reads, CachingHardware, custom wrapper patterns, VisionPortal + Limelight
Core SDK	5	OpMode lifecycle (iterative vs linear), hardwareMap patterns, gamepad API, best practices
Road Runner	1	Actions API, TrajectoryActionBuilder
FTCLib	1	Command-based framework, GamepadEx, triggers

MCP Spec Compliance

Feature	Status
Protocol version	2025-11-25 (latest)
`tools` capability	✓ with `outputSchema` + `structuredContent` + `annotations`
`resources` capability	✓ template-based (9 categories, 1 template each)
`prompts` capability	✓ all 11 prompts use `registerPrompt`
`completions` capability	✓ prompt args + resource template `{topic}` autocomplete
`logging` capability	✓ declared, available for client-subscribed diagnostics

3 Tools (context-optimized, SDK 1.29 with `outputSchema` + `structuredContent`)

Tool	What It Does
`scan_project`	Scans your TeamCode directory -- detects SDK version, installed libraries (Pedro, Dashboard, Panels, RoadRunner, FTCLib, SolversLib, CachingHardware), existing OpModes, hardware devices, and Pedro Constants. Returns typed `structuredContent`. Call at the start of every session.
`search_knowledge`	Single entry point for the entire knowledge base. Tries exact example match → device API reference → full-text search across all categories.
`validate_ftc_code`	Checks code for common FTC mistakes: missing `follower.update()`, `@Config` with `final`, Thread.sleep in iterative OpMode, Pedro v1 imports, copy semantics, bulk-cache misuse, SolversLib/FTCLib coexistence, gamepad Y inversion, CommandOpMode `super.run()` gaps. Returns typed `structuredContent` with severity-classified issues.

10 Complete Code Examples

Every example is a full, compilable Java file with package declaration, all imports, and working code:

Topic	Description
`pedro-auto`	Pedro Pathing autonomous with FSM state machine, path callbacks, @Config tunable poses, field overlay
`pedro-teleop`	Pedro TeleOp with `setTeleOpDrive()`, slow mode, bulk reads, loop timer
`pedro-constants`	Complete Constants.java with FollowerConstants, MecanumConstants, PinpointConstants builders
`dashboard-config`	@Config demonstration with correct/wrong copy semantics examples
`bulk-reads`	Optimized OpMode with LynxModule MANUAL + CachingHardware
`subsystem`	Hardware subsystem class with @Config positions, state methods
`pid-tuning`	Live PID tuning with dashboard-graphed error/output
`vision-pipeline`	VisionPortal + AprilTag processor with dashboard camera stream
`custom-pid-drive`	Encoder-based autonomous with IMU heading PID (no pathing library)
`field-centric-drive`	Field-centric mecanum TeleOp using IMU

11 Workflow Prompts

Structured instructions that guide the AI through complex FTC tasks:

Prompt	Description
`setup-ftc-project`	Guided project init: choose pathing lib, configure Gradle, add dashboard
`create-autonomous`	Full auto creation: poses, paths, FSM, callbacks, dashboard telemetry
`create-teleop`	TeleOp: drive type, subsystems, gamepad bindings, slow mode
`create-subsystem`	Hardware subsystem with @Config tuning, state methods
`tune-pid`	PID tuning with dashboard live graphing
`optimize-performance`	Bulk reads, CachingHardware, loop timer, I2C reduction
`add-dashboard-tuning`	Add @Config live-tunable variables to existing code
`setup-command-based`	Command-based project with SolversLib: subsystems, commands, gamepad bindings
`build-and-deploy`	Build + deploy workflow for VS Code, Android Studio, IntelliJ, or CLI
`setup-vision`	VisionPortal + Limelight 3A: AprilTag and color detection
`setup-gradle`	Configure Gradle deps for any combination of FTC libraries

Supported Libraries

Library	Version	Knowledge Depth
FTC SDK	11.1.0	Full hardware API, OpMode lifecycle, gamepad, telemetry
Pedro Pathing	2.1.2	Complete v2.0+ API with builder patterns; v2.1 notes for predictive braking + swerve (NOT the outdated v1.x)
FTC Dashboard	0.5.1	@Config, MultipleTelemetry, Canvas, camera streaming
Panels	1.0.12	@Configurable, PanelsTelemetry, PanelsField, Limelight proxy, plugin architecture, gamepads, capture/replay
Road Runner	1.0.x	Actions API, TrajectoryActionBuilder
CachingHardware	1.0.0	Write caching algorithm, drop-in wrappers
FTCLib	2.1.1	Command-based framework, GamepadEx

Supported Hardware

Full API documentation and initialization patterns for:

Motors: DcMotor, DcMotorEx, all RunModes, PIDF coefficients, every goBILDA/REV/NeveRest motor with exact CPR
Servos: Servo, ServoImplEx (PWM range), CRServo, power pairing rules
Sensors: REV IMU, Color Sensor V3, 2m Distance Sensor, Touch Sensor, Through Bore Encoder
Localizers: goBILDA Pinpoint (full driver API, offsets, status enum), SparkFun OTOS (scalars, calibration)
Vision: VisionPortal, AprilTagProcessor, Limelight 3A
REV Hub: LynxModule bulk reads (OFF/AUTO/MANUAL), I2C timing, encoder port hardware vs software decoding

Example Vibe Coding Sessions

"Set up my project with Pedro Pathing and Dashboard"

AI calls scan_project -> reads ftc://gradle/all-library-coords -> edits build.dependencies.gradle with exact repos and versions -> changes compileSdk to 34 -> creates Constants.java with builder pattern

"Create an autonomous that scores 3 samples"

AI reads ftc://pedro/api-reference + ftc://pedro/auto-structure -> generates complete OpMode with @Config tunable poses, FSM state machine, path callbacks, MultipleTelemetry, field overlay

"My loop times are slow"

AI reads ftc://hardware/bulk-reads + ftc://hardware/caching-hardware -> adds LynxModule MANUAL + CachingDcMotorEx + loop timer telemetry

"Add a dashboard variable so I can tune arm position"

AI reads ftc://dashboard/config-pattern -> adds @Config class with public static double ARM_POSITION = 0.5; -> warns about reading it fresh each loop (copy semantics)

Project Structure

ftc-mcp/
├── src/
│   ├── index.ts                  # Entry point (stdio transport)
│   ├── server.ts                 # McpServer setup
│   ├── knowledge/
│   │   ├── pedro.ts              # Pedro Pathing 2.0 (1,550 lines)
│   │   ├── hardware.ts           # Full hardware stack (1,479 lines)
│   │   ├── examples.ts           # 10 complete code examples (1,396 lines)
│   │   ├── ftc-sdk.ts            # SDK patterns (881 lines)
│   │   ├── dashboard.ts          # FTC Dashboard (845 lines)
│   │   ├── panels.ts             # Panels by Lazar — all-in-one dashboard
│   │   ├── ftclib.ts             # FTCLib framework (636 lines)
│   │   ├── gradle.ts             # Gradle build system (584 lines)
│   │   └── roadrunner.ts         # Road Runner (478 lines)
│   ├── resources/registry.ts     # 41 resource URI registrations
│   ├── tools/registry.ts         # 6 tool implementations
│   └── prompts/registry.ts       # 8 workflow prompts
├── package.json
└── tsconfig.json

Development

npm install
npm run build          # Compile TypeScript
npm run dev            # Watch mode
npm start              # Run the server

Requirements

Node.js >= 18
An MCP-compatible AI client (Claude Code, Cursor, VS Code Copilot, etc.)

License

MIT

Available Tools

3 tools

scan_projectScan FTC ProjectA

Read-only

Scan FTC project for SDK version, libraries, OpModes, hardware devices, and structure. Use at session start.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	FTC project root path

Output Schema

ParametersJSON Schema

Name	Required	Description
`buildDependenciesGradle`	Yes
`compileSdkVersion`	Yes
`libraries`	Yes
`teamCodeDir`	Yes
`javaFiles`	Yes
`opModes`	Yes
`configClasses`	Yes
`hardwareDevices`	Yes
`usesPedro`	Yes
`usesRoadRunner`	Yes
`usesSolversLib`	Yes
`usesFtcLib`	Yes
`usesCommandBase`	Yes
`usesPanels`	Yes
`hasFollowerConstants`	Yes
`hasMecanumConstants`	Yes
`error`	No

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's lack of mutation disclosure is acceptable. It adds value by listing what is scanned (SDK, libraries, etc.), but does not mention any other behavioral traits like performance or side effects. Adequate but not exceptional.

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 a single sentence plus a usage note, with no wasted words. The verb 'Scan' is front-loaded, efficiently conveying the action and scope.

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 simplicity (1 param, output schema exists, siblings clear), the description covers the tool's purpose and timing. It lacks explicit mention that projectPath must be an existing directory, but overall provides sufficient context for a straightforward scan 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?

The schema has 100% coverage for the single parameter 'projectPath' with a description. The tool description does not add further meaning beyond what the schema provides, so baseline score of 3 applies.

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 scans an FTC project for specific elements (SDK version, libraries, OpModes, etc.) and distinguishes from siblings like search_knowledge and validate_ftc_code. The verb 'scan' with resource 'FTC project' and listed specifics define a unique purpose.

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 instruction 'Use at session start' provides clear timing guidance. While alternatives are not explicitly mentioned, the siblings are distinct in purpose, reducing confusion. No exclusions or when-not-to-use are given, but the context is sufficient for a simple tool.

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

search_knowledgeSearch FTC KnowledgeA

Read-only

Search FTC knowledge base. Finds documentation, code examples, and hardware API references.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query, example topic, or device name

TDQS

A3.6/5.0

Behavior3/5

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

Description adds context about content types beyond the readOnlyHint annotation but omits details like return format, pagination, or rate limits. It does not contradict annotations.

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, front-loaded sentences with no redundant information. Every word adds value.

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?

For a simple search tool with one parameter and no output schema, the description adequately covers purpose and scope. However, it could improve by hinting at result behavior (e.g., returns relevant snippets).

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 single parameter 'query' is fully described in the schema (100% coverage). The tool description adds no extra semantic value, so baseline score of 3 applies.

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 verb 'Search' and resource 'FTC knowledge base'. It lists specific content types (documentation, code examples, hardware API references) that distinguish it from sibling tools like scan_project and validate_ftc_code.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention when to prefer search_knowledge over scan_project or validate_ftc_code, making it ambiguous for an agent to decide.

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

validate_ftc_codeValidate FTC CodeA

Read-only

Validate FTC Java code for common mistakes and anti-patterns.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Java code to validate

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`issueCount`	Yes
`issues`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint true and openWorldHint false. The description adds that it checks for common mistakes and anti-patterns, but lacks details on validation specifics (e.g., error reporting style).

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?

A single sentence, front-loaded, with no wasted 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?

Given low complexity (one param, output schema exists, annotations present), the description is fairly complete, though it could mention the output format.

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 100% schema coverage and only one parameter clearly described in the schema, the description adds minimal value beyond 'Java code to validate'.

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 validates FTC Java code for common mistakes and anti-patterns, distinguishing it from siblings like scan_project and search_knowledge.

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 for validating FTC code but does not explicitly provide when to use or when not to use compared to sibling tools.

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.

3 tool updatesv1.3.1Jun 13, 2026
- First observedscan_project
- First observedsearch_knowledge
- First observedvalidate_ftc_code

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: scanning a project, searching knowledge, and validating code. No overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, making them predictable and easy to understand.

Tool Count5/5

Three tools is appropriate for the focused domain of FTC project analysis, covering key tasks without excess.

Completeness5/5

The tool set covers the essential actions for an FTC development assistant: initial project scan, knowledge search, and code validation. No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
DevSpeak
io.github.juanjaragavi
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
Developer Tools AI & Machine Learning Documentation Access
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214

Related MCP Servers

Vibe Coder MCP
Developer Tools Code Execution Autonomous Agents
freshtechbro
A
license
B
quality
C
maintenance
An MCP server that supercharges AI assistants with powerful tools for software development, enabling research, planning, code generation, and project scaffolding through natural language interaction.
Updated a year ago (2025-08-21 03:06 UTC)
11
67
101
MIT
OmniDocs MCP
RAG Systems Documentation Access Developer Tools
Yogesh-G-3468
F
license
Not graded
quality
D
maintenance
An intelligent MCP server that enables AI agents to crawl, index, and semantically search official framework documentation using local RAG. It prevents hallucinations by providing precise, up-to-date documentation excerpts directly into the AI's context window.
Updated 6 months ago (2026-02-23 15:47 UTC)
1
-
ftc-knowledge-server
Documentation Access Research & Data Education & Learning Tools
david-constantinescu
F
license
Not graded
quality
D
maintenance
Remote MCP server for FTC & Pedro Pathing research, providing tools to search technical notes, code templates, and verified team examples to assist AI agents in code generation and robotics development.
Updated 3 months ago (2026-06-13 09:47 UTC)
-
mcdev-mcp
Games & Gamification Code Analysis Autonomous Agents
use-ai-for-mc
A
license
A
quality
A
maintenance
An MCP server that empowers AI coding agents to work effectively with Minecraft mod development, providing static analysis of decompiled source code and runtime interaction with a running Minecraft instance.
Updated 6 days ago (2026-08-31 10:27 UTC)
31
44
13
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/jackulau/ftcMCP'

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

ftc-mcp

One-Click Install

Claude Code

Cursor (Manual)

VS Code (Copilot)

Windsurf

Any MCP Client (.mcp.json)

From Source

What It Provides

49 Resources (Documentation)

MCP Spec Compliance

3 Tools (context-optimized, SDK 1.29 with outputSchema + structuredContent)

10 Complete Code Examples

11 Workflow Prompts

Supported Libraries

Supported Hardware

Example Vibe Coding Sessions

Project Structure

Development

Requirements

License

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Any MCP Client (`.mcp.json`)

3 Tools (context-optimized, SDK 1.29 with `outputSchema` + `structuredContent`)