Mcp integration

[afsalthaj]

Fixes #2792
Fixes #2793
Fixes #2837 (I had to do this straight away, to ensure whatever I did in the backend to make mcp part of the plan etc works).

Also merged tool schema mapping into this: #2847. This is simple tool schema mapping and value mapping (value mapping is almost noop - we just use existing value_and_type.to_json_value) under the hood, to avoid any duplicate/vunmaintainable logic. JSON schema mapping will adhere to whatever golem_wasm code does in terms of converting a json value to/from ValueAndType. Also note that text/binary/multimodal will be done once I am done with resource ticket

Bootstrapping MCP server, the flattened version as documented.

And the whole thing works with prominent AIs such as : https://platform.openai.com/chat/edit?models=gpt-4.1-mini

Testing with Open AI

A new golem rust app with the following in golem.yaml

mcp:
  deployments:
    local:
       # public simply forwarding to local mcp server 
      - domain: shoot-vincent-attached-med.trycloudflare.com
        agents:
          counter-agent: {}

• golem deploy

The name of the tool is a bit odd, bu I will be fixing it as part of cleaning things up. The above screenshot successfully handshaked with Golem and listed tools

User experience using MCP Server

The actual usage looks very reasonable. The fact that constructor parameters being part of the tool itself seems to be very reasonable as well as flexible.

For example see this specific situation. Here name is a constructor argument

Here I just prompted to increment by 10, but forgot to mention which counter (the value of the constructor param) and client tell us the user to give more details.

Statefulness

The statefulness is about being able to hit the same identity of the agent, that's it.

The agent that was used:

use golem_rust::{agent_definition, agent_implementation, endpoint};

#[agent_definition]
pub trait CounterAgent {
    fn new(name: String) -> Self;

    fn increment_by(&mut self, num: u32) -> u32;
}

struct CounterImpl {
    _name: String,
    count: u32,
}

#[agent_implementation]
impl CounterAgent for CounterImpl {
    fn increment_by(&mut self, num: u32) -> u32 {
        self.count += 1;
        self.count
    }
}

Input Schema and Output Schema and different AI behaviours.

Note that in OpenAI, I couldn't see it really considering output-schema. It did care about input-schema, and I could actually see the final response (json value). This questions whether our output schema works. This may or may not be our problem, and the only way to test this manually doing a handshaking following MCP protocol and see if the response schema is detailed. And for us it works.

See this #2833 (comment)

[afsalthaj]

@mschuwalow #2864

[mschuwalow]

I would like to see

• some integration tests for the crud apis (i.e. in integration-tests/tests/api/*)
• caching in the worker service (as discussed this can happen in follow-ups)

Otherwise, good to go from my side

[mschuwalow]

Suggested change

	pub mcp_capability_lookup: Arc<dyn McpCapabilityLookup + Sync + Send + 'static>,
	pub mcp_capability_lookup: Arc<dyn McpCapabilityLookup>,

McpCapabilityLookup already requires Send + Sync and trait objects are 'static by default