TL;DR: Both Linear and GitHub publish official MCP servers. Install via npm i -g @linear/mcp-server (and equivalent for GitHub), add an entry to ~/.lingcode/mcp.json with your API token, and the agent can search issues, open PRs, and read ticket context directly.
Two of the most useful real MCP servers for everyday engineering: GitHub and Linear. After this tutorial, "find the ticket about the rate limiter," "open a PR for these changes," and "what's still in this sprint" are one prompt each.
The abstract MCP tutorial covers the protocol. This one is concrete. Most engineers' work is intertwined with two services LingCode doesn't natively know about: the issue tracker (Linear, in this example β the same shape applies to Jira/Asana/etc.) and the source forge (GitHub, equivalently for GitLab/Bitbucket). The agent can do good work without these β but with them, every "look at the ticket and decide what to build" turn becomes one prompt instead of three.
Both Linear and GitHub publish MCP servers as npm packages. They're the same shape: install the package, generate a personal API token, paste the token into mcp.json, restart your chat. The friction is in the credential setup more than in the MCP wiring; you do that part once per service and never again.
The reason this is worth doing as a single tutorial β rather than two separate ones β is that the workflows compose. The agent that can read a Linear ticket and open a GitHub PR is meaningfully different from one that can do either alone. "Implement what this ticket asks for, then open a PR linking back to the ticket" becomes one prompt. That's the payoff.
mcp.json entries for both serversSign in to Linear. Click your avatar β Settings β API β Personal API keys. Click Create key, name it (e.g., "LingCode"), pick the scope.
The key inherits your user's permissions. If you're an admin, the key is admin. If you have read-only access to certain workspaces, the key respects that. Scope at the user level, not the key level.
Copy the key β it's shown once. lin_api_β¦.
Go to GitHub β Settings β Developer settings β Personal access tokens β Fine-grained tokens. Generate a new token. The important fields:
Copy the token β github_pat_β¦.
In ~/.claude/mcp.json (user-wide is right here β these are personal-account tokens):
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "github_pat_..."
}
},
"linear": {
"command": "npx",
"args": ["-y", "mcp-server-linear"],
"env": {
"LINEAR_API_KEY": "lin_api_..."
}
}
}
}
Both use stdio transport, both spawn via npx (so you don't have to install the packages globally β npx fetches and runs). Tokens go in the per-server env, never in shared shell config.
Open a chat and ask: "What Linear tickets are assigned to me?" The agent picks the tool, you get a permission prompt naming mcp__linear__list_issues with the arguments it's about to pass. Approve.
The first call per server warms up: npx downloads the package (one-time delay), the server starts, registers its tools, executes the call. Subsequent calls in the session are fast.
Do the same for GitHub: "List the open PRs on org/repo." Approve when prompted. From here, both servers are live.
The payoff for connecting both is composition. Try:
"Read Linear ticket ACME-1234, then look at the code, implement what the ticket describes, open a draft PR linking back to the ticket."
The agent calls Linear to read the ticket, the local file tools to look at and edit code, and GitHub to open the PR. Four tool families in one turn, all with structured arguments and structured results. The PR description references the Linear ticket; closing the PR can be configured to update the ticket status, depending on your Linear settings.
If you'd usually have spent ten minutes context-switching between three tools, you've spent zero.