Default error [chapter] deterministic

return MCPResponse( error={"code": -32601, "message": "Method not found"}, id=request.id )

`

This example is intentionally simple. In a production server, you would add authentication, rate limiting, logging, and proper error handling. You would also validate the arguments parameter against a schema to prevent injection attacks. For example, if the run_command tool expects a command string, you might require that it matches a whitelist of allowed commands.

Implementing Tools and Resources When you design your tools and resources, think about the data flow and the context that the model will need. For a knowledge‑graph application, you might expose a GetNeighbors tool that returns the immediate neighbors of a node, along with the edge types. For a content‑automation pipeline, you might expose a FetchPosts tool that retrieves recent posts from a social‑media API, and a Summarize tool that calls an LLM to generate a summary. Each tool should have a clear name, a concise description, and a well‑defined input schema. The description is important because the model uses it to decide when to invoke the tool. If the description is vague, the model may misuse the tool or skip it entirely. Therefore, write descriptions that are specific and action‑oriented. For example, instead of “Fetch posts,” use “Retrieve the most recent 10 posts from the Instagram feed, including metadata such as timestamp and author.” When you expose resources, consider whether they are static, semi‑static, or dynamic. Static resources (e.g., a configuration file) can be cached indefinitely. Semi‑static resources (e.g., a database table that is updated once per hour) should have a TTL (time‑to‑live) that tells the client when to refresh. Dynamic resources (e.g., a live feed of sensor data) may require real‑time subscriptions. MCP supports both polling and subscription‑based updates, so you can choose the model that fits your use case.

Security Considerations Because MCP gives the model the ability to read and invoke arbitrary actions, security must be a first‑class concern. The **Cybersecurity Specialist** in your team should help you define a threat model that covers the entire MCP stack. At a minimum, you should consider the following: - **Authentication**: Ensure that only authorized clients can connect to the server. Use token‑based authentication, mutual TLS, or OAuth2 as appropriate. - **Authorization**: Enforce fine‑grained access controls for resources and tools. For example, a tool that writes to a database should only be callable by users with the write role. - **Input Validation**: Validate all inputs against a schema. Reject malformed or overly large payloads. Sanitize strings to prevent injection attacks. - **Rate Limiting**: Prevent abuse by limiting the number of requests per client per time window. - **Audit Logging**: Log all requests and responses, including the ID, timestamp, and result. This is essential for forensic analysis and compliance. - **Sandboxing**: Run tools in a sandboxed environment (e.g., a container or a restricted account) to limit the impact of a compromised tool. When you integrate MCP with a local LLM, you should also consider the model’s own security posture. For example, if the model is running on your machine, you should ensure that it does not leak sensitive information through its output. This can be achieved by filtering the model’s responses, applying content moderation, or using a post‑processing step that removes PII (personally identifiable information).

Integrating MCP with Local LLMs

Client Configuration Integrating MCP with a local LLM typically involves configuring the client to communicate with the MCP server. The client can be a simple script, a web application, or a full‑featured AI framework such as LangChain or LlamaIndex. The key is to establish a reliable transport connection and to handle the MCP protocol messages correctly. In Python, you can use the requests library to send JSON‑RPC requests to the server. You will need to construct the request payload according to the MCP schema, send it to the server endpoint, and parse the response. The response will contain the result of the operation, such as a list of resources, the content of a resource, or the output of a tool. Below is a minimal client that connects to the MCP server defined earlier and calls the run_command tool. The client sends a JSON‑RPC request, receives the response, and prints the result.

```python import requests import json SERVER_URL = "http://localhost:8000/mcp" def call_mcp_tool(tool_name: str, arguments: dict) -> dict: payload = { "jsonrpc": "2.0", "method": "call_tool", "params": {"tool_name": tool_name, "arguments": arguments}, "id": 1 } response = requests.post(SERVER_URL, json=payload) response.raise_for_status() return response.json() if __name__ == "__main__": result = call_mcp_tool("run_command", {"command": "echo 'Hello from MCP'"}) print(result)

`

This client is straightforward but does not include authentication or error handling. In a production environment, you would add headers for authentication, check the response status code, and handle errors gracefully. You would also consider using a library that abstracts the JSON‑RPC protocol, such as jsonrpcclient or a custom wrapper around requests.

Source Code and Repositories

This chapter draws from the following open-source projects by DanielKliewer:

• **PersonaGen**: https://github.com/kliewerdaniel/PersonaGen
• **dynamic_persona_moe_rag**: https://github.com/kliewerdaniel/dynamic_persona_moe_rag
• **SynthInt**: https://github.com/kliewerdaniel/SynthInt
• **workflow**: https://github.com/kliewerdaniel/workflow
• **sovereign**: https://github.com/kliewerdaniel/sovereign
• **sovereignSpec**: https://github.com/kliewerdaniel/sovereignSpec

For more projects, visit https://github.com/kliewerdaniel

---

Chapter 8: Multi-Agent Systems