Model Context Protocol makes it easy to give an assistant access to your systems. Easy enough that the first instinct is to wire up everything. Six months and five servers later, the split between useful and ignored is sharper than I expected.
The two that stuck
PostgreSQL, read-only. The value is not writing queries — it is that a question like "why does this order have two shipment rows" gets answered against the actual database in one step, instead of a round trip through me. Read-only is what makes it comfortable: the worst outcome is a slow query, not a mutated table.
Jira, scoped to one project. Almost entirely because of one operation: reading a ticket and its comments before starting work. The context that lives in a comment thread — the decision someone made in March, the edge case QA found — is exactly what a fresh session lacks.
The three that did not
Bitbucket write access. Creating PRs from a session sounds useful. In practice, I want to read the diff myself before it goes anywhere, so the write path just added a permission prompt to a flow I was going to complete manually.
A metrics dashboard. Metrics answer "is it broken", and I already have alerts for that. The queries an assistant would help with are exploratory, and exploration needs a chart, not a JSON blob.
A generic HTTP client. This one is a trap. It can call anything, so it describes nothing.
A tool named fetch_url gives the model no signal about when to use it. Narrow tools with
honest names get picked correctly; generic ones get picked at random.
The pattern
The servers that earned their place share a shape: read-heavy, narrow scope, and they retrieve context that is expensive for a human to gather but cheap for a machine. The ones that failed either duplicated something I wanted to do deliberately, or were so general that choosing them correctly was itself the hard part.
If a server's description needs the word "any", it is probably too broad to be useful.