MCP

Quality for MCP is a connected tool call, not a longer prompt. After the assistant runs, you should be able to name three things: which server ran, which slice of the world that server was allowed to see, and which source record came back. The record might be a page, a ticket, a commit, a message, or a row. If the client is not connected, those three stay empty. The assistant does not invent a file, a path, or an id to look finished.

That bar is what separates MCP from stuffing context into chat. Paste can produce fluent answers. It also puts the document and often the secret in the same transcript. A scoped server keeps credentials in the client configuration. The model sees tool names and tool results, not your token.

Host apps such as Claude, ChatGPT, Cursor, and Copilot belong to one class: they can run as MCP clients. Do not rank them here, and do not assume a given host exposes every server type. The permission model is the same wherever the client is honest. A tool that is not connected cannot be called. A connected tool still cannot see data outside the scope you configured.

Instructions and live access are different layers. AI Skills tell an assistant how to work. MCP tells it which tools, documents, repositories, and work history it may actually query.

Scope is a permission decision you make while the assistant is still offline. Write three boundaries first: the system (wiki, tracker, repo, mailbox, calendar), the slice (one organization, one repository, one space, one project), and the tool verbs you will allow (search, get, and list versus create or update).

Prefer a read-only first server. Search plus get replaces most of the copy-paste that people currently dump into chat. Leave write tools off until a person is ready to watch them. If you need both, use two servers or two configs: a wide reader and a narrow writer.

Never paste secrets into the thread to "just connect it." Tokens, personal access credentials, and session cookies belong in the host's server settings, not in Claude, ChatGPT, Cursor, or Copilot chat. Once a secret is in the transcript, the real scope is every later reader of that chat, including exports and logs you do not run.

Standing briefing text is not a server. If the need is "keep this background in one place," use a project or similar workspace. AI Projects hold durable context. MCP holds live lookups. Connecting a server and also pasting the same corpus into the project doubles exposure without adding a new source of truth.

If you cannot state the slice in one sentence, you are not ready to connect. "The whole company Git org" is a scope. It is rarely the scope you want on day one.

Attach one server that matches the boundaries you wrote. In the host, confirm the server is live and that the tool list matches what you allowed. An empty tool list means stop. An assistant with no tools will answer from general knowledge and will sound sure.

Ask in a way that forces the three-part citation. One illustration: a knowledge worker needs the owner of payments on-call before they page. They connect a read-only directory or wiki server limited to the operations space. They ask the assistant to search that server, only inside the operations space, then get the record and report the server name, the allowed space, and the record id. They do not ask the model to open org/backend/docs/oncall.md unless a tool already returned that path. Inventing a repository path is how disconnected sessions fake a lookup. If the tools return nothing, they use the runbook they already trust. They do not paste the directory credential into chat. They do not invent /wiki/ops/oncall-payments.md. They do not fill an owner name from memory and attribute it to the server.

If you have a choice among AI assistants, choose the host that can attach the server you already scoped. Changing host does not enlarge the server's permission. It only changes which client is talking to it.

Call listed tools only. If update is not in the list, do not ask the model to "edit the page anyway." If get returns a title and no assignee, do not complete the assignee.

Disconnected, unauthenticated, and error are success states for honesty. When the server is off or the tool fails, the facts that would have come from the tool stay blank. "No record from the server" is a complete answer. A reconstructed folder tree is not.

The pressure to fill blanks is social. Empty looks like the assistant failed. Operators then supply a path they remember from last quarter. Models then supply a ticket prefix that looks local. Neither object is auditable, because it never passed through the server.

MCP is for repeating a scoped lookup without putting the corpus in the prompt. It is not a simulated filesystem. If you need the answer badly enough to guess, open the source system yourself and skip the tool call.

The same rule applies inside a record. A tool that returns a title without an assignee does not imply you. Leave the assignee empty. Cite what the server returned. Omit what it did not.

Reads may run once the server is connected. Writes wait. A create or update tool can return a payload, a diff, or an object that looks like success. Treat it as a draft. A person still approves the write: they confirm the target record, the fields that will change, and that the server in use is the write-enabled config, not the read-only twin.

The matching failure is treating a tool result as already written. Someone asks to file an incident update. The model formats a paragraph, or describes a tool call, or even receives a tool payload. The operator sees tidy markdown and assumes the wiki moved. The live page is unchanged. Require a visible round trip: tool name, arguments, result, then a human confirm in the client or a manual save in the source system if the client cannot commit.

Keep write scope smaller than read scope. A server that can search an org should not also edit it by default.

If you later add workflow automation on the same systems, wait until the MCP path is boring: same server, same allowed tools, same empty-on-failure rule, and a person still on every write. After an approved change, you should still be able to name the server, the allowed scope, and the source record. If you cannot, the change happened in chat, not through MCP.