We recently held a webinar on MCP and demonstrated how it would work with our platform and AI to create powerful integrations. We had several questions from that session, some of which we couldn't answer during the webinar.
Here is a slightly cleaned-up transcript of the Q&A, including those additional questions. Answers are provided by webinar hosts Justin Hipple and Jake Hagle.
Question: Does MCP log the questions and responses like a universal chat across all of the generative AI apps on my app platform?
Answer: The way this works is that you're building up a context window. As those interactions flow back and forth, they build up an overall context window.
One of the things that's a really common pattern that we're seeing emerge with MCP is having it tied to sessions so that that whole context can be reloaded. You can review it, especially as you're trying to dial in prompts that might be interfacing with these tools or seeing how maybe customers have used it and gotten poor responses.
So it is a combination of providing the right context by pulling the data, but then still using the prompt engineering best practices to ensure that it's using that data in an effective and repeatable way.
Question: Do I have to be a dev to create automations using MCP?
Answer: Absolutely not, especially if you're going to lean on things like using Prismatic integrations. The idea with those is that non-devs can build out these workflows. If you were to lean on a tool like this, you should be able to expose those via MCP and leverage the full benefit of the systems that you're wrapping up in these flows.
Question: Even with that approach, given the non-probabilistic nature of LLMs, how do we ensure accuracy when polling data across multiple apps?
Answer: In the places where any amount of non-determinism is going to be problematic, those are exactly the things you should still abstract into deterministic workflows. In this case, it may mean a script or workflow which handles the specific acts of polling, but then the results are handed off to an LLM to inspect them and decide how to proceed using MCP or other capabilities.
Question: Is it useful for AI x AI integrations?
Answer: Absolutely. Chaining AI-enabled tooling is becoming more common.
Question: I'm curious if you have seen any particular domain or use case category really draw value out of flows, and in general, building encapsulation on top of existing foundational models?
Answer: It's still pretty early days as far as having MCP in production. We've seen it become useful for generating content, including code, but I haven't personally seen the "killer app" for MCP yet.
Question: How can we handle multi-tenancy with MCP? Do we need to run a separate MCP server for each of the tenants? I am playing around with GitHub MCP server, and it takes user credentials when the MCP server starts, but not when each tool is called.
Answer: Usually, you're tied to some kind of user session, so it will come back to whatever tenant that user session is associated with. That's going to be the data you will have access to. There are probably other ways to do it. I suppose there are lots of ways to do tenancy, after all. But that has been my experience with it thus far.
If we think about it from a Prismatic perspective, really being able to encapsulate those integrations in a customer-by-customer instance where they set up their credentials, and then your LLM can use that customer's primary identifier as that session begins with that AI-enabled application. You can keep that multi-tenancy approach, keep your integrations separate, keep your users interfacing with that MCP server with their tokens and everything (including that unique identifier) to apply your multi-tenancy approach.
Question: All these public MCP servers require credentials to be set up at deployment time. If I have 100 customers needing one specific MCP server connected to their resources – let's say Gitlab or GitHub or Jira – most of these public libraries require credentials at setup, not at runtime. How can I use one deployment and pass in credentials at runtime?
Answer: This is where Prismatic's connection management really helps. Your customers set up their GitHub/Jira/GitLab connection once in Prismatic, and that's it. The MCP server doesn't need any credentials; it just proxies requests to your Prismatic integrations, which already have access to those connections. So when one of your customers uses an LLM to make a tool call through MCP, it's hitting your Prismatic integration, which uses your customer's existing connection. You deploy one MCP server that routes to your integrations, and Prismatic handles all the credential injection based on which customer is making the request. No need for 100 separate deployments. Customers manage their own connections through the embedded Prismatic marketplace UI, and everything just works at runtime. It's way cleaner than trying to solve multi-tenancy at the MCP server level.
For the full context of this Q&A, check out our on-demand MCP webinar. To see how Prismatic and MCP can enhance your integration strategy, schedule a demo.
