By May 2026, builders integrating their agent with a new piece of functionality face the same three-way decision dozens of times per year: should this be an MCP server, a custom tool, or a Skill? The wrong choice is rarely catastrophic — it works, but it costs more to maintain, ships slower, or fits the team's workflow poorly. The right choice is usually obvious once you align the packaging with three dimensions: the reuse horizon, the system access shape, and the team that will maintain it. This lesson is the explicit decision tree for picking the right packaging, with named example scenarios for each branch, the common mis-pickings we've observed, and a framework you can use to revisit existing choices when a team's needs change.

The Three Packaging Options

Before the decision tree, a one-screen definition of each option so the rest of the lesson can use precise vocabulary.

MCP server

A standalone process (Node, Python, Go binary, or hosted HTTPS endpoint) that exposes a catalog of tools to any MCP-speaking host. Lifecycle: installed once, used by many agents across many teams. Strength: cross-team reusability and cross-host portability. Built when: the underlying system will be touched by multiple agents and you want one canonical interface.

Custom tool

A function inside your agent framework (LangGraph node, LangChain Tool, CrewAI Task, n8n Code node, Make function, Zapier app action) that the agent can call. Lifecycle: lives in your agent code, often single-purpose. Strength: zero packaging overhead, full integration with your runtime's data model. Built when: you need one specific action, in one specific agent, and the action is platform-specific or one-off.

Skill

A SKILL.md folder containing instructional guidance and optional attached resources. Lifecycle: travels with the model across hosts; loaded conditionally when its description matches a request. Strength: portable instructional packaging that doesn't run code, just shapes behavior. Built when: you want the model to follow a specific procedure when a category of request arrives, and the procedure is the value (not the system access).

The three are complementary, not exclusive. A real production agent typically uses all three. A Skill says what to do, a tool/MCP says how to act on the world, and your prompt says who you are and what you're constrained by.

The Decision Tree

For any new piece of functionality, walk this tree in order. The first answer wins.

Question one: does it need to call an external system?

If no — the work is purely "shape the model's behavior on a category of input" — it's a Skill. Stop here. Examples: write changelog entries from Linear tickets, draft Slack code-review replies, fill the postmortem template. The model is doing the work; no API call is involved.

If yes, continue.

Question two: will this functionality be reused by multiple agents or teams?

If no — it lives inside one agent, owned by one team, and other teams don't need it — it's a custom tool. Stop here. Examples: this specific agent's "look up a record in our internal database that no one else uses," this specific n8n workflow's "format the email per our team's template."

If yes, continue.

Question three: is there an existing official MCP server for the underlying system?

If yes — Atlassian, Stripe, Notion, etc. from the official-server list — install the official MCP server. Stop here. Do not build a custom alternative; you'll trade your reuse benefit for maintenance burden.

If no — the system doesn't have an official MCP server — continue.

Question four: is the underlying system internal to your organization, or external?

If internal (a custom service your team built) — and the answer to question two was yes (multiple agents need it) — build a custom MCP server for the internal system. Cost: 1-3 days of engineering plus ongoing maintenance. Benefit: any current or future agent at your company that needs this system gets a clean, standard interface.

If external — and there's no official MCP server — you have three options in priority order: (a) check if Zapier MCP wraps the system and use that as a fallback, (b) if Zapier MCP doesn't fit and reuse is high, build a custom MCP server for the external system, (c) if reuse is uncertain, build a custom tool for now and migrate to MCP when reuse becomes clear.

The decision tree is intentionally biased toward "official MCP first, Zapier MCP second, custom MCP third, custom tool fourth, Skill never for system access." The bias reflects the maintenance-cost arithmetic: custom tools accumulate. By the time you have 30 custom tools sprinkled across five agents, the maintenance burden exceeds what a few MCP servers would have cost upfront.

The Reuse Horizon Test

Question two — "will this functionality be reused?" — is the highest-leverage question in the tree. It's also the easiest to answer wrong, because builders are systematically optimistic about future reuse and pessimistic about future maintenance.

A clarifying test: imagine 90 days from now. How many distinct agents in your organization will need this functionality? Three honest answers:

• Zero or one other agent. Build a custom tool. The reuse premium of MCP doesn't pay off.
• Two or three other agents. Borderline. Build a custom tool now; refactor to an MCP server when the second agent actually needs it. Don't build the server until reuse is demonstrated.
• Four or more agents, or you can name them by team. Build the MCP server. The cross-team coordination cost without MCP exceeds the server-build cost.

A second clarifying test: who else needs to know how to call this? If only your team — custom tool. If multiple teams need to discover and use this — MCP server. The discoverability of an MCP server (it shows up in the host's tool catalog automatically) is one of its highest-value properties.

The honest test for "should this be an MCP server" is whether someone outside your team would find and use it. If not, you're paying the MCP overhead for a benefit you won't realize. Build the custom tool first; promote to MCP when reuse arrives.

The System Access Shape Test

Some functionality is borderline between "system access" and "instructional behavior." A common mis-picking: building an MCP server for something that should be a Skill because the author saw a vendor API and assumed the wrapper had to be an MCP server.

Example: "generate a one-page customer brief from our CRM." The temptation is to build an MCP server for the brief generation. But the brief generation is not system access — it's a procedure that takes already-fetched CRM data and shapes it into a brief. The right packaging is: an existing Salesforce/HubSpot MCP server (for fetching the data) plus a Skill (for the brief-generation procedure). The Skill says "when the user asks for a customer brief, fetch the CRM data via available MCP tools, then format using these rules"; the MCP server stays generic.

Another example: "send a templated thank-you Slack message after a deal closes." The temptation is to build a custom tool that does the whole thing. But the action is just "post Slack message" — the templating is a Skill. The right packaging: Slack MCP server (for posting) plus a Skill (for the templating rules).

The test: if the work is "decide based on context and shape an output," it's a Skill. If the work is "call a system and return data," it's a tool/MCP. Most non-trivial agent tasks combine both — the Skill orchestrates which tools to call and how to format the result.

The Maintenance-Cost Test

Each packaging has different ongoing maintenance:

MCP server

Maintenance items: API contract changes from the underlying system, OAuth token rotation, dependency upgrades, security patches, schema-validation updates as the vendor evolves the API, on-call when the server's downstream system has an incident. For a vendor-maintained official MCP server, the vendor absorbs most of this. For a custom internal MCP server, your team carries all of it. Budget roughly 0.1-0.2 FTE per non-trivial internal MCP server.

Custom tool

Maintenance items: API contract changes (same as MCP), framework upgrades (LangGraph or whatever you're on), tight coupling to your agent's data model means refactors propagate. Per-tool cost is lower than per-MCP cost but the tools multiply — many small tools have more total maintenance than fewer well-designed MCP servers.

Skill

Maintenance items: when the model changes (Sonnet 4.5 → Sonnet 5), behavior may shift, requiring Skill body revisions. When the team's process changes (new style guide, new template), Skills need updating. Skills are the cheapest to maintain in absolute terms but have higher "behavior surprises" risk because they're language-mediated.

If your team has limited operator-engineering bandwidth and a high tolerance for "behavior consistency varies," Skills are the right cost-effective default. If your team needs strict consistency and can absorb the engineering work, MCP servers concentrate the maintenance into fewer surfaces.

Six Named Scenarios Walked Through

Real scenarios from teams we've observed. For each, the right packaging plus the reasoning.

Scenario one: "create a Jira issue from a Slack message"

System access: yes (calls Jira's REST API). Reuse: yes (every agent at the company that touches engineering tickets needs this). Existing official MCP: yes (Atlassian MCP). Packaging: install Atlassian MCP server. Effort: 6 minutes including OAuth. Common mis-pick: building a custom n8n HTTP node that calls Jira directly — works but creates a separate maintenance surface that other agents at the company can't reuse.

Scenario two: "generate a customer-facing changelog entry from a Linear ticket"

System access: yes (calls Linear's API to fetch the ticket). Reuse: ticket fetching has reuse. Brief generation procedure: limited reuse but high value when invoked. Packaging: Linear MCP for the fetch + Skill for the procedure. Common mis-pick: stuffing both fetching and formatting into one custom tool — works but the brief-generation logic is locked inside the tool and harder to refine.

Scenario three: "look up a record in our internal customer-success database"

System access: yes (internal Postgres). Reuse: just this one customer-success agent for now. Packaging: custom tool in the agent framework. Common mis-pick: building a custom MCP server for the internal DB on day one — over-engineering, since reuse hasn't been demonstrated. Refactor to MCP when a second agent needs this.

Scenario four: "anonymize customer names in any document"

System access: no (purely text transformation by the model). Reuse: high (everyone in the org might want this). Packaging: Skill. Common mis-pick: building a tool that calls a regex-based anonymizer — works for trivial cases but breaks on contextual cases (pronouns referring to named entities) that the model handles naturally.

Scenario five: "post a daily revenue snapshot to a Notion page"

System access: yes (Stripe + Notion). Reuse: this specific reporting flow is the only consumer. Packaging: Stripe MCP + Notion MCP (both official) + a custom tool or Skill for the orchestration. Common mis-pick: building a single monolithic custom tool that does it all — works but couples three orthogonal concerns (data fetch, formatting, write-back).

Scenario six: "check our internal CI status before approving a deploy"

System access: yes (internal CI's REST API). Reuse: every deploy-aware agent the company has. Packaging: custom MCP server for the internal CI. Effort: 1-2 days. Common mis-pick: building it as a custom tool in just one agent — works but the next agent that needs CI status has to re-build it.

When to Revisit Old Decisions

Packaging choices aren't permanent. Three signals that an existing packaging should be promoted or demoted:

Promote custom tool to MCP server

When: a second agent needs the same functionality. Or: the custom tool's coupling to your agent framework becomes painful when you want to use the agent in a different host. Or: another team's agent could benefit from the same access. The migration is usually straightforward; the work is moving the logic out of the agent framework's tool definition and into a standalone MCP server that exposes the same surface.

Demote MCP server to custom tool

When: the MCP server is used by only one agent and the cross-host portability has no realized value. The overhead of maintaining a server isn't paying for itself. Less common but does happen — a team built an MCP server speculatively, no one else adopted it, the maintenance cost stopped being worth it. Move the logic back into the agent and retire the server.

Convert tool/MCP behavior into a Skill

When: the "what to do with the data" logic was inside the tool's implementation but it's actually instructional procedure, not system access. Pulling it out into a Skill makes the tool generic (and more reusable) and the procedure portable.

Three Mis-Pick Stories

Story one: the unnecessary MCP server

A 70-person engineering org built a custom MCP server for "our internal feature-flag system." It was elegantly designed and well-documented. Six months later, only one agent had ever used it — the original team's agent. The maintenance team had been carrying 0.15 FTE of work on the MCP server for an audience of one. After a quarterly review, they migrated the logic back into the agent's framework as a custom tool and retired the MCP server. Lesson learned: build for demonstrated reuse, not aspirational reuse.

Story two: the MCP server that should have been a Skill

A 30-person consultancy built an MCP server that exposed a tool called generate_executive_summary. The tool's implementation was 400 lines of prompting logic plus a call to Claude's API. Every invocation cost ~$0.30 and took 8 seconds. After a usage review, they realized the tool was effectively a Skill in disguise — the value was in the prompting logic, and the model was making the actual call internally anyway. They converted it to a Skill, dropped per-invocation cost to roughly $0.04 (because the prompting was now done by the user's model, not a separately-invoked one), and removed the entire MCP-server-deployment infrastructure. Lesson learned: if your tool's implementation is mostly prompting, it's a Skill.

Story three: the Skill that should have been a tool

A 12-person agency built a Skill called parse_invoice that instructed the model to extract structured data from invoice text. The Skill worked but produced varying outputs across runs (model variability on numeric fields, occasional field-name drift). After moving the parsing to a deterministic Python tool that the agent could invoke, the variability went to zero and downstream consumers (which expected exact JSON shapes) stopped failing intermittently. Lesson learned: anything requiring deterministic output should be a tool, not a Skill. Skills are for behavior shaping, not for deterministic computation.

A Checklist for Each Decision

For every new piece of functionality, run this quick checklist:

1. Does it need to call an external system? If no → Skill.
2. Will it be reused by 4+ agents in 90 days? If no, plus the system is external → custom tool. If yes → continue.
3. Is there an official MCP server? If yes → install it. If no → continue.
4. Is the system internal? If yes → custom MCP server. If no → Zapier MCP if it fits, else custom MCP server, else custom tool with migration plan.
5. Is the "decide and shape output" logic high-value? If yes → also write a Skill that orchestrates the tools.
6. Is the output required to be deterministic? If yes → ensure it goes through a tool, not a Skill.
7. Document the decision in your team's packaging-decision log so future reviewers can revisit.

Aligning with the Team

The decision tree is technical, but the choice has team-process implications. Three coordination notes:

• MCP servers need owners. Every MCP server in your stack has a named maintainer. If no one will own it, don't build it.
• Skills need authors. Every Skill has a named author who will keep it current. Anonymous Skills decay.
• Custom tools need framework reviewers. When custom tools accumulate, periodic review catches duplicates and identifies promotion candidates to MCP servers.

The packaging decision is also a maintenance-commitment decision. Builders who skip this step accumulate technical debt that surfaces during the next agent build, when the team realizes they have 14 ways to talk to Salesforce and three of them are subtly inconsistent.

Key Takeaways

• Three packaging options, complementary not exclusive. MCP server: cross-team reusable system access via a published catalog. Custom tool: in-framework function for one-agent or one-platform actions. Skill: portable instructional packaging for behavior shaping.
• The decision tree, in order. (1) No external system → Skill. (2) No reuse beyond one agent → custom tool. (3) Official MCP exists → install it. (4) Internal system with reuse → custom MCP server. (5) External system without official MCP → Zapier MCP, then custom MCP for high reuse, else custom tool with migration plan.
• The reuse-horizon test. Ask: how many agents need this in 90 days? 0-1 → custom tool. 2-3 → custom tool now, refactor when reuse demonstrated. 4+ or nameable cross-team → MCP server. Discoverability via tool catalog is one of MCP's highest-value properties.
• The system-access-shape test. If the work is "decide and shape output" → Skill. If the work is "call a system and return data" → tool/MCP. Most non-trivial tasks combine both; let the Skill orchestrate and let MCP/tools handle access.
• Maintenance-cost arithmetic. Vendor-maintained MCP: nearly free for you. Internal MCP: 0.1-0.2 FTE per non-trivial server. Custom tools: lower per-tool cost but they multiply. Skills: cheapest in absolute terms but higher behavior-surprise risk.
• Common mis-pickings. Building a custom HTTP node when an official MCP exists. Building an MCP server for something that should be a Skill (mostly prompting logic). Stuffing fetching and formatting into one tool when they should be separated. Writing a Skill for deterministic computation (use a tool instead).
• Six named scenarios with right packaging. Jira-from-Slack → Atlassian MCP. Linear-to-changelog → Linear MCP + Skill. Internal CS DB lookup → custom tool. Anonymize names → Skill. Daily revenue snapshot → Stripe MCP + Notion MCP + orchestration. Internal CI status → custom MCP server.
• Three mis-pick stories. The 0.15-FTE MCP server with audience of one (migrated back to custom tool). The MCP server that was actually a Skill in disguise (saved $0.26/invocation by converting). The Skill that should have been a tool (deterministic JSON required a Python parser).
• Revisit decisions when signals appear. Promote tool to MCP when a second agent needs the same functionality. Demote MCP to tool when reuse never materialized. Convert tool/MCP behavior to Skill when "what to do" is the value and access is generic.
• Packaging-decision log is the team-process equivalent of the technical tree. Every choice documented, every owner named, periodic reviews to catch debt. Skipping this accumulates 14 ways to talk to Salesforce — three of them subtly inconsistent.