MCPs not working properly

[arthurandrade]

Has anyone facing the same issue?

Basically we created a MCP to use OpenMetadata functionalities. It works fine on AI Playground, and it works fine on Databricks Genie (previously, Databricks One). But when I try to add this MCP on Genie Code, it fails with a generic message:

"External MCP: ... could not be added. Please see the documentation for more information and try again later."

The second issue is: our MCP Jira is not working properly. It works fine, with WRITE capabilities on Genie Code. But when I try to use on Databricks Genie, it fails saying that it doesn't contains WRITE capabilities (but it contains and it's working).

Anyone facing similar issues?

[Louis_Frolio]

Hello @arthurandrade , I looked into this and here is what If found:

These are really two separate problems, and the thing that untangles them is realizing that AI Playground, Chat in Genie (what used to sit under Databricks One), and Genie Code are three different surfaces with three different MCP capability models. The same server can behave differently in each, so it helps to reason about them one at a time.

One clue from your setup points the way. Your Jira MCP adds fine in Genie Code, but OpenMetadata doesn't. That tells me Genie Code's MCP plumbing works for you in general, so the add failure is almost certainly specific to the OpenMetadata server, not a blanket Genie Code config problem.

First issue: OpenMetadata won't add in Genie Code. I'd check these roughly in order.

1. Agent mode. MCP servers are only supported in Genie Code Agent mode, not chat. Adding from chat mode will fail.
2. The 20 tool cap. Genie Code caps MCP at 20 tools across all servers combined. If OpenMetadata exposes a big tool surface and your other servers (Jira included) already use slots, the add can fail. Disable other tools first, then add OpenMetadata and selectively enable what you need.
3. "Try again later" usually means a transient tool-listing failure. The managed proxy probably couldn't enumerate tools at that moment (an upstream 5xx, a slow handshake, a token that isn't valid yet). Retry first. If it sticks around, check AI Gateway, then MCPs, and look at the Unity AI Gateway usage dashboard under the External MCP Server tab for 5xx or error rates on that connection.
4. Re-authenticate the exact UC connection and re-add. The docs are explicit that you have to log in to the connection before it can be used.
5. Transport has to be Streamable HTTP. SSE is not supported. Confirm the UC HTTP connection points at the Streamable HTTP /mcp endpoint and that "Is mcp connection" is checked.
6. If OpenMetadata is hosted as a custom Databricks App MCP, verify a few things: it's in the same workspace, it's exposed at exactly https://<server-url>/mcp, it runs stateless (mcp_server.http_app(stateless_http=True)), and your workspace URL is in the CORS allowlist if you're seeing CORS errors.
7. Validate the tool schemas, for example with the MCP Inspector. If any OpenMetadata tool has a malformed or unsupported input schema, the "acquire tool definitions" step fails for the whole server and you get a generic add error.
8. Region. External MCP only works where Model Serving is supported. Since Jira works for you, region is probably fine, but I'd still rule it out.

For fast triage, point a UC connection at OpenMetadata and test it in AI Playground (you said it works there) against Genie Code with all other tools disabled. If Playground works but Genie Code still rejects it, you're most likely looking at the schema validation or transport path. At that point, open a support ticket with the connection name and a timestamp so they can pull the proxy logs.

Second issue: Jira writes work in Genie Code, but Databricks Genie says "no WRITE capabilities." Here I want to be honest about my confidence.

What the docs support is that the Genie surface is read oriented by design. Chat in Genie's external MCP and connector story is framed around searching documents to answer questions, and the managed Genie and Genie Space MCP servers are documented as read-only (Genie's generated SQL is always read-only). So write-capable external MCP actions in Chat in Genie may simply be unsupported, or supported inconsistently, today. The "no WRITE capabilities" message most likely reflects a Genie-side limitation, not your MCP lacking write.

A few things to try and check. First, confirm reads work in Genie chat with a read-only Jira tool. If reads succeed but writes fail, that points hard at a Genie limitation or bug rather than your server. Second, annotate your write tools explicitly in the Jira MCP: set readOnlyHint to false, and destructiveHint to true where it applies. Clients treat absent annotations differently, so Genie Code may invoke regardless while Chat in Genie inspects the advertised capability. It's a cheap experiment, though it may not override a hard Genie restriction. Third, verify your OAuth scopes if any path uses the managed Atlassian connection. Its default scopes are read-only (read:jira-work, read:jira-user, read:confluence-content.all, offline_access) with no write:jira-work. Since you built your own MCP, double-check which credential and scope the Genie surface actually presents.

Here's my honest "I don't know." I couldn't find documentation that clearly confirms Chat in Genie supports arbitrary write-capable MCP actions today, so I can't promise the annotation fix will make writes work there. If reads succeed but writes don't after the checks above, treat it as a likely product limitation and file a support ticket.

The practical takeaway: use Genie Code in Agent mode for any tool or action workflow that needs write behavior, and treat Genie and Chat in Genie as primarily read, search, and answer oriented until Databricks documents write support more clearly.

Regards, Louis.

Sources used in my research:

1. Connect Genie Code to MCP servers (Microsoft Learn): https://learn.microsoft.com/azure/databricks/genie-code/mcp and AWS: https://docs.databricks.com/aws/en/genie-code/mcp
2. Install an external MCP server (Microsoft Learn): https://learn.microsoft.com/en-us/azure/databricks/generative-ai/mcp/external-mcp
3. Use Databricks managed MCP servers, Genie and Genie Space are read-only: https://docs.databricks.com/aws/en/generative-ai/mcp/managed-mcp
4. Chat in Genie (Databricks on AWS): https://docs.databricks.com/aws/en/genie-ui/genie-chat
5. Community, getting error while trying to use external MCP: https://community.databricks.com/t5/generative-ai/getting-error-while-trying-to-use-external-mcp/td-...
6. MCP spec, tool annotations and Streamable HTTP transport: https://modelcontextprotocol.io/introduction

[arthurandrade]

Hi Louis.

Thank you for your time and your response in here.

Let me address that, step by step.

First issue: OpenMetadata won't add in Genie Code. I'd check these roughly in order.

1. Agent mode also fails. I tried it.
2. It won't allow me to select the tools. It works with other MCPs, not with Open Metadata. I tried it.
3. Most part of the response is 200, other responses are 405. No error message in the dashboard,
4. The MCP uses Bearer Token. There's no login on it.
5. It is.
6. It's not a custom Databricks App MCP.
7. Will try using that. I found MCP Inspector really complex, but I will give a try on it.

Yeah, I have a ticket opened for that case. It works fine on AI Playground and on Genie, but not on Genie Code.

Second issue: Jira writes work in Genie Code, but Databricks Genie says "no WRITE capabilities."

Yeah, this is a limitation on Genie. Using Genie Code to perform actions is good, for coding, but it requires manual interaction, that only makes sense for coding. What I expect from an agent: autonomy and capacity of effectively do things, for example: flag a ticket, add a comment based on daily analysis, etc.

The agent is not doing that. It's just reading, and retrieving JIRA tickets is something easy that I can do, I don't need an agent to do that for me. 

Already confirmed with Databricks support team. Genie can't perform actions, while Genie Code can. Weird, but I hope you guys can solve this in the next DAIS.

Thanks for your time and attention, Louis!