MCP guide for teams

MCP architecture

MCP helps an assistant discover structured tools and context from systems it should interact with. The point is not to make the assistant magical; the point is to make access explicit, governed, and easier to audit.

In a typical MCP setup, the host is the AI application, the server exposes tools or resources, and the client connects them. The assistant can query available tools, receive structured responses, and decide what to do next. All of this happens through a defined protocol rather than ad-hoc integrations.

What to connect

• Read-only docs or knowledge stores.
• Task systems or project trackers.
• Developer tools, repos, or local files.
• Business systems that need an approval step before writes.

Permission model

Security considerations

Connecting AI to real systems creates real risk. Treat MCP integrations like any other API or automation layer.

• Least privilege: Give the assistant only the permissions it needs.
• Audit logging: Record what tools were called, with what inputs, and by which user.
• Scope boundaries: Limit which tools are available in which conversations or contexts.
• Human gates: Require approval before destructive or customer-facing actions.
• Credential hygiene: Rotate keys, use scoped tokens, and avoid sharing credentials across environments.

Integration map

Use this map when planning an MCP integration:

1. Define the workflow: What is the input, decision, and output?
2. Choose the tool surface: Which system holds the data or action?
3. Decide the permission level: Read, draft, approve, or write?
4. Build the MCP server: Expose the tool with clear schemas and descriptions.
5. Test in isolation: Verify tool calls and responses before connecting the assistant.
6. Add logging and review: Make sure every action is traceable and reversible.

MCP is not a replacement for good API design or security practices. It is a protocol that makes tool access explicit. The hard work of permissions, testing, and review still belongs to the team.

Setup example

Here is a sample Claude Desktop configuration that connects a Postgres MCP server. Use read-only credentials and restrict the schema the server can access.

Package choice matters. The old reference server @modelcontextprotocol/server-postgres was archived in 2025 and has an unpatched SQL-injection issue that bypasses its read-only mode — do not install it. A maintained option is Postgres MCP Pro, which enforces restricted (read-only) mode by parsing statements, not just wrapping them in a transaction:

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": {
        "DATABASE_URI": "postgresql://readonly_user:pass@localhost:5432/dbname"
      }
    }
  }
}

Install it with pipx install postgres-mcp (Python 3.12+) or run the crystaldba/postgres-mcp Docker image. Two extra precautions: always pass --access-mode=restricted (the default is unrestricted read/write), and connect with a database role that has SELECT-only grants — server-level read-only is a seatbelt, not a wall.

For step-by-step setup guides, see Postgres MCP server, GitHub MCP server, and Slack MCP server. To build your own, see Build an MCP server.

Troubleshooting

• Server not found: Verify the command path and that the package is installed globally or via npx.
• Permission errors: Use scoped credentials. Never give an MCP server broader access than the workflow needs.
• Slow responses: Reduce the data returned per tool call or cache read-only results.
• Unexpected tool calls: Check the tool description and schema. Ambiguous descriptions lead to wrong invocations.