Model Context Protocol (MCP) is a standard way for an AI client to discover tools, call them, and get structured results back. In a .NET studio that already ships ASP.NET Core APIs, it is not a new religion — it is a contract so Cursor, Claude, or an internal agent can talk to the same services your products already expose.
We started using it at Gidysoft because every product team was pasting connection strings and admin URLs into chat windows. That does not scale, and it is a security incident waiting to happen. MCP lets us publish a small, typed surface — “list open EduPick enrollments”, “replay a Limy webhook”, “fetch last night’s Tahta error budget” — without handing the model the whole database.
What we actually expose
Each MCP server is a thin host in front of an existing use-case. The agent never writes raw SQL. Tools take explicit IDs, return DTOs, and time out. If a tool can mutate state, it is marked as such and requires a confirmation token the human has to click. Read tools are cheap; write tools are rare.
We keep one server per bounded context, not one giant “Gidysoft brain”. EduPick’s enrollment tools do not sit next to Kitapix catalog writes. That isolation is the same reason we split ASP.NET solutions: blast radius, ownership, and the ability to revoke a server without taking the studio offline.
Auth is the hard part
An MCP server that inherits the developer’s laptop identity is fine for local debugging. The moment it runs against staging or production, it needs its own principal, scoped tokens, and an audit row for every call — who asked, which tool, which arguments, which model. We log those the same way we log admin API traffic. If you cannot answer “who refunded that user?”, you do not have a tool, you have a hole.
How this shows up for clients
When we add an assistant inside a product, we reuse the same tool definitions. The marketing site chat does not get production tools. The internal ops assistant does. Same protocol, different allow-lists. That is the Gidysoft rule: protocol for portability, policy for safety.
Questions we keep getting
Do you replace your APIs with MCP? No. HTTP APIs stay the source of truth. MCP is a discovery and calling layer on top, the same way a Swagger UI never replaced the API.
Is it only for coding agents? No. We use it for coding agents and for in-product assistants. The useful part is the shared tool schema, not the IDE.
When would you skip MCP? A single hardcoded function call in one feature. Standards pay off when a second client appears — and it always does.