DEV Community: foss42

Building API Dash MCP Server - Adding SPA MCP App

Abdelrahman El-Borgy — Mon, 17 Aug 2026 18:40:37 +0000

We are officially at the halfway mark of Google Summer of Code GSoC 2026

Over the past period, my core focus has been bridging the gap between traditional API testing workflows and modern AI-assisted development. Working on API Dash—an open-source, lightweight API client—my mission is to transform standard request-and-response workflows into a fully autonomous, AI-native testing ecosystem.

1. The Foundation: What is API Dash?

Before adding AI to the mix, API Dash is a standalone, open-source developer tool. Whenever developers write backend code or build web services, they need a way to test if their URLs (endpoints) are working, sending the right data, and returning the correct responses. Developers traditionally use visual tools like Postman, Insomnia, or API Dash to manually build and fire off these HTTP requests.

2. The Problem: The "Context-Switching" Tax

As AI assistants (like VS Code Copilot, Cursor, or Claude) have become standard in coding, a new bottleneck has emerged.
If an AI suggests a piece of code to fetch data from an API, the developer still has to:

Leave their code editor.
Open their API client (like API Dash).
Copy and paste the URL, authentication tokens, and JSON payloads.
Click "Send" and manually read the errors.
Go back to the AI and explain what went wrong.

This constant tab-switching breaks a developer's focus.

3. The Solution: The API Dash MCP Server

This is where the API Dash MCP Server comes in. If the Model Context Protocol (MCP) is the "universal USB-C port," then the API Dash MCP Server is the smart adapter plugged into that port.

It is a specialized backend program that runs locally on your computer and allows your AI assistant to "drive" API Dash for you. It safely exposes API Dash's core capabilities directly to the AI, turning a manual visual tool into an automated, AI-driven testing engine.

What it actually does for the user:

Automated Testing: Instead of you manually clicking buttons, you can just tell your AI, "Test the user login API and tell me if it works." The AI communicates through the MCP Server to fire the request using the API Dash engine.

Embedded Interactive UIs: When the AI tests an API, it doesn't just spit back a wall of text. The server generates interactive UI widgets (Single Page Applications) right inside your chat window. You get a fully functional mini-version of API Dash directly in your editor to tweak headers, view history, or read logs.

Database Memory: It hooks into your local database (Hive) so the AI can review past requests. You can ask, "Show my past history requests in apidash" and the server will fetch that history for you.

Ultimately, the API Dash MCP Server turns your AI assistant into a proactive co-pilot that can natively test, debug, and visualize your network requests without you ever having to leave your coding environment.

The Architecture:

The AI Host (Client): The developer prompts their AI assistant in the IDE.
The Bridge (apidash-mcp): A lightweight NPM wrapper spawns the local API Dash binary and bridges communications via standard input/output (stdio) streams using standard JSON-RPC 2.0 messages.
The Dart Engine (mcp_dart): Running headlessly in API Dash (--mcp-engine), the Dart backend executes HTTP requests, manages local Hive database history, and evaluates environment variables.
The MCP App Canvas: Instead of responding with plain text, the engine serves interactive Single Page Applications (SPAs) directly into the AI chat interface via the emerging text/html;profile=mcp-app standard.

The User Experience: API Dash in Action

Here is what the end-to-end developer experience looks like in practice:

Step 1: One-Line Configuration

Developers configure their AI client (like VS Code or Cursor) by simply adding the NPM bridge to their mcp.json file. No manual binary compilation is required:

{
  "servers": {
    "apidash": {
      "command": "npx",
      "args": ["-y", "apidash-mcp@latest"]
    }
  }
}

Step 2: Natural Language Prompting & Tab Navigation

Once connected, the AI model automatically registers API Dash tools. A developer can now talk to their API workspace naturally:

"Execute a GET request to https://api.github.com/users/foss42"
"Show my request history"
"Open the environment variables manager"

The agent intelligently routes the prompt to the correct tool and triggers the appropriate workbench view.

Step 3: Embedded Interactive Workbenches Inside Chat

Instead of dumping raw JSON responses into the conversation, API Dash embeds a rich, interactive visual studio directly into the chat pane:
Developers can click, tweak headers, edit URL params, inspect execution timings in milliseconds, or switch environment variables right inside their AI chat.

Key Achievements & Technical Milestones

1. Implemented MCP Server & Core Tools

Built using mcp_dart and apidash_core, the engine exposes a rich suite of capabilities:

apidash_execute_request: Executes HTTP requests (GET, POST, PUT, DELETE, etc.) with custom headers and body payloads.
apidash_get_results & apidash_list_history: Queries local Hive database storage for instant session ledger reviews.
apidash_delete_request: Removes history records safely by ID.
apidash_launch_*: Direct navigation tools (apidash_launch_workbench, apidash_launch_history_tab, apidash_launch_variables_tab, apidash_launch_logs_tab) to launch specific UI panes.
apidash_btn_send: An agentic pre-flight sanity inspector triggered on UI submission.

2. Multi-Tab SPA MCP App Workbenches

We created a modular SPA framework rendered cleanly inside the MCP App window with full theme awareness:

Request Studio: Complete HTTP request/response builder.
Environment Variables Manager: Manage Global and local variables, bearer tokens, and base URLs.
Session Execution Ledger: Live history feed directly connected to Hive DB.

3. The Node.js Bridge on NPM apidash-mcp

Published live at apidash-mcp on NPM:

Smart Path Resolution: Automatically resolves executable paths across Windows, macOS, and Linux, checking APIDASH_PATH, system PATH, and standard OS directories.
Process Lifecycle Safety: Implemented strict signals (SIGINT, SIGTERM, exit) to ensure zero orphan Flutter processes are left behind when the IDE closes.

Key Learnings & Technical Highlights

Cross-Boundary Communication (postMessage & RPC): Connected embedded iframe-based MCP Apps to host IDEs using ResizeObserver and postMessage (MCP_APP_RESIZE) for smooth, auto-adjusting canvas heights.
Native IDE Theme Synchronization: Dynamically mapped host CSS environment tokens (VS Code theme colors) into the workbench canvas so it adapts instantly to Light/Dark modes.
Agentic Pre-Flight Sanity Inspection: Created a pre-flight inspector (apidash_btn_send) that analyzes drafted payloads before execution to catch missing auth tokens or malformed URLs early.

What’s Next for the Second Half?

With the foundational backend engine, bridge, persistence layer, and SPA workbenches complete, my goals for the remaining coding period are:

Full Feature Parity: Expanding the MCP tools to support collection management.
In-App AI Chat Engine: Embedding a native AI assistant directly into the API Dash desktop application.
Chained Agentic Workflows: Enabling autonomous end-to-end API test generation and multi-step verification pipelines.

Building the Foundation for Git and Scan Sync in API Dash (GSoC 2026)

Shashwat Pratap Singh — Mon, 20 Jul 2026 19:25:06 +0000

Git was not the most difficult part of my Google Summer of Code project.

The greater challenge was recognizing that our storage layer could not support the collaboration experience we intended to deliver.

Git, Scan Sync, and live filesystem updates all followed from addressing that foundation first.

Where I started

I'm a Google Summer of Code 2026 contributor with API Dash, working on Git Support, UI Workflow Builder & Collection Dashboard.

The midterm objective was not a single feature. It was a shared architectural spine:

Make collections real, shareable workspaces so desktop teams can use Git, and your phone can stay in the loop without fighting the stack.

In practice, that meant one folder on disk that desktop Git, phone Sync, and the UI could all treat as the same source of truth.

The problem

API Dash previously persisted data in Hive. That approach worked for a single machine, but the data was binary and neither human-readable nor suitable for Git. Introducing a conversion layer on top would have created two sources of truth and ongoing translation overhead.

In discussion with mentors, we chose a clearer path: own a filesystem workspace instead. See PR #1695 (storage migration).

A workspace is simply a folder: collections, environments, and workflows as readable JSON. Secrets stay in secure storage on the device, not in those files , so sharing a workspace does not accidentally share keys.

Why JSON?

Flutter and API Dash were already oriented around this model. Domain models already exposed toJson / fromJson. The architecture already used maps and JSON for requests, imports, and code generation. Writing that same shape to disk was not a new serialization dialect; it was aligning persistence with what the application already trusted.

The approach was fast to implement, straightforward to diff, and easy for users to inspect. It avoided maintaining a parallel serialization path.

That decision unlocked the rest: Git for desktop team collaboration, Scan Sync for laptop and phone, and disk-to-UI synchronization so folder changes appear in the application - all on the same workspace.

A workspace you can actually open and understand.

Git vs Scan Sync

Git for teams (desktop)

Desktop Git is the natural collaboration path: system Git, OS credentials, clone / commit / push / pull, and Visual/Raw diffs in a Collaboration tab. See PR #1734 (scan sync / collaboration).

The workspace folder is the repo. History and local-only files stay out of Git by design; what you review and push is the same JSON you can open in Finder.

Review before you push or pull. Same diff language everywhere.

Scan Sync for your phone

Full Git on mobile appeared consistent in theory and awkward in practice authentication, SSH, and conflict resolution on a small screen for a job that is usually simply "get this workspace onto my phone."

We therefore built Scan Sync: same Wi‑Fi, QR pairing, a device-to-device link, the same review diffs as Git, then Apply. Under the hood, file hashes (SHA) keep a shared baseline so later syncs can show only what changed—Send or Receive without copying the whole workspace every time.

Git: collaborate with a team over a remote
Scan Sync: move your workspace between your devices, quickly

Same files. Right tool for each side.

Scan Sync: pair on the same Wi‑Fi, review, Apply.

Watching the filesystem

A filesystem-first design only works if the interface remains accurate. We added an event tracker on disk so the desktop app notices when a collection or request is added or removed outside the UI; the catalog updates accordingly. The application's own writes are filtered out so autosave does not conflict with the watcher.

Whether the change comes from Git pull, Scan Sync Apply, or an edit in Finder, the expectation is the same: the UI matches the folder.

Delete on disk. The UI follows.

What I learned

Do not paper over the foundation. A Hive-to-file bridge would have deferred the real design. Mentors advocated filesystem-first. That was the unlock.
Use what the architecture already provides. JSON was not a fashion choice. toJson / fromJson was already familiar ground for Flutter and API Dash.
The filesystem must be usable for humans, not only correct for Git. Folders and names should make sense in Finder so users always know what they are looking at and where their data lives. If they cannot tell what a file is, the workspace is incomplete.
One truth, several doors. Storage, Git, Scan Sync, and disk-to-UI are connected by design, not bolted on separately.
Match the tool to the job. Git where teams collaborate. Scan Sync where phone speed matters.
Reuse the review path. One Visual/Raw mental model for pull and for phone Apply.

What's next

Land the pull requests, then Workflow Builder and Dashboard on a workspace we can trust.

Looking back

In retrospect, Git was not really the project.

The project was building a workspace architecture that Git, Scan Sync, and future features could all rely on.

Along the way, my priorities also shifted. I previously optimized primarily for clean, maintainable code. That still matters. I now place greater weight on user experience: Can someone open the folder and understand what they are looking at? Can they sync to their phone without fighting the application? Does the UI remain accurate when the disk changes?

Maintainable code is how you get there. Usability is why it matters.