Giving a LangChain Agent Real-World Facility-Management Tools via MCP

A developer demonstrated connecting a LangChain agent to Telesherpa, an ontology-based facility, fleet and field-service management platform, through the Model Context Protocol using LangChain's langchain-mcp-adapters package over Streamable HTTP with Bearer-token authentication. The agent autonomously handles registration, email-code activation and login as MCP tool calls, then queries and modifies real ontology objects such as buildings, vehicles and machines, with role-based scopes determining which of the server's live tools are visible.

Most "give your agent tools" tutorials hand it a calculator or a weather API. Useful for learning the mechanics, but it doesn't tell you what happens when an agent gets access to a real operational system — one with access control, multi-tenancy, and objects that map to actual physical things buildings, vehicles, machines . This post walks through connecting a LangChain agent to Telesherpa https://www.telesherpa.com , an ontology-based platform for facility, fleet and field-service management, over the Model Context Protocol https://modelcontextprotocol.io MCP . By the end, the agent can query and modify real ontology objects — not toy data — using nothing but its own reasoning and the tools MCP hands it. Two things make this a useful example rather than a marketing demo: public caller sees a handful of self-registration tools, an authenticated caller with the right scope sees object CRUD, reports, automation triggers, structured image filing, and more. That's a realistic shape for enterprise software, and a good stress test for whether an agent framework's tool-loading actually scales. register , activate a 7-digit email code , and login are all public MCP tools. An agent can go from nothing to an authenticated session without a human ever opening a browser. LangChain's official langchain-mcp-adapters https://github.com/langchain-ai/langchain-mcp-adapters package speaks MCP's Streamable HTTP transport natively, including custom headers — which is what you need for Bearer-token auth against a remote server: python from langchain mcp adapters.client import MultiServerMCPClient client = MultiServerMCPClient { "telesherpa": { "transport": "http", "url": "https://mcp.telesherpa.com", "headers": {"Authorization": f"Bearer {token}"}, } } tools = await client.get tools That's the entire integration surface. tools is now a list of LangChain-compatible tools, generated directly from the server's live tool catalog — no manual schema mapping, no maintaining a wrapper per endpoint. If Telesherpa adds a tool next week, your agent sees it next week too. Before that snippet works you need token . Since every step is itself an MCP tool call, an agent can do this on its own: 1. register — creates an account, requires accept terms=true await call tool "register", {"email": "...", "accept terms": True, ...} 2. activate — redeem the 7-digit code emailed to that address await call tool "activate", {"code": "1234567"} 3. login — exchange client credentials for a bearer token result = await call tool "login", {"client id": "...", "client secret": "..."} token = result "token" valid ~10h refresh token = result "refresh token" auth status is worth calling first in any new session — it tells you plainly whether your token is valid, which roles it carries, and how many of the total tools are currently visible to you. Cheaper than guessing from a 401. With tools loaded, a standard LangChain agent can now reason over real ontology objects: python from langchain.agents import create agent agent = create agent "openai:gpt-4.1", tools response = await agent.ainvoke { "messages": "List the buildings in my current scope and flag any " "that are missing a structured image category." } Under the hood this typically resolves to a couple of tool calls — something like onto type show "building" to enumerate objects, then onto file structured object id per building to check which image categories are filled. The agent picks the sequence; you didn't hardcode it. What makes this more than a search-and-summarize demo is that the same tool surface supports writes : creating objects, executing defined actions on them check-in/check-out, service-order creation, form submission , setting properties, and — critically for anything touching real operations — a role-based access model that determines what an agent is even allowed to attempt. The interesting engineering problem isn't "can the agent call a tool," it's "does the permission boundary hold when the caller is non-human." The same MCP server works the same way with CrewAI, LlamaIndex, and Microsoft's Agent Framework, since MCP is transport- and framework-agnostic by design — the tool definitions and auth flow don't change, only the client-side plumbing does. Working examples for each some verified, some flagged as in-progress are in telesherpa/telesherpa-quickstarts https://github.com/telesherpa/telesherpa-quickstarts . The full capability reference — object model, scopes, automation, structured image filing, forms — is in telesherpa/skill-telesherpa-com https://github.com/telesherpa/skill-telesherpa-com . If you're building agents that need to do something in the physical world — not just answer questions about it — this is roughly the shape that "agent-ready" enterprise software needs to take: a documented, self-registering, role-scoped MCP surface, not a REST API with an OpenAPI spec bolted on after the fact.