Feature Request: Add MCP Client Support to Connect External MCP Data Sources

[faisal-fida]

Currently, bagofwords connects to standard data warehouses (Snowflake, BigQuery, Postgres) and services via specific, built-in integrations. While this covers major databases, users often need to analyze data from a wider variety of sources (e.g., Google Drive, Slack, local filesystems, or custom internal APIs) that do not yet have native connectors in bagofwords.

Building and maintaining individual integrations for every possible SaaS or database is resource-intensive. However, many of these sources already offer Model Context Protocol (MCP) servers.

Describe the solution you'd like

I would like to request that bagofwords implement MCP Client capabilities (in addition to its existing MCP Server support).

This would allow users to register external MCP servers as "Data Sources" within bagofwords. Once connected, the agentic analyst could query these MCP servers to fetch context, read resources, or call tools to retrieve data for analysis, just as it currently does with SQL databases.

Proposed Workflow:

1. In the "Data Sources" settings, add a new option: "Connect MCP Server".
2. User provides the configuration (e.g., command to run the stdio server, or SSE endpoint).
3. bagofwords connects to the MCP server and discovers its available Resources and Tools.
4. The AI Analyst can now utilize these tools/resources to answer user queries (e.g., "Summarize the Q3 report from the Google Drive MCP source").

Describe alternatives you've considered

• Manual Ingestion: Manually exporting data from these sources to CSV/SQL and uploading it to bagofwords. This is slow and static.
• Building Custom Connectors: Requesting specific native integrations for every tool (Salesforce, Jira, etc.), which is not scalable for the maintainers.

Additional context

The modelcontextprotocol.io is rapidly becoming the standard for exposing data to LLMs. By acting as an MCP Client, bagofwords would instantly gain access to the entire ecosystem of existing MCP servers without needing to write custom adapters for each one.

Example Use Cases:

• Connecting a Postgres MCP for a database type not yet natively supported.
• Connecting a Filesystem MCP to analyze local logs or config files.
• Connecting a Git/GitHub MCP to analyze code churn alongside Jira tickets.

[yochze]

Thanks @faisal-fida for requesting. This is wip -- the overall design is very similar to current integrations flow. There are two requirements for BOW to work with 3rd party integrations.

1. get tables: we need to see what are the tables(or resources) that can be queried
2. execute_query: being able to run code across those tables

So the flow would be user will provide the MCP connection -> tools will be discovered -> user will map bow-get_tables to the mcp-get_tables and bow-execute_query to mcp-execute_query

Does that make sense? Would it fit the MCPs you're looking to use?

[faisal-fida]

@yochze Thanks for the response, but I think there is a slight misunderstanding of my request.

To be clear: I am not looking to expose bagofwords as a server to other clients, nor am I looking to connect to "Database MCPs" that have tables and rows.

The Goal:
I want bagofwords to act as an MCP Client (Host) that can connect to standard, off-the-shelf MCP Servers. Exactly like how Claude Desktop connects to the ecosystem of existing integrations (e.g., AWS, Stripe, ActiveCampaign, Jira, etc.).

The Problem with the Proposed Design:
You mentioned a workflow where the user maps bow-get_tables → mcp-get_tables.
This will not work for the vast majority of existing MCP connectors because they do not have tables.

• Example: The Stripe MCP does not have a "table" of customers. It has a Tool called search_customers.
• Example: The AWS MCP does not accept SQL queries. It has a Tool called list_ec2_instances.

What I Need:
I need bagofwords to support generic Tool Usage, not just Table Querying.

1. Connect: User connects an MCP Server (e.g., the AWS connector).
2. Discovery: bagofwords lists the available Tools (not tables).
3. Execution: The Agent decides to call a Tool (e.g., aws_list_buckets) to get data, rather than trying to run a SQL query against a non-existent table.

If you enforce a get_tables / execute_query requirement, bagofwords will be incompatible with the entire existing MCP ecosystem. I hope you understand my point?