$npx -y skills add giuseppe-trisciuoglio/developer-kit --skill langchain4j-mcp-server-patternsProvides LangChain4j patterns for implementing MCP (Model Context Protocol) servers, creating Java AI tools, exposing tool calling capabilities, and integrating MCP clients with AI services. Use when building a Java MCP server, implementing tool calling in Java, connecting LangCh
| 1 | # LangChain4j MCP Server Implementation Patterns |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill to design and implement Model Context Protocol (MCP) integrations with LangChain4j. |
| 6 | |
| 7 | The main concerns are: |
| 8 | - defining a clean tool, resource, and prompt surface |
| 9 | - choosing the right transport and bootstrap model |
| 10 | - filtering unsafe capabilities before exposing them to agents or applications |
| 11 | |
| 12 | Keep `SKILL.md` focused on the implementation flow. Use the bundled references for expanded examples and API-level detail. |
| 13 | |
| 14 | ## When to Use |
| 15 | |
| 16 | Use this skill when: |
| 17 | - building a Java MCP server that exposes tools, resources, or prompts |
| 18 | - integrating LangChain4j with one or more external MCP servers |
| 19 | - wiring MCP support into a Spring Boot application |
| 20 | - filtering available tools by tenant, user role, or runtime context |
| 21 | - adding observability, resilience, and safe failure handling around MCP interactions |
| 22 | - reviewing an MCP integration for prompt-injection and side-effect risks |
| 23 | |
| 24 | Typical trigger phrases include `langchain4j mcp`, `java mcp server`, `mcp tool provider`, `spring boot mcp`, and `connect langchain4j to mcp`. |
| 25 | |
| 26 | ## Instructions |
| 27 | |
| 28 | ### 1. Design the MCP surface before writing code |
| 29 | |
| 30 | Decide what the server should expose: |
| 31 | - tools for actions with clear inputs and side effects |
| 32 | - resources for read-only or structured data access |
| 33 | - prompts only when a reusable template adds real value |
| 34 | |
| 35 | Keep names stable, descriptions concrete, and schemas small enough for a client or model to understand quickly. |
| 36 | |
| 37 | ### 2. Implement providers with narrow responsibilities |
| 38 | |
| 39 | Use separate classes for each concern: |
| 40 | - tool provider for executable functions |
| 41 | - resource provider for discoverable and readable data |
| 42 | - prompt provider for reusable prompt templates |
| 43 | |
| 44 | Validate arguments before execution and return clear error messages for invalid input or unavailable dependencies. |
| 45 | |
| 46 | ### 3. Choose the transport intentionally |
| 47 | |
| 48 | Use: |
| 49 | - stdio for local integrations, CLI tools, and sidecar processes |
| 50 | - HTTP or SSE for remote or shared services |
| 51 | |
| 52 | Pin external server versions and document how the process is started, authenticated, and monitored. |
| 53 | |
| 54 | ### 4. Bridge MCP into LangChain4j carefully |
| 55 | |
| 56 | When consuming MCP servers from LangChain4j: |
| 57 | - initialize clients during application startup |
| 58 | - cache tool lists only when stale metadata is acceptable |
| 59 | - filter tools by trust level, environment, or user permissions |
| 60 | - fail closed for dangerous tools rather than exposing everything by default |
| 61 | |
| 62 | ### 5. Add resilience and security controls |
| 63 | |
| 64 | At minimum: |
| 65 | - bound execution time for external calls |
| 66 | - log server and tool identity for each failure |
| 67 | - sanitize content returned by external resources before using it downstream |
| 68 | - isolate privileged tools behind allowlists, qualifiers, or role checks |
| 69 | |
| 70 | ### 6. Validate the full workflow |
| 71 | |
| 72 | Before shipping: |
| 73 | - verify tool discovery and invocation with a real MCP client |
| 74 | - test disconnected or slow server behavior |
| 75 | - confirm that tool filtering matches the intended authorization model |
| 76 | - check that prompts and resources do not leak secrets or unsafe instructions |
| 77 | |
| 78 | ## Examples |
| 79 | |
| 80 | ### Example 1: Minimal tool provider and stdio server bootstrap |
| 81 | |
| 82 | ```java |
| 83 | class WeatherToolProvider implements ToolProvider { |
| 84 | |
| 85 | @Override |
| 86 | public List<ToolSpecification> listTools() { |
| 87 | return List.of( |
| 88 | ToolSpecification.builder() |
| 89 | .name("get_weather") |
| 90 | .description("Return the current weather for a city") |
| 91 | .inputSchema(Map.of( |
| 92 | "type", "object", |
| 93 | "properties", Map.of( |
| 94 | "city", Map.of("type", "string") |
| 95 | ), |
| 96 | "required", List.of("city") |
| 97 | )) |
| 98 | .build() |
| 99 | ); |
| 100 | } |
| 101 | |
| 102 | @Override |
| 103 | public String executeTool(String name, String arguments) { |
| 104 | return weatherService.lookup(arguments); |
| 105 | } |
| 106 | } |
| 107 | |
| 108 | MCPServer server = MCPServer.builder() |
| 109 | .server(new StdioServer.Builder()) |
| 110 | .addToolProvider(new WeatherToolProvider()) |
| 111 | .build(); |
| 112 | |
| 113 | server.start(); |
| 114 | ``` |
| 115 | |
| 116 | Use this pattern for local tool execution or a sidecar process started by another application. |
| 117 | |
| 118 | ### Example 2: Expose MCP tools to a LangChain4j AI service with filtering |
| 119 | |
| 120 | ```java |
| 121 | McpToolProvider toolProvider = McpToolProvider.builder() |
| 122 | .mcpClients(mcpClients) |
| 123 | .failIfOneServerFails(false) |
| 124 | .filter((client, tool) -> !tool.name().startsWith("admin_")) |
| 125 | .build(); |
| 126 | |
| 127 | Assistant assistant = AiServices.builder(Assistant.class) |
| 128 | .chatModel(chatModel) |
| 129 | .toolProvider(toolProvider) |
| 130 | .build() |