[jira] [Commented] (CAMEL-24394) camel-mcp-server: should add support for MCP resources

["Karol Krawczyk (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-24394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105113#comment-18105113 ] 

Karol Krawczyk commented on CAMEL-24394:
----------------------------------------

h3. Context

I looked into this before picking it up. The premise holds for
{{components/camel-ai/camel-mcp-server}}: {{VertxMcpServerEngine}} advertises
{{ServerCapabilities.builder().tools(true)}} only, and the {{McpServerEngine}} SPI has just
{{toolAdded}}/{{toolRemoved}}. Worth noting for anyone reading this later: the *other* MCP
server in the tree — {{dsl/camel-jbang/camel-jbang-mcp}}, the dev-time Quarkus one — already
ships resources and prompts ({{SecurityResources}}, {{MigrationResources}},
{{DependencyResources}}, {{TestInfraResources}}), so this issue is only about the runtime server.

Nothing blocks it technically: MCP Java SDK 2.0.0 has the full server-side resource API
({{addResource}}, {{addResourceTemplate}}, {{removeResource}}, {{notifyResourcesListChanged}},
{{notifyResourcesUpdated}}, {{ServerCapabilities.resources(subscribe, listChanged)}}), and
quarkus-mcp-server 1.13.1 has {{ResourceManager}} for dynamic registration, so a Quarkus engine
can follow the same shape.

Before writing code I would like to settle six design points.

h3. 1. How should a resource be declared?

Tools come from {{ai-tool}} routes. For resources I see three options:

* a new consumer-only component, e.g.
  {{from("mcp-resource:app_config?uri=camel://config/app.json&mimeType=application/json&tags=crm").to("aws2-s3:...")}}
  — the route body becomes the resource contents. Symmetric with {{ai-tool}}, and
  {{camel-mcp-server-api}} would depend on it exactly as it depends on {{camel-ai-tool}} today.
* new options on {{ai-tool}} itself. There is precedent (CAMEL-24332 put the MCP annotation
  hints there), but it adds an MCP-only concept to a deliberately framework-agnostic component
  that the langchain4j and openai producers also consume.
* configuration-only static resources ({{camel.server.mcp-resources[...]}} pointing at
  files/classpath), which would not cover the FTP/S3 case from the description.

My preference is the first. Is that the direction you want?

h3. 2. Resource templates in the first iteration?

{{resources/templates/list}} with URI template variables bound as headers: v1 or follow-up?
I would keep v1 to fixed URIs unless you see it differently.

h3. 3. Subscriptions?

Proposal for v1: {{resources(false, true)}} — {{notifications/resources/list_changed}} on route
start/stop, no per-resource {{resources/subscribe}}. Is there a use case that needs subscribe now?

h3. 4. Tag selection and timeout — shared with tools or separate?

The bridge exposes only tools whose tags intersect {{camel.server.mcp-tags}}. Should resource
reads reuse that property and {{mcp-tool-timeout}}, or get {{mcp-resource-tags}} and their own
timeout? Reuse looks right to me (same trust boundary), with the consequence that one tag opts a
route in to both surfaces.

h3. 5. SPI evolution and the conformance kit

{{McpServerEngine}} is implemented out of tree by camel-quarkus-mcp-server and the Spring Boot
starter, so {{resourceAdded}}/{{resourceRemoved}} would land as {{default}} no-ops — that part is
safe. The shared {{McpServerConformanceTestSupport}} is the real question: adding resource
assertions there would fail those engines until they implement resources. Would you rather the kit
gate resource tests behind an engine capability flag, or stay tool-only until every engine catches up?

h3. 6. Prompts?

The same gap exists for {{prompts/*}}. Out of scope here and a separate issue, or should the SPI be
shaped for both in one go?

_Reported by Claude Code on behalf of Karol Krawczyk_

> camel-mcp-server: should add support for MCP resources
> ------------------------------------------------------
>
>                 Key: CAMEL-24394
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24394
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-mcp-server
>    Affects Versions: 4.22.0
>            Reporter: Otavio Rodolfo Piske
>            Priority: Major
>
> It seems that the Camel MCP server only supports exposing routes as MCP tools. Although tools are the most common use case, MCP resources can be particularly useful as well - specially in cases when the operation is a read-only one to retrieve data (i.e.: think of reading a static file from FTP or S3). 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)