Claude Desktop + MCP: A Company Brain for Law Firms

Claude Desktop gets much more useful when it stops being a separate writing window and starts becoming a safe front door into the firm. That is what the Model Context Protocol, or MCP, makes possible: Claude can ask approved tools for information from the systems staff already use, then prepare the next step with the right context in view.

For a law firm, that is the difference between a chatbot and a company brain. A chatbot waits for someone to paste facts. A company brain can read the approved firm context, respect role boundaries, and help staff move work across systems without turning every question into a scavenger hunt.

This is the long-term direction behind the law-firm operations system we are building at FirmOps. Start with the AI Concierge for one visible bottleneck. Then, as the firm earns trust in the model, connect Claude Desktop and managed agents to the systems that already run the business.

What MCP changes inside Claude Desktop

Without MCP, Claude can only use what a staff member types or pastes into the chat. That creates friction, security risk, and inconsistent answers. With MCP, Claude Desktop can expose a curated menu of tools: search a matter, look up a contact, read a timeline, find the right email thread, inspect a Dropbox folder, or draft a matter email.

The key word is curated. A good company-brain connector is not a giant admin key. It is a role-aware staff surface with lookup-first tools, audit trails, and clear side-effect gates. Staff should be able to ask useful questions like “what happened on this matter this week?” or “draft the provider follow-up from the file,” without also giving Claude the ability to approve payments, publish public posts, or make unsupervised legal decisions.

Concrete example: the Conduit Team MCP

At Conduit, the staff-facing Team MCP is intentionally separate from the admin/operator MCP. The team surface is matter-centric and built for Claude Desktop-style staff work. It exposes tools such as find_matter, find_contact, get_contact, get_matter_timeline, list_matter_notes, list_matter_communications, and list_matter_tasks.

That means a staff member can start from a normal language question and let Claude gather the file context through approved routes. Instead of opening Clio, searching notes, checking tasks, and asking another person for the latest status, Claude can assemble the picture and cite which system it read.

The same surface connects to communication and document systems. Tools such as search_my_email, get_email_thread, get_gmail_attachment, search_dropbox, list_dropbox_folder, and read_dropbox_file let Claude find the conversation or document before drafting. When a draft is appropriate, tools like draft_matter_email and reply_to_matter_email keep the output in a Gmail draft review path instead of auto-sending.

What staff can actually do with a company brain

The useful version of this is not “connect every API and hope.” It is a set of staff jobs where one trusted assistant can read across systems and prepare work for review.

• Matter status: use get_matter_timeline, notes, communications, and task lists to answer “what is stuck and who owns the next move?”
• Email follow-up: use Gmail thread search plus matter context to draft a response that staff can edit and send.
• Document review: search Dropbox, read allowed files, and prepare a summary or next-step checklist without moving the original document.
• Payment prep: use submit_payment_request and get_payment_detail behind the firm’s approval process instead of informal Slack or email requests.
• Health-insurance billing notices: use generate_hi_billing_notice to prepare a draft packet while preserving staff review.
• Validation and reporting: use list_validation_candidates, review_matter_validation, validated_matters_report, channel_performance_report, and channel_cohort_report to turn operating questions into measurable answers.
• Mold and lead workflows: use tools like find_mold_lead, get_mold_lead_scorecard, mold_pipeline_summary, and create_intake_link so intake staff can work from one assistant instead of bouncing across portals.

None of those examples require Claude to replace staff judgment. The value is that Claude can collect the file, draft the work, and point the human to the decision.

The staff automation catalog matters as much as the tools

One lesson from building the Conduit Team MCP is that tool names are not the product. Staff need recognizable work buttons. The Team MCP includes a staff automation catalog with practical actions such as Draft Welcome Package, Draft BI1 LOR, Draft UIM LOR, DPD Report Request, Draft Provider LOR, Request Provider List, treatment referral drafts, Terminate Old Attorney, Settlement Alert, and HIPAA authorization requests.

Those examples matter because they translate API plumbing into staff language. A paralegal does not want to think about which endpoint creates a Gmail draft, which template version applies, where the matter folder lives, or which document needs to attach. The company brain should know the approved path and ask for review when the work is ready.

The safety model: read first, draft second, approve before action

A firm brain should start read-first. Claude can search, summarize, and draft from approved sources before it is allowed to change anything. The next level is draft-gated work: emails, letters, referrals, notices, and packets prepared for human review. Only after the firm has clear policy should live actions be allowed, and even then the highest-risk actions need explicit approval.

In practice, we separate three lanes:

• Read-only: matter lookup, timeline, notes, tasks, communications, Dropbox search, email search, and reporting.
• Draft-gated: Gmail drafts, letter packets, referral drafts, billing notices, and document requests.
• Approval-gated live action: SMS sends, payment workflow steps, public posts, broad record changes, spend, or anything that could create legal or client risk.

This is why MCP design belongs inside a law firm AI policy and an AI implementation plan, not just an IT ticket. The question is not “can Claude call the API?” The question is “which staff role should see which tools, what gets logged, and where does human approval sit?”

How to roll it out without creating chaos

The clean rollout is narrow. Pick one team and one recurring question. For example: “what is the current status of this matter?” Connect only the safe read tools needed to answer it. Test whether Claude can gather the same facts a good case manager would gather. Then add one draft path, such as a reviewed email follow-up or provider-list request.

After that, measure where staff actually use it. Good signals include fewer status pings, fewer missed follow-ups, faster draft preparation, cleaner handoffs, and fewer places where a manager has to ask someone to manually reconstruct the story from three systems.

That is how Claude Desktop becomes more than another AI tab. It becomes the place staff go to ask the firm what it knows.

Where FirmOps fits

FirmOps builds this as an operator-led implementation, not a generic connector install. The first step is usually a visible workflow through the AI Concierge. The expansion path is Managed AI Agents and MCP-backed integrations that let the firm brain read Clio, Gmail, Dropbox, intake, tasks, reporting, and other approved systems through one governed staff surface.

Bring one repeated staff question or one cross-system handoff. We will help decide whether it should become a company-brain workflow, what should stay human, and which APIs Claude should be allowed to touch first.