Files
computer-playbook/roles/web-app-nextcloud/meta/mcp.yml
kevinveenbirkenbachandClaude Opus 5 70feb319be feat(nextcloud): front the Context Agent with the MCP adapter
The hub serves 94 tools across 23 categories, write tools included, and enabling the ExApp switches every category on. That surface was published on the public vhost and every discovered client was handed an app password for it. svc-ai-mcp-adapter now sits in front in mcp_passthrough mode: clients present credentials.mcp_bearer to contextagentmcp and reach the nine read tools of calendar, contacts and files, which files/mcp/tools.json names and the sidecar enforces per call. Those three categories are the ones whose upstream is_available is unconditional, so the served set does not vary with which optional apps a deployment installs.

Enforcing it in the sidecar rather than in each client is what makes it hold: web-app-openwebui renders no per-tool filter at all, so a client-side include list would have bounded two consumers out of three.

06c13e7f3e withdrew the declared path from the edge for exactly this reason - "that surface is what the adapter exists to narrow". Nextcloud answers the same route under a second spelling, without the /index.php front controller, which try_files rewrites back onto the route after the edge has already declined to block it. The withdrawal becomes a regex covering both, and only where stripping the front controller changes the path, so the four adapter providers without one render unchanged.

The app password is minted after the stack renders, so it reaches the sidecar through upstream.env and rebuild.yml rather than the compose environment: compose up resolves env_file while creating the container, a restart does not. The sidecar is the last service in the template because a Jinja set has no block scope and its env_file would otherwise displace the one talk, whiteboard and talk_recording each carry.

Two suites cover what nothing measured: the vhost template rendered without a container, asserting both spellings are withdrawn, and every shipped tools.json loaded through the adapter own loader, so a bad contract fails in a second instead of as a probe timing out an hour into a deploy. The guest spec probed mcp.endpoint.path, which this change makes the proxy answer 404 for its own reasons; it now probes all three public paths and requires no MCP body.

Not yet deployed: the sidecar build, the upstream.env delivery and the hub answering exactly nine tools are unverified against a running stack.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 20:55:05 +02:00

53 lines
1.4 KiB
YAML

---
classification: adapter_server
direction: server
source_url: https://docs.nextcloud.com/server/latest/admin_manual/ai/app_context_agent.html
transport: streamable_http
exposure: internal
auth: bearer_token
auth_subject: service_account
implementation: adapter
credential:
owner: mcp-web-app-nextcloud
source: credentials
key: mcp_bearer
adapter:
type: mcp_passthrough
upstream_transport: streamable_http
specification_path: roles/web-app-nextcloud/files/mcp/tools.json
specification_sha256: sha256:1b9a603d452bf350bdc36fdc0f64b5fda82e01bb6a0cbbdf3dc9e400831474ab
upstream_path: /index.php/apps/app_api/proxy/context_agent/mcp/
endpoint:
service_key: contextagentmcp
path: /mcp
port_key: http
limits:
request_bytes: 65536
response_bytes: 1048576
timeout_seconds: 15
concurrent_requests: 4
page_size: 100
result_items: 500
stream_seconds: 300
tools:
read_probe:
tool: find_details_of_current_user
arguments: {}
allowlist:
- find_details_of_current_user
- find_free_time_slot_in_calendar
- find_person_in_contacts
- find_person_in_users
- get_file_content
- get_file_content_by_file_link
- get_folder_tree
- list_calendars
- list_tasks
categories:
- calendar
- contacts
- files
schema_sha256: sha256:3c1ad73136e3985d4884a83582bb39da051ef323eb4a9f8109558e17b6ccbdab
read_only_default: true
mutating_tools_enabled: false