Discussion on #6 - CLI & MCP Support

[animator]

This project focuses on creating a CLI tool to run API Dash via terminal. Contributors will design and implement command-line interfaces that expose core capabilities of API Dash that help in API testing. Also, your task is to expose API Dash as a MCP Server so that it can be run via any Agent interface (like VS Code, AI Apps, etc.) that supports MCP.

Also, go through this resource to study if MCP Apps can be served via API Dash MCP server.

Tech Stack: Anything for CLI, Dart/Flutter for API Dash codebase

Please feel free to discuss your ideas/research below.

[pratapsisodiya]

[mshehto]

Hello, a lot of great ideas! In the GSoC meeting @animator mentioned they’re leaning toward implementing MCP in TypeScript due to its stronger ecosystem support at the moment. Just wanted to share this context in case it helps!

[pratapsisodiya]

Hello, a lot of great ideas! In the GSoC meeting @animator mentioned they’re leaning toward implementing MCP in TypeScript due to its stronger ecosystem support at the moment. Just wanted to share this context in case it helps!

Ya but re creation of core apidash package in typescript or python is not a good efficient idea I thinks my ideas uses the current apidash packages functionality.
So no duplication of core logic in mcp pkg

[mshehto]

Great! I just wanted to inform you what was discussed :)

[animator]

@mshehto That is project # 1
This is project # 6 which will be completely implemented in dart.

[animator]

@praaatap Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[vik05h]

My Research & Existing Implementation for CLI & MCP Support

Hi @animator and mentors,

I’ve been actively exploring MCP support in API Dash and wanted to share what I’ve already implemented, along with how I think it maps to GSoC 2026 Idea 6 (CLI & MCP Support).

---

Background

This builds on the original feature request:
#845 - Add support for working with MCP for LLMs to access APIs

As part of that work, I already built a working MCP Server implementation as a standalone Dart package under packages/mcp/.

---

What I’ve already built

Here’s the current MCP architecture as implemented (diagram below):

MCP Server core (packages/mcp/lib/src/server/mcp_server.dart)

• Implements JSON-RPC 2.0 handling (requests, responses, notifications, error codes)
• Request routing via McpServer._routeRequest() for:
  initialize, tools/list, tools/call, resources/list, resources/read, ping
• Protocol version: 2024-11-05

Transport layer (packages/mcp/lib/src/transport/)

• HttpTransport: runs on localhost:22140/mcp (current GUI/Dashbot mode)
• StdioTransport: stdin/stdout (useful for CLI + Claude Desktop style integrations)

Tools already exposed (via ToolRegistry)

Tool	Description
list_requests	List saved API requests (supports filter & limit)
get_request	Get full request details by ID
create_request	Create a new request (method, URL, headers, body)
execute_request	Execute/send a request and return response
list_environments	List environment configurations
get_active_environment	Get currently active environment variables

Resources already exposed (via ResourceRegistry)

URI	Description
apidash://requests	Summary of all saved requests
apidash://environments	All environment configurations
apidash://environment/active	Active environment variables
apidash://request/{id}	Dynamic: full details of a specific request

Key design choice: ApiDashDataProvider interface

All tools/resources access API Dash data through an abstract ApiDashDataProvider.
This keeps the MCP layer independent of Flutter/Riverpod and makes it reusable for both GUI and a future headless CLI.

abstract class ApiDashDataProvider {
  Future<List<Map<String, dynamic>>> getAllRequests();
  Future<Map<String, dynamic>?> getRequest(String id);
  Future<Map<String, dynamic>> executeRequest(String id);
  Future<Map<String, dynamic>> createRequest({...});
  Future<List<Map<String, dynamic>>> getEnvironments();
  Future<Map<String, dynamic>?> getActiveEnvironment();
}

How I think this fits into GSoC Idea 6 (my plan)

From my understanding, Idea 6 is specifically aiming for:

1. a proper CLI tool to use API Dash from the terminal, and
2. exposing API Dash as an MCP Server so external AI agents (VS Code / Copilot-style clients, Claude Desktop, other MCP clients) can interact with it.

I created a second architecture diagram to represent this “external clients + CLI + MCP” scope more explicitly. The solid boxes are what I've already built, and the dashed boxes represent the scope of work for GSoC:

1) External MCP clients (VS Code / Claude Desktop / other agents)

• I already have the MCP server core + transports.
• For GSoC scope, I'd focus on polishing and validating the StdioTransport flow so external MCP clients can connect reliably.
• I'd also add practical setup docs + config templates (especially for Claude Desktop and editor-based MCP clients).

2) Building a real CLI (apidash command)

Because MCP tools/resources already use ApiDashDataProvider, a CLI can reuse the same backend logic without duplicating code.

Commands I'm thinking of:

• apidash list
• apidash run <request-id>
• apidash create --method GET --url ...
• apidash env list
• apidash env active
• apidash serve --mcp (start MCP server headlessly)

3) Headless mode + storage access

The big engineering piece is making sure CLI/MCP mode can run without starting the Flutter UI, while still safely accessing the same local storage used by the app (Hive, request collections, environments, etc.).

I plan to split "UI startup" from "core data init", so the headless process can safely read saved requests/environments, execute requests, and expose them via CLI/MCP.

---

Questions for maintainers

To ensure my GSoC proposal aligns with the org's vision for Idea 6, I have a few key questions:

1. Storage access in headless mode: What's your preferred approach for the CLI/MCP server to safely read/write from the same local Hive storage as the GUI app without conflicts? Should we implement a file lock, or use a shared service layer?

2. MCP transport priority: For GSoC, should I prioritize StdioTransport (for Claude Desktop & editor integrations) or HttpTransport (for broader agent compatibility)? Or both equally?

3. CLI scope: Beyond what I've sketched (list, run, create, env), are there specific CLI commands you'd consider essential for Idea 6?

4. Testing expectations: For integration testing with external MCP clients (VS Code, Claude Desktop, Cursor), do you have preferred tools/approaches, or should I define that as part of the proposal?

These answers will help me refine my timeline and deliverables for the proposal. Thanks!

[mshehto]

Agreed. Hybrid definitely seems like the most intuitive choice. I will bring this up in the next meeting and get the maintainers' thoughts!

[animator]

@vik05h you can send project idea doc PR for further review and ask any doubt in our weekly call - https://luma.com/embed/calendar/cal-ZTW02O2EsWRs6V4/events

[vik05h]

@vik05h you can send project idea doc PR for further review and ask any doubt in our weekly call - https://luma.com/embed/calendar/cal-ZTW02O2EsWRs6V4/events

Sir I didn't understood, do you want me to create PR for the above??

[animator]

@vik05h Read - #1048

[animator]

@vik05h Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[mshehto]

---

Research & Initial Thoughts on CLI & MCP Support (Project 6)

Hi everyone! I'm Mohamed Shehto. I attended 2 weekly connects and have been exploring the codebase. Here are my initial thoughts on Project 6.

Research: HTTPie

HTTPie is a widely used open-source command-line HTTP client designed to make API testing more human-friendly than traditional tools like curl. (view repo)

A key observation is that a significant portion of HTTPie’s complexity comes from implementing and maintaining its own HTTP execution layer.

API Dash is in a better position!!!

The repo already provides a mature HTTP execution pipeline via:

sendHttpRequest()

located in:

packages/better_networking/lib/services/http_service.dart

This means that the proposed CLI does not need to solve the hardest infrastructure problems that HTTPie faced. Instead, development can and should focus primarily on:

• command design
• developer experience
• output formatting
• workflow integration

---

What I Think Should Be Built First

Start with the simplest possible useful thing:

apidash list                     # show all saved requests
apidash run "Get Users"         # execute a saved request
apidash collection run "My APIs"  # run all requests in a collection

---

Proposed Architecture

A new package inside the monorepo:

packages/apidash_cli/

Execution flow:

apidash run "Get Users"
        ↓
HiveHandler opens apidash-data.hive   ← existing lib/services/hive_services.dart
        ↓
RequestModel.fromJson()               ← existing apidash_core models
        ↓
sendHttpRequest()                     ← existing better_networking package
        ↓
Print response to terminal

Almost everything already exists the CLI is a thin wiring layer on top.

This is very similar to how HTTPie does it as well!!

---

Shared Data Between CLI, GUI, and MCP

A key design insight: since the CLI reads and writes directly to the same apidash-data.hive file that the GUI uses, all three interfaces stay automatically in sync.

GUI         → creates/saves requests → apidash-data.hive
CLI         → reads/runs requests    → apidash-data.hive
MCP Server  → reads/runs requests    → apidash-data.hive

This means:

• Create a request in the CLI → it shows up in the GUI automatically
• Save a request in the GUI → run it from the CLI immediately
• Claude or any AI agent calls the MCP server → it reads the same collections

---

Tech Stack Recommendation

In the meeting, we discussed splitting the stack for MCP, and I think it's a good idea, as TypeScript for MCP is much more mature

CLI → Dart

So we can directly reuse:

• HiveHandler
• RequestModel
• sendHttpRequest()

without duplicating logic. A TypeScript CLI couldn't share the Hive layer natively.

Tools like melos and mason show Dart CLIs work well in the Flutter ecosystem.

---

MCP Server → TypeScript

Because the official:

@modelcontextprotocol/sdk

is the most mature and widely adopted.

Most MCP servers in production are TypeScript, and:

• VS Code
• Claude Desktop
• Cursor

all have strong TypeScript MCP support.

---

The MCP Angle (Coolest Part)

Based on today's discussion, the primary use cases are:

• developers using the CLI
• AI agents accessing API Dash through the MCP server

This enables powerful workflows.

Claude (or any AI agent) could:

• call list_requests → see all saved collections
• call run_request → execute any saved request
• receive the response and reason about it

A developer could literally say:

"run all my Auth API requests and tell me if any are failing"

…and Claude would do it autonomously using the MCP server.

---

Questions

Should the CLI support creating and managing requests purely from the terminal with no GUI needed, or is the primary CLI use case running requests that were already saved in the GUI?

This affects whether I prioritize:

• apidash create commands
  or
• focusing purely on apidash run and apidash list within the 90-hour scope.

Looking forward to next weeks meeting!!!

[animator]

@mshehto you can send the idea doc PR and in case you have already sent it, you can send a PoC PR.

[animator]

@mshehto Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[saurabhhhcodes]

Hello @animator and the API Dash Team,

I've been following the GSoC 2026 ideas with great interest. After researching the current AI implementation in API Dash and reviewing the 2025 successful proposals (e.g., AI API EVAL by Harsh Panchal), I would like to share a comprehensive vision for a 350-hour project.

As an active contributor with 3 closed PRs and 1 currently in progress, I am committed to evolving API Dash into the central hub for Agentic AI development.

1. The Vision: Unified Agentic Ecosystem

I am proposing to bridge Idea #1 (MCP Testing), Idea #2 (Multimodal Eval), Idea #4 (Agentic Testing), and Idea #6 (CLI Support). This isn't just a set of features; it's a "Modular Intelligence Layer" for the platform.

2. High-Fidelity Research & Architecture

Below is my proposed high-level architecture, keeping API Dash as the orchestration hub:

graph TD
    User([User]) --> Dashbot[Dashbot Agent]
    Dashbot --> Core[apidash_core]
    Dashbot --> MCP[MCP Client/Server]
    MCP --> Target[External API/Tool]
    Core --> CLI[API Dash CLI]
    Core --> GUI[Flutter GUI]
    
    subgraph "Agentic Layer"
        Dashbot
        MCP
    end

Loading

Detailed Internal Flow

To ensure technical feasibility, I've mapped out the internal interactions between the core engine and the new protocol layers:

sequenceDiagram
    participant UA as User/Agent
    participant AP as apidash_core
    participant MCP as MCP Registry
    participant SRV as MCP Server (stdio/SSE)
    
    UA->>AP: Trigger Request/Tool
    AP->>MCP: lookup_tool(id)
    MCP-->>AP: Tool definition (JSON)
    AP->>SRV: call_tool(args)
    SRV-->>AP: Result
    AP-->>UA: Formatted Output

Loading

Key Pillar: MCP Tool Playroom (Idea #1 & #6)

I've designed a dedicated visualizer for the Model Context Protocol. This will allow developers to discover and test MCP tools (stdio/SSE) with real-time schema validation—a "Postman experience" for the AI world.

Note

GUI Mockup: MCP Server Explorer with Tool Playroom and Multimodal results (To be uploaded).

Key Pillar: CLI as an MCP Bridge (Idea #6)

The CLI won't just run requests; it will act as an stdio MCP Server, allowing external agents (like Claude or GitHub Copilot) to use API Dash's core engine to execute collections and generate code.

Note

CLI Mockup: Interactive Terminal Dashboard with real-time request monitoring (To be uploaded).

3. Deep Research & Competitive Advantage

By analyzing past proposals, I've identified three "Winning Edges" for 2026:

1. Shift to Agent Eval: Moving from static metrics (BLEU/ROUGE) to evaluating tool-use accuracy and multi-turn reasoning via MCP.
2. Self-Healing Tests: Building agents in genai that proactively repair test assertions when schemas change.
3. Core-Native Protocol: Implementing the JSON-RPC MCP spec directly in apidash_core for zero-latency communication.

I have a detailed 12-week roadmap and technical documentation ready for review. I am extremely excited to help future-proof API Dash through this 350-hour project!

Best regards,
Saurabh Kumar Bajpai (@saurabhhhcodes)

[animator]

@saurabhhhcodes Focus on one project idea, and go deep.

[animator]

@saurabhhhcodes Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[saurabhhhcodes]

Hi @animator and API Dash Team 👋

Following the discussion and feedback to focus deeply on Project #6 (CLI & MCP Support), I am presenting a complete Proof of Concept (PoC) + Final Proposal Direction that I will be submitting for GSoC 2026.

This proposal is designed to transform API Dash into a:

👉 CLI-first + MCP-enabled + Agent-ready API platform

It is based on:

• Deep codebase research

• Existing discussions in this thread

• MCP Apps exploration

• Practical implementation feasibility

---

🎯 1. Proposal Objective

The goal of this project is to extend API Dash into a multi-interface execution system supporting:

1. CLI for developers & CI/CD workflows

2. MCP Server for AI agents (VS Code, Claude, etc.)

3. MCP Apps for interactive response visualization

---

🧠 2. Language & Architecture Decision (Critical)

🔹 Final Tech Stack

Component | Technology -- | -- CLI | Dart Core Logic | Dart MCP Server | Dart MCP Apps UI | HTML + JavaScript CI/CD | GitHub Actions (YAML)

---

🏗️ 6. CLI PoC Design

📦 Package

packages/apidash_cli/

---

🔹 Commands

apidash list
apidash run <request-id>
apidash collection run <collection>
apidash env list
apidash history
apidash serve --mcp

---

🔹 CLI Execution Flow

sequenceDiagram
participant User
participant CLI
participant Hive
participant Core
participant Network
User->>CLI: run request

CLI->>Hive: load request

CLI->>Core: build model

Core->>Network: send request

Network-->>CLI: response

CLI-->>User: output

---

🔹 PoC Code

void main(List<String> args) async {

switch (args[0]) {

case 'list':

await listRequests();

break;

case 'run':

await runRequest(args[1]);

break;

}

}

Future<void> runRequest(String id) async {

final request = await HiveService.getRequest(id);

final response = await sendHttpRequest(

request.toHttpRequestModel(),

);
print("Status: ${response.statusCode}");

}

---

⚙️ 7. Required Refactoring

Issue

• Flutter dependencies in core packages

Solution

• Convert to pure Dart implementations

Result

👉 Shared core usable by:

• GUI

• CLI

• MCP

---

🔌 8. MCP Server Design

📦 Package

packages/apidash_mcp/

---

🔹 Architecture

flowchart TD

Agent[AI Agent]

Stdio[stdio Transport]
MCP[MCP Server]
Core[apidash_core]

Network[better_networking]

Storage[Hive]
Agent --> Stdio

Stdio --> MCP
MCP --> Core

Core --> Network

Core --> Storage

---

🔹 MCP Tools

• send_request

• list_requests

• get_request

• generate_code

• debug_request

---

🔹 MCP Flow

sequenceDiagram

participant Agent

participant MCP

participant Core

participant Network

Agent->>MCP: execute request

MCP->>Core: build model

Core->>Network: execute

Network-->>MCP: response

MCP-->>Agent: structured output

---

🌟 9. MCP Apps (Key Innovation)

Current

JSON responses only

Proposed

Interactive UI dashboards

---

Flow

sequenceDiagram

participant Agent

participant MCP

participant API

participant UI

Agent->>MCP: execute_request

MCP->>API: run

API-->>MCP: response

MCP->>UI: render UI

UI-->>Agent: dashboard

---

Benefits

• Better debugging

• Structured visualization

• Improved AI reasoning

👉 Positions API Dash as:
“Postman for AI Agents”

---

🔐 10. Security

• Sanitize:

  • Authorization headers

  • API keys

  • Cookies

---

📦 11. Distribution

• Dart compiled CLI binaries

• Optional npm wrapper

---

🚀 12. CI/CD

• GitHub Actions:

  • Build CLI

  • Test MCP

  • Release artifacts

---

🧪 13. Testing Strategy

• Unit testing (CLI + MCP tools)

• Integration testing (CLI ↔ Core ↔ Network)

• MCP agent interaction testing

---

🗺️ 14. Execution Roadmap

Phase 1 → CLI foundation
Phase 2 → Advanced CLI features
Phase 3 → MCP server implementation
Phase 4 → MCP Apps integration
Phase 5 → Testing, optimization, documentation

---

❓ 15. Questions

1. Should stdio be prioritized as the primary MCP transport?

2. Preferred approach for Hive concurrency across CLI + GUI?

3. Is MCP Apps aligned with the long-term vision?

---

📌 16. Final Statement

This proposal presents a complete, scalable, and production-ready architecture to extend API Dash beyond a GUI tool into a:

👉 Developer CLI + AI Agent Platform + Interactive API Intelligence System

This is the direction I will be submitting as my GSoC 2026 proposal.

---

Thank you for your time and guidance 🙌
Saurabh Kumar Bajpai

[Bhavesh-More]

Hi @animator

While researching the CLI and mcp support, I noticed that better_networking currently depends on Flutter in a few places:

kIsWeb in http_client_manager.dart

debugPrint in auth_utils.dart

flutter_web_auth_2 in oauth2_utils.dart

Because of this, the CLI cannot depend on better_networking, as the CLI will be pure Dart.

Would it be acceptable to refactor these Flutter-specific dependencies so that better_networking remains usable by both the Flutter app and the CLI?

I want to confirm this direction before proceeding with the initial idea.

[mshehto]

Great observation! I will mention it in the next meeting.

[pratapsisodiya]

@Bhavesh-More @animator apidash core pkg too Flutter dependency that lead to compilation problem of pure dart logic

[Bhavesh-More]

@praaatap Thanks for pointing this out.

In apidash_core package, Flutter is only used for a single debugPrint. If the maintainers agree with refactoring better_networking to remove Flutter-specific dependencies, I was planning to replace that as well so apidash_core stays compatible with pure Dart.

I was going to mention this in the initial idea draft but wanted to confirm the direction first.

[animator]

@Bhavesh-More yes it can be refactored.

[animator]

@Bhavesh-More Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[armanraymagit]

Hi @animator Sir here is my initial draft for Proof of concept i want to discuss before finalize anything.

API Dash and DashBot MCP Proof of concept

This document outlines the core components and user interface features of the Model Context Protocol (MCP) integration for DashBot and API Dash.

Mono repo here armanraymagit/apidash_mcp

Demo Video

MCP Integration Demo to see the native Dart Implementation for MCP Support and MCP server.

🏗️ Core Architecture

The system follows the standard MCP triad to ensure seamless communication between AI models and external data sources.

Component	Description
MCP Host	DashBot – This where the LLM Models can Interact with the MCP Clients and MCP Servers.
MCP Client	The management layer that handles connections and configuration settings between the AI and the servers.
MCP Server	The storage and execution layer where specific Tools, Resources, and Prompts are stored.

🛠️ System Components

1. MCP Inspector (The Manager)

The MCP Inspector acts as the central command center for all connected capabilities.

• Management: Add or remove MCP Servers, Tools, and Resources.
• Control: Includes an ON/OFF Button for each MCP Server and individual Tools to maintain granular control over model access.

2. External Server Configuration

This section allows for the manual management of server connections to DashBot.

• Connectivity: Add or remove servers via http or stdio.
• Flexibility: Easily scale the AI's capabilities by bridging to external environments.

3. Resource & Tool Management

Centralized interface to manage the specific assets the AI can utilize.

• Resources: Data sources or documents the AI can read.
• Tools: Functions or actions the AI can perform.

⌨️ Interaction & Commands

Interaction with the MCP layer is handled through a slash-command interface within the chat.

• / Commands: Trigger any connected tool or resource directly.
• System Commands: Use commands like /mcp list to view active configurations and statuses.

🚀 Workflow Summary

1. Connect: Add an external server via stdio or http.
2. Inspect: Toggle specific tools or servers ON in the MCP Inspector.
3. Execute: Use the / command in DashBot to call tools and resources into your workflow.

🛠️ Implementation Plan: API Dash MCP Integration

Building a high-performance Model Context Protocol (MCP) Host within API Dash. This implementation leverages the mcp_dart 2.1.0 package to create a production-ready system for managing AI tools and resources.

🏗️ 1. Top-Down Architectural Breakdown

Following a Top-Down approach, deconstructing the MCP specification into manageable layers to ensure a modular and scalable system.

🔵 Layer 1: The UI & Application State (Flutter/Dart)

• MCP Inspector: A centralized dashboard for users to monitor server health, toggle tools, and manage configurations.
• State Management: Utilizing a reactive pattern (Provider/Riverpod) to track the real-time status of McpClient instances.
• Slash Command Engine: A UI overlay within the API Dash chat/request interface that maps / commands to underlying MCP tool calls.

🟡 Layer 2: The Logic Engine (mcp_dart & json_rpc_2)

• Protocol Orchestration: Managing the lifecycle of the McpClient.
• JSON-RPC 2.0 Routing: Implementing the standard messaging format for requests, responses, and notifications between API Dash and external servers.
• Resource Mapping: Parsing data from MCP Resources and converting it into structured views (JSON, Markdown, or Plain Text) for the API Dash response viewer.

🟢 Layer 3: Transport & Execution

• stdio Transport: Managing local child processes. This allows API Dash to launch and communicate with local Python, Node.js, or Go-based MCP servers.
• SSE/HTTP Transport: Enabling connections to remote MCP endpoints over the web.

🚀 2. Why mcp_dart for API Dash? (Developer Experience)

While an official TypeScript SDK exists, choosing mcp_dart provides a superior experience for both developers and end-users within the Flutter ecosystem:

Feature	mcp_dart (Native)	TypeScript (Node.js)
Distribution	Compiles to a single, self-contained binary.	Requires Node.js runtime and node_modules on the user's machine.
Performance	AOT (Ahead-of-Time) compilation for zero-latency execution.	JIT execution; higher memory and CPU overhead.
DX (Debug Mode)	Can run in single command debug protocol logic via flutter run [platform].	Requires npm run dev / build and Flutter run [platform].
Portability	Perfect for desktop/mobile apps where a small footprint is critical.	High "dependency hell" risk for non-web environments.

🧪 3. Quality Assurance & Refactoring

To ensure the code is GSoC-ready and stable for production, we will transition from "vibe-coded" prototypes to a hardened architecture through:

1. Unit Testing: Validating individual logic blocks, such as JSON-RPC serialization and MCP capability negotiation, using the test .
2. Integration Testing: Using flutter test to simulate the full user flow:
   • User types /fetch_data → UI triggers MCP Tool → Server returns JSON → UI renders response.
3. Refactoring: Applying SOLID principles to ensure the MCP client logic is decoupled from the UI, making it easy to maintain and extend in future versions of API Dash.

🌐 4. Unlocking the Ecosystem

Implementing this component transforms API Dash into a Centralized AI Hub. It allows for seamless connectivity with:

• Gemini CLI: Use local AI models to automate API testing or data extraction.
• VS Code Integration: Sync context between IDE and API testing environment.
• External AI Tools: Instantly support any tool built for Claude, ChatGPT, or other MCP-compliant platforms.

[animator]

@armanraymagit Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[VanshKaushal]

Hi everyone, @animator 👋

I spent some time thinking about how a CLI interface for API Dash and MCP server integration could be designed, and I wanted to share a few ideas.

The main goal seems to be making API Dash usable directly from the terminal while also allowing it to integrate with AI agent environments through MCP (Model Context Protocol). This would make API Dash useful not only as a GUI application but also as a developer-friendly automation tool.

One approach would be to design a lightweight CLI wrapper around the core API Dash functionality. Since API Dash is built with Dart/Flutter, the CLI could be implemented using Dart so it can reuse the same request models, collections, and API handling logic already present in the codebase.

The CLI could expose commands that mirror the main capabilities of API Dash. For example, users could run commands to send API requests, run saved collections, test endpoints, or inspect responses directly from the terminal. A possible command structure might look like:

apidash request send --method GET --url https://api.example.com/users
apidash collection run users_collection
apidash env list
apidash history show

This would allow developers to use API Dash in scripts, CI pipelines, and automation workflows, similar to tools like curl or Postman CLI.

For the second part of the project, exposing API Dash as an MCP server could make it accessible to AI agents and development environments that support MCP. In this setup, API Dash would act as a tool provider that agents can call when they need to perform API requests or inspect endpoints.

The MCP server could expose capabilities such as:

• Sending API requests
• Running saved API collections
• Fetching request/response history
• Listing environments and variables
• Returning structured API responses

This would allow agent tools in environments like VS Code or other AI-assisted IDEs to call API Dash programmatically.

A possible architecture could include a CLI layer, an API Dash core logic layer, and an MCP adapter layer. The CLI would translate terminal commands into calls to the API Dash core. The MCP adapter would expose similar capabilities through the MCP protocol so that external agents can interact with it.

A typical workflow might look like this: a developer runs a command in the terminal to test an API endpoint, the CLI sends the request using API Dash’s internal request engine, and the response is displayed in a formatted output. Alternatively, an AI agent could call the MCP interface to trigger the same request automatically.

Some potential enhancements could include support for environment variables, collection execution, response formatting, and CI-friendly output modes. Over time, the CLI could also support features like automated API testing or scripting workflows.

I would be interested in starting with a minimal CLI prototype that can send API requests using API Dash’s core logic, and then extending it with additional commands and MCP server support.

Looking forward to feedback and suggestions on this approach.

[animator]

@VanshKaushal Go through this resource and see if MCP Apps can be leveraged in any way in this project.

[AshutoshSharma-pixel]

Hi @animator and @ashitaprasad, I've gone through Ashita's article on MCP Apps carefully. I see a compelling angle for Project 6: beyond just returning plain text from the MCP server, API Dash could leverage MCP Apps to render rich interactive response UIs directly inside hosts like VS Code and Claude Desktop. So when an agent calls execute_request, it gets back a sandboxed HTML dashboard showing the response status, headers, and body, rather than raw JSON. I'm exploring this direction for my idea doc. Would love to know if this aligns with what you had in mind.

[animator]

@AshutoshSharma-pixel Please follow the application guide and send proposal doc PR for your proposed solution.

[animator]

@AshutoshSharma-pixel go through this resource to study if MCP Apps can be served via API Dash MCP server.

[Manar-Elhabbal7]

Hello , Are there somethings were said as preferred in this project in the previous meetings? this will help me to consider them in my plan to implement it . Thanks a lot

[animator]

@Manar-Elhabbal7 go through this resource to study if MCP Apps can be served via API Dash MCP server.

[farheenimam]

Hi @animator ,

I’m planning to work on the CLI and MCP server integration for API Dash, and I wanted to clarify a few points so I can align my implementation with project expectations.

1. MCP Server Scope

• Should we implement a full MCP integration for specific Agents like VS Code and AI Apps, or is it enough to make API Dash MCP-compliant and let Agents connect later?
• Are there preferred message formats or protocols we should follow for MCP requests? JSON only, or other formats too?

2. CLI Features

• Which core API Dash functionalities must be exposed in the CLI? For example:

  • Sending GET/POST requests
  • Handling headers/authentication
  • Displaying JSON, images, audio, PDF

• How should CLI handle file responses (images, audio, PDFs) that can’t be rendered in a terminal? Save to a local folder, display metadata, or something else?

• Should the CLI support real-time monitoring, like testing multiple APIs continuously?

3. Authorization / API Key

• What’s the recommended way to store/manage API keys in the CLI?
• Should the CLI reuse API keys set from the GUI, or maintain a separate configuration?

4. Async / Real-Time Behavior

• Should commands wait for a response synchronously, or support async operations like streaming responses?

5. CLI Design Preferences

• Any preferred argument parsing style (e.g., --endpoint, --header) or output format?
• Should the CLI provide interactive mode, or only command-line flags?

6. Contribution Guidelines

• Are there existing CLI/MCP patterns in the codebase we should follow?
• Any specific Dart or Flutter libraries recommended for CLI or MCP server implementation?

[animator]

@farheenimam go through this resource to study if MCP Apps can be served via API Dash MCP server.

[Vishnu-tppr]

Hi @animator I've been reading through the codebase while preparing my GSoC 2026 proposal for this idea.

I noticed that the networking layer was moved out of apidash_core ~9 months ago and now lives in packages/better_networking/lib/services/. My plan for the CLI is to build packages/apidash_cli/ as a pure-Dart package (no Flutter runtime) that imports better_networking and apidash_core/import_export/ directly so the CLI works in any CI environment where only the Dart SDK is installed, with no GUI dependency.

Two questions before I finalize the design:

1. For the apidash run command, should the CLI read collections from exported HAR files (which import_export/ already supports), or is there a plan to support reading directly from the Hive database path?
2. For the MCP server layer, is package:shelf acceptable, or does the team prefer a different HTTP server package?

I've drafted the full architecture and 12-week timeline happy to share the proposal doc for early feedback.

[animator]

@Vishnu-tppr go through this resource to study if MCP Apps can be served via API Dash MCP server.

[Devaprakash47]

Hi @animator,

I've built a working prototype for Project #6 (CLI & MCP Support).

What I've Built:

• CLI tool with request, run, and codegen commands
• MCP server with stdio transport (JSON-RPC 2.0)
• VS Code integration via .vscode/mcp.json
• All built in pure Dart, sharing apidash_core logic

Architecture:

apidash_core/   → Shared HTTP engine + models
apidash_cli/    → Terminal commands (no Flutter deps)
apidash_mcp/    → MCP server exposing 3 tools

MCP Apps Integration:
After reading @ashitaprasad's article, I see we can return rich HTML dashboards instead of plain JSON when agents call send_request. This makes API Dash "Postman for AI Agents."

Prototype: https://github.com/Devaprakash47/apidash-cli-mcp-prototype.git

Questions:

1. Should MCP Apps (HTML responses) be prioritized in the initial implementation?
2. For CLI storage: read directly from Hive, or use exported HAR/JSON files?
3. Should I refactor better_networking to remove Flutter deps as part of this project?

Looking forward to feedback!

[animator]

@Devaprakash47 go through this resource to study if MCP Apps can be served via API Dash MCP server.

[saurabhhhcodes]

Hi @animator and the API Dash team! 👋

I'm Saurabh Kumar Bajpai, a final-year B.Tech Biotechnology student at Amity University and an AI Engineer Intern at Akoode Technologies. I have formally submitted my GSoC 2026 proposal for Project Idea #6 — CLI & MCP Server.

🎯 Proposal Summary

My proposal introduces two major architectural additions:

1. apidash_cli — A pure Dart headless CLI supporting apidash run, apidash list, and apidash collection run --ci, with strict POSIX exit-code mappings for GitHub Actions integration.
2. apidash_mcp — A full JSON-RPC 2.0 MCP server over stdio, exposing API Dash's workspaces, environments, and request execution as tools/resources consumable by Claude Desktop, Cursor, and any MCP-compatible AI agent.
3. MCP Apps — Rich interactive HTML/JS response panels rendered natively inside Claude Desktop.

🔗 My Contributions

• PR perf(dashbot): improve reasoning trace for API debugging #1095: feat: LangGraph-based Agentic API Debugger with Reasoning Trace — Demonstrates my deep familiarity with the API Dash codebase, agentic workflows, and reasoning trace visualization.

🛠️ Tech Stack

Dart · package:args · JSON-RPC 2.0 · stdio · Hive · MCP Protocol · GitHub Actions

I would love any feedback on the architectural decoupling strategy, particularly around the Hive advisory file-locking mechanism. Happy to jump on a call or answer questions here!

Thank you for the amazing project 🙏

[animator]

@saurabhhhcodes go through this resource to study if MCP Apps can be served via API Dash MCP server.

[Vishnu-tppr]

Hi @animator — I've submitted 3 PRs as part of my GSoC Idea #6 research:
PR 1: #1670 — Removes Flutter deps from better_networking (pure-Dart CLI blocker fix, raised by @Bhavesh-More)
PR 2: #1671 — Fixes silent data corruption in map key assignment + unsafe BuildContext usage
PR 3: #1672 — Global error handlers + stricter lint rules
Also reviewed the MCP resource you shared. MCP Apps can be surfaced through the tool layer — each App registers as a named tool with its own input schema, mapping cleanly to a packages/apidash_mcp/tools/ structure. I have direct hands-on experience with this architecture from my own project (Axoltl). Happy to discuss further.