Can I Directly Access the Tool in Google Meet MCP Rather Than Using the Pipedream MCP Server?

1

This topic was automatically generated from Slack. You can find the original thread here.

I tried to use the Google Meet MCP, and from what I understand, we are sending the request through the Pipedream MCP server to another LLM that has the actual tool to execute the given task. I would like to have direct access to the tool itself so my LLM can call it directly. Can I do that, or it isn’t supported yet?

image.png
image.png1332×538 41.1 KB

2

The Pipedream MCP server executes the task using Pipedream’s resources, not an LLM. What do you mean you want direct access to the tool so your LLM can call it directly?

3

If you’re looking to deploy your own MCP server, then you need the Connect plan

4

Also check the docs: GitHub

5

As shown in the screenshot, we’re currently sending an "instruction"—which means the query gets routed to Pipedream. Pipedream uses an LLM layer to interpret the instruction and decide what parameters to pass to the actual tool. However, what we want instead is to call the actual tool on the remote MCP server directly, with explicit parameters like "date", "time", etc., rather than relying on an intermediate instruction-based layer.

6

Ah gotcha, yeah you’re right. I think you’ll need to host your own MCP server

7

Where can I find the instructions or docs for that?

8

And will it also work if I use the local stdio version of the mcp server (pipedream/modelcontextprotocol at master · PipedreamHQ/pipedream · GitHub) mentioned here.

9

The docs are in GitHub, and example at pipedream/modelcontextprotocol at master · PipedreamHQ/pipedream · GitHub

10

You should be able to run everything in development mode if you’re not on the Connect plan, but will need to subscribe to move to production

11

Yea you’re exactly right — we’re experimenting with this approach right now and it seems to perform a bit better in our testing, but I agree that you lose some observability by abstracting the actual tool calls away from the client.

12

What’s your core use case, as you using these as an individual consumer in Cursor etc, or are you considering adding these to an agent or AI app?

13

We’re building a general-use case agent and would love to have MCP integrations. Ideally, we’d be able to install an MCP from Pipedream, connect it, provide auth, and boom—it’s added to the agent. Simple and seamless.

Why I’m not a fan of the current setup: I don’t want to pay for AI credits again when I’m already paying for them on my own agent. I need a very lean flow—something like a remotely hosted MCP for a specific API (e.g., Gmail), with per-user/per-app auth management. Totally doable with the system you already have.
I don’t need 50 other things bundled in. Just something lightweight and affordable for the use case I’m working on. Would love to explore this if it’s possible.

Hope this gives some clarity.

14

Totally — check out the reference implementation: pipedream/modelcontextprotocol at master · PipedreamHQ/pipedream · GitHub. That model shows you how your LLM can call all the individual tools yourself instead of using the approach that our hosted servers at mcp.pipedream.com are currently taking.

15

You can also check out the demo app at chat.pipedream.com to see the implementation I’m talking about

16

@U05FUC30Q01 I’ve been experimenting with the generic MCP server mentioned in the GitHub README, and I have a few questions:

  1. Currently, there’s no authentication solution in the Pipedream MCP server. What’s the recommended way to handle that?
  2. How can I list integration apps in my own app, similar to how they’re listed here: https://mcp.pipedream.com/?
  3. Do you offer a white-label solution — for example, can the OAuth screen show our app’s name instead of “Pipedream”?
17
  1. That’s correct, the assumption is that your customers will be signed in to your application when interacting with Pipedream’s MCP server. Does that make sense? Is there an implementation you’d ideally like to see here?
  2. Check out the /apps API here: GitHub
  3. Yes, check out how to configure your own OAuth clients in Connect here: GitHub
18

We’re seriously considering Pipedream, and it’s currently one of our top choices alongside another option our team has looked into called Smithery. We really like what Pipedream offers — it’s a strong fit for our use case — but the pricing is the only major blocker for us at the moment.

Would it be possible to explore a custom pricing option? We don’t require workflows, AI credits, or many of the other features in the connect plan. Our needs are quite focused: we only need Connect API MCPs and auth management for the users of those apps.

We’d love to make this work if there’s flexibility here. Looking forward to hearing your thoughts.

19

Regarding Authentication:
You’re right that we’ll have our own authentication in place. However, the current assumption is that the MCP server endpoint remains completely hidden and never exposed publicly. The concern is that if the endpoint were to be leaked — intentionally or otherwise — it would become an open playground, allowing anyone to access and interact with the MCP without restriction. That’s a security risk we’re keen to address proactively.

20

Feel free to fill out the form on our pricing page to contact our sales team to discuss custom pricing, but FYI that Connect plan is a new plan that we recently added, which is a dramatic price reduction compared to the previous Connect pricing (prior to this it was only available on the Business tier), so I actually don’t think there’s going to be much wiggle room there.