Skip to main content
Help Center

How MCP works in teamspace

The building-block principle behind MCP configurations: why many small accesses beat one large one – and why your own permissions always apply.

teamspace comes with an MCP server of its own. But it is not a finished, fixed offering – it is a construction kit: an administrator assembles as many accesses from it as the company needs, each with its own set of tools and its own release.

Two principles explain almost everything you will come across with MCP. Once you understand them, the rest is just a matter of looking things up.

Principle 1: many small accesses instead of one large one

It would be technically possible to build a single MCP that contained every tool for every area. We advise against it – and not out of caution, but for speed.

An AI assistant is handed the list of all tools when it connects, and it has to keep them in mind on every request. That list takes up space in the model’s working memory and time on every reply. The more tools an MCP offers, the longer it takes before the assistant even gets going – and the greater the chance that it reaches for the wrong one among twenty similar tools.

A tailored MCP with the twelve tools a department really needs is therefore noticeably faster and more accurate than an all-powerful one with a hundred. teamspace shows you this relationship right as you assemble it: the details panel on the left of an MCP configuration carries a token estimate – see Select and tailor tools.

From this follows the usual approach: one MCP per use case, not per tenant.

  • A general access with read-only access to non-critical data – released to all employees.
  • An HR access with personnel tools – released only to the HR department.
  • A sales access with CRM and sales tools – released to the sales team.

Each of these accesses has its own address. Anyone in two groups simply connects both in their client.

Principle 2: your own permissions always apply

This is the single most important statement in the whole topic, which is why it comes so early:

An MCP never extends permissions. What tools an access offers says nothing about what you can see or change with them. On every call, teamspace interprets your personal permission profile – exactly the same one that applies when you log in normally.

An example: the HR access offers the “Employee information” tool. When the head of HR calls it, she gets the personnel file. When a developer calls the same tool through the same access, he gets exactly what he would be allowed to see in the interface too – and not a single record more.

The tool selection of an MCP is therefore not a security mechanism, but a way of tailoring it to the use case. Security arises in two other places: through releasing the access to particular groups or people, and through the user’s own permission profile. How the two work together is covered in Security and permissions with MCP.

This has a pleasant side effect: you don’t have to maintain permissions twice. Someone who moves from sales to controlling sees the new area via MCP from that moment on, and no longer the old one – without anyone touching an MCP.

What this means in practice

Because the assistant works under your name and with your permissions, it is not a report generator but a colleague with access. Typical uses:

  • Analyses without a ready-made report. “Which bug tickets have gone untouched for more than two weeks, grouped by status?” – a question no one built a report for beforehand.
  • Capture in passing. Turn a chat discussion straight into an open item with a due date and an assignee.
  • Think across modules. Connect tickets, projects and contacts in a single question, without opening three views.
  • Move data. Reconcile between two systems or support a migration – the assistant reads from one and writes into the other.

The last point calls for particular care: write access is powerful, and an assistant has no sense of whether a change was costly. It is therefore common practice to build the general access read-only and to reserve write tools for a separate, more narrowly released access.

Notes

  • An MCP is tied to one tenant. The address contains the configuration’s identifier; an access from one tenant does not work in another.
  • If the administrator changes the tools, it takes effect immediately. The client picks up the new list the next time it connects – you don’t have to set up the connector again.
  • A deactivated access is dead at once. The “Active” field in the configuration is the fastest kill switch.
  • The language sits with the access, not the user. Each configuration has a language in which its tools are described. For a mixed-language team, two accesses are worth it.