Plugging your own tools into LIA with MCP

The problem

LIA knows your mail, your calendar, your files. But your work may also live elsewhere: a ticket tracker, a code repository, a database, an in-house service. I can't write a connector for each one. It needed a standard door that you could open yourself.

What MCP is

The Model Context Protocol (MCP) is an open protocol made for exactly that. A service publishes an MCP server that describes its tools: their name, what they do, the parameters they expect. An assistant that speaks MCP can then use them without code written specially for that service.

What I wanted

I wanted you to be able to add a server from the settings, and have its tools join LIA's as if they had always been there. You give its HTTPS address, a short description and how to authenticate: nothing, a key, a token, or an OAuth connection, meaning the service's own authorization page, as with Google. LIA tests the connection, discovers the tools and, if you didn't write anything, writes a description itself so it knows when to use them. Your credentials are encrypted before being stored.

How it works

You've connected your ticket tracker's server and you ask “which tickets are assigned to me this week?”. LIA picks that tool among its own based on your question and the server's description, calls it, then shows the result in a card that names the server and the tool. It adds no field the server didn't return.

Some servers need several steps: read their documentation, call a tool, chain another one with the result. For those, you turn on iterative mode: LIA hands the request to a dedicated assistant that works step by step with that server, within a bounded number of steps and a bounded time. It costs more, and it doesn't guarantee success.

LIA keeps in memory what each server offers, so it doesn't have to ask again with every message. If a server is slow to get ready, a short message says so, and your answer arrives without its tools, so you're not kept waiting. Before using a tool it hasn't heard from recently, LIA checks that the server still offers it in the same form; if not, the call doesn't go out and LIA tells you.

Staying in control

An MCP server is written and hosted by someone else. So I set a few rules:

Your confirmations. Account, server and tool choices determine whether LIA asks. A dedicated agent is approved once before its task when any of its tools would ask, then completes that task. “Never ask” is your explicit standing choice for one tool; a changed declaration suspends it. A routine needs advance approval in its form for servers whose calls would otherwise stop.
The network. A server you add must be reachable over HTTPS. LIA refuses addresses that point to a private or local network, and doesn't launch any program on the machine it runs on.
Bounds. The number of servers, the timeouts and the rate of calls are limited by the instance. When a server asks to slow down, LIA waits before retrying.
The switch. You can pause a server without losing its configuration.

Servers also come in plugins, packages in the open Agent Plugins format that bundle skills and servers. LIA installs the parts it can run and tells you what it left aside, with the reason. A plugin never brings credentials: you enter them yourself after installation.

What MCP doesn't guarantee

Encrypting your credentials protects how they're stored; it doesn't make the service that receives them trustworthy. Choose a server with the care you'd take in handing over a key. LIA also can't check everything a tool does on its side: when you approve a call, you approve the request sent, not each of its effects inside the service. Finally, a server can advertise tools and then fail on some requests. In that case, LIA tells you it failed, without dressing the failure up as a success.