Big Mode Consulting
    Integrations & AI

    MCP Servers for Legal Software: Using Your Own AI Inside Filevine and Clio

    Written by Mauro GonzalezClio Certified Consultant10+ Years in Legal TechnologyLast updated:

    Model Context Protocol is an open standard for connecting an AI model to external tools and data. A firm that wants its own model working against its own case data can build an MCP server that wraps the API its platform already publishes. Big Mode Consulting builds these against Filevine, Clio, and MyCase. What follows is what they can reach, what they cannot, and what goes wrong.

    Mauro Gonzalez13 min readAugust 2026

    Why your case management vendor has not shipped one

    Every major legal platform is building or has already shipped its own AI. A general purpose door into the same data undercuts that product, and nobody should be shocked that the door is not a priority. That is the commercial reading and it is a fair one.

    It is also not the whole story. An open connector is a support surface, because every strange model behavior becomes a ticket the vendor did not cause and cannot reproduce. It is a security surface, since a new authenticated path into client data is a new thing to defend. And it is an unresolved liability question about what an unpredictable model does with privileged material once it has been handed some. Those concerns are real independent of anyone's revenue.

    Both things are true at once. The outcome does not change either way. A firm that wants its own model reading its own matters usually has to build the connection itself, or have someone build it.

    What an MCP server actually is

    Strip the acronym away and it is a small service. It sits between an AI client and some other system, and its job is to describe what that system can do in a form the model understands. Nothing more exotic than that.

    The sequence runs like this. Somebody asks the model a question about a matter. The model decides it needs data and calls one of the operations the server advertised. The server turns that call into a request against the platform's API. The platform checks the credentials, applies the same permission rules it applies to every other API client, and returns whatever it would have returned to any other integration holding that token.

    Which leads to the point that matters most for anyone signing off on this. The server grants nothing new. It is a translator, not a key. Every byte it can retrieve was already retrievable by any software your firm authorized to use that API, under terms the vendor already published.

    What it can reach, and what it cannot

    The API is the boundary, and it is a hard one

    An MCP server exposes what the platform's API exposes. Nothing else. If a field is not in the API response, the model never sees it, no matter how prominently it appears on screen inside the product.

    The interface shows more than the API returns

    This one surprises firms every time. A user interface is built by the vendor against their own internal data layer, and the public API is a curated subset of that layer. Derived values, certain rollups, some report views, and occasionally whole record types live on one side and not the other. So the answer to whether the model can see a given thing is not a yes or no you can reason out from using the product. Someone has to check the documentation, then check the actual response body, because those two disagree more often than anyone would like.

    Permissions travel with the credentials

    The connector authenticates as something. Whatever that something cannot see, the model cannot see either. This is a feature, and it is the main reason we do not hand a connector an administrator token because it was the easiest one to get.

    Documents are their own problem

    Retrieving a file reference is not the same as retrieving usable text. Scanned PDFs, images, and anything without a text layer need an extraction step before a model can reason over them, and that step is where accuracy quietly degrades.

    This is the published API, used the way the vendor published it

    Everything on this page describes using an API a vendor already publishes, with credentials your firm was issued, under the terms already granted, connected to a model the firm chooses. That is the whole scope. We do not scrape user interfaces, we do not work around access controls, and we do not build anything designed to reach data a firm is not licensed to reach.

    Terms of service differ between platforms and get revised, so read yours before a project starts. If a clause is unclear, ask the vendor rather than guessing. And if the API does not expose something, that is the answer. A connector cannot expose it either.

    What we build against Filevine and Clio

    Filevine and Clio both publish documented REST APIs with token based authentication scoped to an organization. A connector wraps those. It exposes a defined set of operations to the model, translates each one into an authenticated request, and writes a log line for every call so there is a record afterward.

    We keep the operation list short on purpose. A model offered forty tools chooses badly more often than a model offered six, and every operation you expose is one more thing to reason about when something goes wrong.

    This is not hypothetical work for us. We have built read only tooling against Filevine's API for migration auditing, pulling records to check what actually landed after a platform transition rather than trusting the summary at the end of the job. Same underlying approach, different consumer.

    Read only first, and why we default to it

    The first version of any connector we build reads. It does not write. That is not a phase we skip when a client is in a hurry.

    A model that can only look is bounded. A model that can create, edit, or delete inside a system of record sits in a different risk category entirely, and the difference is not about how good the model is. It is about what a single confused call costs when the record it touched is the one a deadline hangs on.

    On our own migration monitoring tooling the read only guard is enforced in code. Write attempts are rejected before the request leaves the machine, rather than trusting the model to stay inside instructions it was given in a prompt. Instructions are advisory. Code is not.

    Firms should start the same way and stay there long enough to see how the thing behaves against real matters. Add write access one operation at a time after that, deliberately, with a named person deciding that this specific write is worth the exposure.

    What to get right before you build one

    • Scope the access to the minimum the workflow needs. Not the token you happen to already have.
    • Log every call the connector makes, with a timestamp and the operation. Someone will eventually ask what the model saw, and the answer needs to be better than a shrug.
    • Decide where the model runs, and be specific about it. Third party hosted means client data crosses a boundary, and that decision belongs to a partner, not to whoever is writing the code.
    • Check your engagement letters and your ethical obligations. ABA Model Rule 1.6 covers confidentiality of client information, and ABA Formal Opinion 512 addresses generative AI use. Read both before, not after.
    • Rate limits and pagination. This is where connectors quietly break at volume. A tool that works beautifully against a demo matter times out or silently truncates against a firm with years of history.
    • Clean the data first, or accept the consequence. A connector pointed at messy records produces confident wrong answers, exactly like every other automation.

    Where this is worth doing, and where it is not

    Worth doing

    • A specific repeated workflow the platform's own AI does not do, and you can name it in one sentence.
    • The firm has already standardized on a model for other reasons and wants matter data available to it.
    • The work spans several systems at once, so a tool that only lives inside one platform cannot complete it.

    Not worth doing

    • The built in AI already covers the job. Pay for the connector you need, not the one that sounds better in a pitch.
    • The underlying data has not been cleaned.
    • Nobody at the firm will own it after launch. Connectors need maintenance when APIs change, and they do change.

    Related reading

    Custom integrations and AI orchestrationThe broader integration view: APIs, connector layers, and how orchestration fits across a whole stack.AI for law firmsWhat AI does well today and what it still gets wrong inside a working firm.Integration servicesHow we scope and deliver integration work.

    Want to point your own model at your own data?

    We build read only connectors against Filevine, Clio, and MyCase, and we will tell you honestly when the platform's own AI already does the job.

    Frequently Asked Questions

    Model Context Protocol is an open standard for describing tools and data to an AI model in a consistent way. An MCP server is the small service that does the describing. It sits between the model and some other system, tells the model which operations exist, and calls that system when the model asks. It does not grant access beyond what the underlying API already allows. The credentials it uses set the ceiling.

    Yes, in the sense that a connector can be built against Filevine's published API using your firm's own credentials and permissions. No, in the sense that there is no official first party switch to flip at time of writing. Someone has to build and host the connector, decide what it exposes, and keep it running. Big Mode Consulting builds these.

    Using a documented API with credentials your firm was issued is normally within terms. Normally is not always. Terms differ by platform, differ by contract, and change over time, so read yours before anyone writes code, and ask your account team if a clause is ambiguous. We do not build anything that scrapes a user interface or works around access controls.

    That depends on where the model runs and what the connector is allowed to touch. A model hosted by a third party means matter content leaves your environment and lands under someone else's terms, retention, and training policy. A model running inside infrastructure your firm controls keeps that boundary tighter and costs more to stand up. Either way, scope the credentials narrowly and log every call. We will not tell you a connector is safe. We will tell you what it can reach and who sees the data.

    Anything the underlying API does not expose. If a field, document type, or report is not available through the API, no connector conjures it. It also cannot exceed the permissions of the credentials it uses, and it cannot fix bad data. Point one at a case management system full of duplicates and half filled custom fields and you get answers that are wrong with total confidence.

    Not at first. Reading is recoverable. A model that can create, edit, or delete inside a system of record is a different risk category, and the blast radius of a bad call is much larger. Start read only, run it against real work for a while, then add write access one operation at a time with someone deciding each time that the specific write is worth it.

    The honest drivers are how many operations you actually need, how well the platform documents its API, and how clean the data is underneath. Three read operations against a well documented API is a small piece of work. Twenty operations spanning documents, custom fields, and pagination heavy endpoints, against data nobody has audited, is a project. We scope it after seeing which workflow you want to run, not before.

    About the Author

    Mauro Gonzalez is the founder of Big Mode Consulting with over a decade of experience in legal technology and enterprise IT. As a Clio Certified Consultant and Filevine implementation specialist, he has helped 50+ law firms modernize their technology stacks. He specializes in case management implementation, managed IT services, and ABA-compliant cybersecurity solutions.