Most AI demos stop at chat. The useful work starts when an assistant can act—open a ticket, draft a post, look up a deal—without becoming a liability.
That is what Model Context Protocol (MCP) is for: give assistants a coherent set of tools against real systems, with auth and boundaries you can defend. At Endertech we did not wait for a client project to learn those boundaries. We built MCP into Ansible—our Symfony + API Platform portal—so assistants could work inside the same systems we already use to run the agency.
The original consumers were OpenAI / ChatGPT and our own in-portal chat. Cursor came later as another client of the same server. We are writing this for buyers and builders who want to know whether MCP is shippable—and for operators who care whether their vendor has scars from production. We have both.
Why we built it: chat that can act on Ansible
Generic chat is good at drafting. It is weak at being accountable. The moment you ask an assistant to touch tickets, content, CRM, or source control, you inherit ordinary systems questions:
- Who is the agent? A real system identity and keys you can rotate—not a shared admin cookie.
- What can it do? A clear toolkit with schemas and scopes—not a wrapper around every internal endpoint.
- What happens when it fails? Safe defaults and honest answers when something is missing or unsupported.
- How do you know it worked? Logs per action, the same way you would treat any production API.
We proved those answers on our own portal first. If MCP cannot survive daily use on Ansible, we should not sell it as a client architecture.
What the tools actually cover
It is easy to undersell this surface as “tickets, blog, and GitLab.” Day to day we run 37 tools grouped by business outcome:
- Tickets & tasks — find recent work, summarize a task, create project tasks after a human approves the plan in chat.
- Projects & sprints — overviews, active sprints, workload snapshots, timelines.
- CRM — search companies, contacts, and deals so an assistant can pull account context instead of guessing.
- Knowledge base — draft internal articles when delivery work needs to become reusable guidance.
- Blog & portfolio — draft posts and case studies into the CMS; update, publish, pin, and manage taxonomy when the workflow calls for it.
- Media — upload assets so content work does not stall on a side channel.
- GitLab — pull repository signal for ideation and status, not as a substitute for engineering judgment.
- Team profiles — enough people context for drafts and operational questions without inventing a second directory.
The portal’s core action set is smaller and deliberate (search, fetch, summaries, drafts, create tasks). The broader Cursor-facing Ansible MCP surface we use every day expands that into the 37-tool toolkit above. Either way, the point is the same: assistants get verbs that map to real Monday-morning jobs.
Examples staff and agents actually run: find the last tickets on an account, summarize a task before standup, draft a blog post into the CMS, draft a portfolio entry, create project tasks after human approval in chat, search CRM deals and companies, pull GitLab signal for a topic, upload media, update a published post.
What production taught us (plain English)
Protocol demos hide the boring failures. Running MCP against a real remote client exposed the ones that matter to anyone who will own on-call:
- Missing config should fail safely. Unset keys or identity settings should not crash the server. Defensive defaults beat “it usually works in production.”
- Long sessions need health answers. Clients will ask whether the server is alive and what it can do. Answer those checks—or the conversation dies mid-task and people blame “the AI.”
- Advertise only what you support. A short, honest toolkit beats a long menu of half-implemented capabilities. Empty-but-valid responses are better than silence or 500s when a feature is intentionally off.
- Auth needs rotatable keys and a real system identity. Production MCP is shared team use and remote access, not a laptop browser cookie. Keys you can revoke without redeploying anyone’s IDE.
- Log per action. When a draft lands wrong or a task is created incorrectly, you need a trail of who called which tool with which outcome.
None of that is glamorous. All of it is the difference between a spike and something operations will run.
Patterns we would reuse for a client MCP server
- Identity before tool breadth. Keys (or OAuth), a mapped system user, and tool-level authorization that respects existing roles. Widen tools only after identity is boring.
- Capability honesty over a long menu. Agents plan better with clear verbs and schemas than with fifty vaguely named endpoints.
- Start narrow, expand with evidence. High-value, low-risk actions first; staging evaluation; then growth when the logs say the tools are safe and useful.
- Treat MCP like an API surface. Contract tests, auth tests, structured errors, and a few end-to-end paths against staging data.
That is the same arc we describe on our MCP server solutions page—feasibility spike, MVP server, or platform layer—because it is how we already run the work internally. Ansible is the reference deployment: we use MCP on our own agency systems first, then we sell the same discipline to clients.
Who this is for
- Teams shipping custom software who need MCP as a product capability—not a weekend plugin.
- Operators who will own auth, keys, and on-call when an assistant writes to a system of record.
- Leaders who want AI leverage without giving a model unbounded access to production data.
If your assistant still lives in a chat window while your real work lives in tickets, CMS, CRM, or Git, MCP is the bridge—when it is built like software.
Let’s talk about your MCP surface
We run ours in production on Symfony + API Platform so the failure modes are ours first. If you want the same discipline on your stack—governed tools, auth you can revoke, observability you can audit—start with the systems and policies, not the model name.
Tell us what the assistant should be allowed to do on Monday morning. We will help you scope the tools that ship safely. Learn more about how we approach this work at endertech.com/solutions/mcp-server.
Endertech builds custom software and production MCP servers for teams that need AI assistants to act inside real business systems—with the same engineering standards we apply to our own portal.