🔌 MCP Server Prompt Engineering (Claude / Cursor / Custom)

What MCP Actually Is

MCP (Model Context Protocol) is Anthropic's open standard (released November 2024) for connecting AI assistants to external tools, data sources, and services. The key differentiation:

• NOT ChatGPT plugins: OpenAI's plugin system was OpenAI-specific, deprecated. MCP is open spec.
• NOT generic function-calling: Function-calling is at the API level. MCP standardizes the SERVER side — how tools expose capabilities to ANY MCP-aware client.
• NOT magic: MCP is plumbing. It standardizes the connection so any MCP server works with any MCP client. The prompt-engineering work is the same as before.

Three capability types in MCP:

1. Tools: actions Claude can execute (run a query, create a ticket, send a message)

2. Resources: data Claude can read (file contents, API responses, structured data)

3. Prompts: templated instructions the server provides (parameterized prompt templates)

For your use case, you'll mostly use Tools + Resources.

Your Use Case Mapped

You want three integrations:

1. Linear search: Tool (search issues) + Resource (read issue content). PRE-BUILT MCP SERVER EXISTS.

2. Postgres read-only queries: Tool (execute query) + Resource (schema introspection). PRE-BUILT MCP SERVER EXISTS.

3. GitHub PR statuses: Tool (search PRs, check status). PRE-BUILT MCP SERVER EXISTS.

Good news: all three have pre-built servers. No custom server needed.

Pre-Built Server Recommendations

For Linear:

• @modelcontextprotocol/server-linear (community, well-maintained)
• Auth: Linear API key

For Postgres:

• @modelcontextprotocol/server-postgres (official Anthropic example)
• Auth: Postgres connection string
• READ-ONLY by default — exactly what you want for safety

For GitHub:

• @modelcontextprotocol/server-github (official Anthropic example)
• Auth: GitHub Personal Access Token (PAT)
• Scope it to read-only for safety

All three are TypeScript-based, run via npx. No custom code needed.

Configuration for Cursor IDE

Cursor's MCP config is at ~/.cursor/mcp.json (or per-project .cursor/mcp.json). For your three integrations:

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-linear"],
      "env": {
        "LINEAR_API_KEY": "lin_api_xxxxx"
      }
    },
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://readonly_user:password@localhost:5432/mydb"
      ]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxx"
      }
    }
  }
}

Key notes:

• Use a READ-ONLY Postgres user (create one specifically for this if you don't have one)
• GitHub PAT scope: repo:status, public_repo minimum; repo if you have private repos. Don't grant write scopes unless needed.
• Linear API key has full account scope by default — if your team allows, use a dedicated bot-user account, not your personal one.

After saving config: restart Cursor. The integrations will appear in the MCP indicator.

Prompt-Engineering for This Setup

With all three connected, Claude in Cursor can be invoked with prompts like:

Pattern 1 — Single-tool query:

'Find all my Linear issues in 'In Progress' status assigned to me. List issue IDs + titles + age.'

Claude knows to use the Linear tool. Output is structured.

Pattern 2 — Multi-tool workflow:

'For each open PR I have on GitHub, find the corresponding Linear issue (search by PR title or branch name) and tell me which ones have stale 'In Progress' Linear status (>3 days since last update).'

Claude orchestrates: GitHub tool to list PRs → Linear tool to search per PR → reasoning to identify stale ones.

Pattern 3 — Investigate + propose:

'Query the users table — show me the schema first, then count users created in last 7 days. Then in Linear, find any issues mentioning 'user growth' and tell me if my query results align with what's claimed in those issues.'

Claude uses Postgres tool for schema + query, Linear tool for issue search, reasoning to compare.

Best practices for MCP-aware prompts:

1. Be explicit about which tool you want used. Claude can guess but is more reliable when told. 'Use the Postgres tool to...' beats ambiguous instruction.

2. Specify output format. 'Return as a markdown table with columns X, Y, Z' produces consistently better results than open-ended.

3. Instruct on failure handling. 'If the Linear query returns no results, say so explicitly rather than inferring.'

4. For multi-step workflows, break into explicit steps. 'First, do X. Then do Y. Then summarize.' beats 'Do X, Y, and Z' which can lead to skipped steps.

5. For Postgres specifically: specify SAFE queries. 'Read-only SELECT only, no UPDATE/DELETE/DROP, limit to 100 rows.' Defense in depth — your DB user should already be read-only, but tell Claude too.

Custom Server Approach

Not needed for your use case (all three integrations have pre-built servers). But for when you DO need custom:

TypeScript SDK starter: @modelcontextprotocol/sdk package. Anthropic's official docs walk through a basic server. Key abstractions:

• Server class for the server itself
• setRequestHandler for routing tool/resource/prompt requests
• Schema definitions for tools (using Zod or JSON Schema)
• StdioServerTransport for local development; HttpServerTransport for hosted

Common gotchas:

• Tool input schemas must be valid JSON Schema or Zod schemas. Sloppy schemas → bad tool-calling.
• Resources should support pagination if data is large.
• Errors must be returned in MCP error format, not raw exceptions.
• For long-running tools: implement progress reporting via the Server's notification API.

Common Failure Modes + Mitigations

Server crashes / hangs:

• Cursor will show stale state or timeout errors
• Mitigation: restart Cursor; check server logs in ~/Library/Logs/Cursor/ (Mac) or equivalent
• Pre-built servers via npx generally stable; custom servers are where most crashes happen

Auth failures:

• 'Tool returned error: Unauthorized' or similar
• Mitigation: verify API keys / tokens are current. Linear API keys can expire. GitHub PATs auto-rotate if you have policies.

Rate limits:

• GitHub: 5000 req/hour per token
• Linear: 1500 req/hour per API key
• Postgres: depends on your DB config
• Mitigation: Don't have Claude run query loops without limits. 'Search top 10 issues' beats 'fetch all issues'.

Schema-mismatch:

• Tool expected X, Claude sent Y
• Mitigation: pre-built servers usually handle this; for custom servers, fail loud with clear error messages.

Security + Permissions Considerations

For your stack:

1. Postgres user permissions: Create a dedicated `readonly_claude` user with SELECT-only permissions. Revoke INSERT/UPDATE/DELETE/DROP at the role level. Don't rely on prompt-engineering for safety.

2. GitHub PAT scoping: `public_repo + repo:status` if you only need PR status. Add `repo` only if you need private repo access. Avoid `admin:org`, `delete_repo`, etc.

3. Linear API key: scope to a dedicated Linear user/account if possible. Use 'Workspace API key' rather than personal API key when team-shared.

4. Secrets management: Don't commit `mcp.json` to your repo. Add to .gitignore. Consider environment variables or a secrets manager (1Password CLI, etc.) for team setups.

5. Audit log review: Linear, GitHub, Postgres all have audit logs. Periodically review what your MCP tokens have done.

On Your Key Question

Direct:

1. All three integrations are pre-built. No custom servers needed. Use the npx-based configs in the JSON above.

2. Cursor setup: drop the JSON into `~/.cursor/mcp.json`, restart Cursor. Each integration shows up after restart.

3. Best prompt patterns: be explicit about which tool to use, specify output format, instruct on failure handling. Multi-tool workflows benefit from explicit step-breakdown.

4. Safety: read-only Postgres user is the most important security move. Don't trust prompt-engineering to enforce 'no DELETE.' Enforce it at the DB role level.

5. Start with one integration, prove value, then add the others. Setting all three at once + getting them all wrong is harder to debug than incremental.

Specific suggested order: Postgres first (highest leverage for backend engineer + most error-prone), Linear second, GitHub last.

What MCP Won't Solve

MCP is plumbing. It doesn't fix:

• Bad prompt-engineering (vague instructions, no output format)
• Bad data architecture (your Postgres queries are only as good as your schema)
• Bad tool selection (Claude using wrong tool for the job)
• Bad permissions (over-scoped tokens are the same risk as before)

MCP standardizes the CONNECTION. The craft of using AI well still requires the same prompt-engineering, security, and architectural thinking as before. Don't expect MCP to make Claude smarter; expect it to make Claude's TOOLS more standardized.