[
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)
