Your team needs Jira integration for an agentic workflow. There's a well-maintained community MCP server for Jira that supports the standard operations the team needs (create issue, update status, query by JQL, add comment). A teammate proposes building a custom in-house MCP server "for full control."
What's the right call?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Default to community MCP servers for standard integrations. They're maintained, tested, and benefit from the community's collective debugging. Custom development is justified for team-specific workflows that the community version doesn't cover — not for the standard create/update/query operations every team needs. The "full control" argument usually masks unfamiliarity with the existing tool.
"Full control" sounds like a virtue, but it comes with full maintenance burden — every update, every Jira API change, every security patch is on you. For standard operations that the community version handles well, this is paying high cost for no real gain.
An immediate fork creates an unmaintained branch that diverges from upstream. You inherit the codebase plus the obligation to track upstream changes, with none of the benefit of community maintenance. Forks are appropriate when the upstream is genuinely insufficient — not as a default posture.
Dropping MCP for direct REST calls forfeits the protocol's actual value — structured tool descriptions, the isError flag, resource catalogs, scoped configurations. You're trading a designed integration layer for ad-hoc shell calls.