The final part of the warehouse series moved from an interactive client to a Python workflow. It used the mcp-agent framework to connect to the MCP server, attach a local model, query inventory information, and summarize the result.
The earlier layers remained in place: FastAPI performed warehouse operations and Redis stored order data. The agent coordinated calls to that service rather than accessing the database directly.
Keep the runtime configuration visible
The historical configuration named the MCP server, configured its connection, and selected an OpenAI-compatible Ollama endpoint for inference. The example used Qwen 2.5 and a framework wrapper for the model interaction.
A server name in configuration is a reference the application uses to locate a connection. The MCP client discovers exposed tools through MCP. The FastAPI integration may derive those tools from API definitions, but the client is not independently discovering arbitrary REST endpoints.
Make the workflow observable
The example initialized an MCPApp, created an inventory agent, listed available tools, attached the model wrapper, and issued prompts. A follow-up prompt requested a summary of the gathered information.
Initialize runtime → connect server → inspect tools
Attach model → request inventory data → inspect result → summarizeThese are useful boundaries for logging and debugging. A model response should remain connected to the tool results that support it. Avoid logging credentials or unnecessary customer information while making those boundaries observable.
Decide what happens between runs
The original article proposed persistent memory as an extension. That raises concrete questions: which state belongs to a task, how long it should be retained, and whether a later run may rely on an earlier inventory snapshot.
A summary can become stale when orders change. Retained conversation history should not silently replace a fresh service query when the user asks for the current state.
Carry service rules into the agent workflow
Useful extensions include clearer tool descriptions, bounded retries, explicit handling of partial results, and authorization on the service. None is supplied merely by attaching a model or choosing an asynchronous runtime.
The author’s agent example and mcp-agent project preserve the implementation. Start with part 1 for the API design and part 2 for the interactive local-model connection. Together, the three layers show where each responsibility belongs and where a failure can be inspected.