TLDR: MCP is the standard that lets an assistant call outside tools. It says how to connect, not who may connect or what they get. A Skill served over MCP with no sign-in is a public Skill with extra steps. Protection needs four things on top of MCP: a sign-in that ties each connection to a person on your list, a check on every call, a per-Skill choice between handing over text and running the method server-side, and a filter that refuses extraction attempts. TCOM's connector is an MCP server with those four things built in. The standard is the road; the lock is what you build on it.

Key Takeaways

  • MCP defines the connection, not the permission.
  • An open MCP server is a public tool, whatever it serves.
  • Protection needs identity, per-call checks, a server-side mode and a refusal filter.
  • "Behind MCP" and "protected" are different claims; ask which one is being made.
  • TCOM's connector is MCP plus the four things.
  • You can test any MCP claim in five minutes with a cancelled account.

What MCP is for

MCP (the Model Context Protocol) is how an assistant such as Claude discovers and calls tools that live somewhere else. The specification covers the transport, the tool list, the call and the result. It is a good standard and we are built on it. It says nothing about whether the person calling is allowed to, and nothing about whether the tool should hand over its instructions.

The open server problem

Anyone can stand up an MCP server that returns a Skill's text when asked. If there is no sign-in, anyone who learns the address can connect, and the assistant will happily read the Skill out. That is a public Skill with a longer URL. Adding a shared secret in the URL is barely better: a secret shared with every subscriber is a secret nobody can revoke.

Four things that make it protection

  1. Identity. Each connection belongs to one person who signed in, and that person is on your list. Our connector uses the sign-in flow the big assistants expect: in Claude nothing is typed beyond the subscriber's own email and password; in Perplexity they paste the connector's public ID once. No secret is ever handed out.
  2. A check on every call. Not once at setup. When you remove someone, their next call fails.
  3. A per-Skill mode. Password mode hands the assistant the text after the check. IP mode runs the method on our server and returns only the result. MCP does not care which; you should.
  4. A refusal filter. A request that tries to pull the instructions out is refused by the server before the Skill runs.

How to test any MCP claim

Add the connector from a second account. Call the Skill. Cancel that account. Start a new chat and call it again. If it still answers, it was never protected. Then ask the assistant to show you the Skill's instructions. If it can, you are in Password mode at best.

Where TCOM stands

Our connector is an MCP server. Subscribers sign in through it, every call is checked against the creator's list, each Skill carries its own mode, and extraction attempts are refused before the Skill runs. The standard is the road. The lock is ours.