Tools, MCP, Skills, and Plugins

Tools are where an agent stops talking and starts doing.

A tool might search files, query a database, create a ticket, run tests, send an email, open a browser, call another agent, or load a capability that was not available when the run began. That power is exactly why tool design is one of the highest-leverage parts of agent engineering.

Bad tools make capable models look clumsy. Good tools make smaller systems surprisingly competent.

Level 1: Fundamentals

OpenAI's tools docs describe several ways to extend model capability: built-in tools, function calling, remote MCP servers, file search, web search, deferred tool definitions, and custom functions [1]. The important idea is that the model does not need to contain every capability. It can call out to systems that retrieve, compute, inspect, or act.

MCP, the Model Context Protocol, standardizes one large part of this story. The 2025-06-18 MCP specification describes MCP as an open protocol for integrating LLM applications with external data and tools, using JSON-RPC 2.0 and a host/client/server model [3].

Skills and plugins sit at a different layer. In this course, a skill is a reusable instruction package for a task pattern: how to write a research blog post, convert Markdown to HTML, read a PDF, or build a site. A plugin is a larger bundle that may expose skills, MCP servers, apps, or other runtime capabilities.

The stack looks like this:

tool: a callable capability
MCP server: a standardized provider of tools/resources/prompts
skill: reusable task instructions and workflow knowledge
plugin: packaged extension that can include skills, tools, apps, and MCP servers

The Hitchhiker guide frames MCP as a way to reduce tool-integration fragmentation: instead of every host integrating separately with every external system, MCP moves the ecosystem toward reusable servers and clients [6].

Level 2: Concepts

The first design choice is to classify tools by consequence.

Tool Type	Example	Risk Profile
Read-only data	search docs, inspect file, list tickets	low to medium
Computation	run parser, convert file, calculate quote	medium
Environment action	edit file, run shell, browse website	medium to high
External side effect	send email, refund order, deploy service	high
Orchestration	call agent, spawn subtask, handoff	variable and compounding

Tool descriptions should say what the tool does, what it does not do, and what the model should provide. Anthropic calls this "agent-computer interface" work: tool interfaces and documentation are part of the system design, not an afterthought [5].

MCP

MCP has three roles:

• host: the LLM application the user interacts with
• client: the component inside the host that connects to an MCP server
• server: the process or service that exposes capabilities

The specification includes tools, resources, prompts, roots, sampling, and elicitation as protocol capabilities [3]. In practical terms, this means an agent host can discover and call external capabilities through a shared protocol instead of a custom integration for every data source.

OpenAI's integrations docs describe both hosted MCP tools and SDK-managed MCP connections over stdio or streamable HTTP, with tracing to inspect what happened during a run [2]. That is the production pattern: protocol-based capability plus observability.

Skills

Skills are not the same as tools. A tool is called during execution. A skill tells the agent how to approach a class of tasks.

For example, a Markdown-to-HTML tool could convert a file. A Markdown-to-HTML skill says how to structure the article, what CSS expectations matter, how to handle references, how to verify the result, and which script to run.

Skills are useful when the agent needs:

• task-specific workflow memory
• local conventions
• reference files
• examples and templates
• validation steps
• constraints that should apply before tool use

Claude Code's docs describe related extension ideas such as CLAUDE.md, MCP, skills, hooks, and custom workflows [4]. The ecosystem vocabulary differs, but the architectural role is familiar: package reusable context and capability so the agent can do specialized work more reliably.

Plugins

Plugins are packaging. They are useful when a capability needs to be installed, versioned, discovered, enabled, or shared.

A plugin can contain:

• one or more skills
• MCP server configuration
• app connectors
• templates
• scripts
• assets
• metadata for discovery

The danger is treating plugin installation as trust. A plugin is supply chain. If it gives the agent tools, it can expand what the agent is able to do. If it gives the agent instructions, it can influence how the agent reasons. Installation, permissions, versioning, and provenance matter.

Level 3: Engineering Detail

A good tool is narrow, typed, permissioned, observable, and recoverable.

Tool Schema

{
  "name": "lookup_invoice",
  "description": "Read invoice metadata for a customer account. This tool does not modify billing state.",
  "input_schema": {
    "type": "object",
    "required": ["customer_id", "invoice_id"],
    "properties": {
      "customer_id": {"type": "string"},
      "invoice_id": {"type": "string"}
    },
    "additionalProperties": false
  },
  "permission": "read_customer_billing",
  "side_effects": "none",
  "timeout_ms": 5000,
  "returns": {
    "invoice_status": "string",
    "amount_cents": "integer",
    "due_date": "string"
  }
}

The model-visible description should be precise. The machine-visible schema should be strict. The runtime should enforce the permission.

Tool Permission Tiers

Tier	Examples	Runtime Behavior
free read	local docs search, current time	allow and log
scoped read	customer lookup, internal search	check identity and ACL
reversible write	draft note, stage patch	allow in sandbox or require confirmation
irreversible write	deploy, email, refund	require approval and audit
privileged execution	shell, browser, database mutation	sandbox, allowlist, approval, tracing

The model can request a tool call. The runtime decides whether it happens.

MCP Server Checklist

Before adding an MCP server, ask:

• what tools, resources, and prompts does it expose?
• are tool descriptions stable and accurate?
• does it require user secrets or service credentials?
• can it enforce tenant/user permissions?
• what logs will it emit?
• can tool outputs contain untrusted instructions?
• how does the host revoke access?
• how are versions pinned?

Because MCP standardizes connectivity, it also makes capability easier to spread. That is good for interoperability and serious for risk management.

Skill Design Checklist

Skills should be specific enough to guide behavior but small enough to apply.

skill/
  SKILL.md
  references/
  scripts/
  templates/
  examples/

Good skills include:

• trigger conditions
• task workflow
• required references
• local constraints
• validation commands
• output expectations
• examples of good results

Bad skills are either too vague to help or so broad that they become a second operating manual.

Current Landscape

Tool ecosystems are moving toward standardization.

OpenAI supports built-in tools, function calling, tool search, file search, web search, and remote MCP tools [1]. Its integration docs position MCP-backed capabilities as part of an inspectable agent runtime with tracing [2].

MCP has become the clearest protocol boundary for agent-to-tool integration [3]. It does not solve every problem. It does not decide whether a tool is safe, whether a user is authorized, or whether a tool result is trustworthy. It does give hosts and tool providers a shared language.

Skills and plugins are the packaging layer. They matter because agents need more than callable APIs: they need task procedures, examples, local norms, validation habits, and installed capabilities. Claude Code's extension surface is one example of this broader move toward configurable, tool-using coding agents [4].

The Hitchhiker guide's N-to-M integration framing is a useful mental model: protocols and packaged capabilities reduce repeated glue code, but they increase the importance of trust, discovery, and governance [6].

Practical Takeaways

Design tools like APIs, not like shortcuts. Give them strict schemas, clear descriptions, timeout behavior, and explicit side-effect labels.

Separate data tools from action tools. Reading and writing should not share the same permission model.

Use MCP when interoperability matters. It is especially valuable when many hosts need access to many external systems.

Treat skills as workflow knowledge. A skill should teach the agent how to do a task, not just expose another function.

Treat plugins as supply chain. Version them, review them, restrict permissions, and know what capabilities they add.

Log every meaningful tool call. Agent debugging depends on knowing what the model requested, what the runtime allowed, and what the world returned.

References

[1] "Using tools." OpenAI API documentation. https://developers.openai.com/api/docs/guides/tools. Published/updated: not listed. Accessed: 2026-07-06. Used for: built-in tools, function calling, file search, web search, tool search, remote MCP, and custom functions.

[2] "Integrations and observability." OpenAI API documentation. https://developers.openai.com/api/docs/guides/agents/integrations-observability. Published/updated: not listed. Accessed: 2026-07-06. Used for: MCP-backed capabilities, SDK-managed MCP connections, hosted tools, and tracing.

[3] "Model Context Protocol specification, 2025-06-18." Model Context Protocol. https://modelcontextprotocol.io/specification/2025-06-18. Published/updated: 2025-06-18. Accessed: 2026-07-06. Used for: MCP purpose, JSON-RPC 2.0, host/client/server roles, tools, resources, prompts, roots, sampling, and elicitation.

[4] "Claude Code overview." Anthropic Claude Code documentation. https://code.claude.com/docs/en/overview. Published/updated: not listed. Accessed: 2026-07-06. Used for: coding-agent extension surfaces including MCP, instruction files, skills, hooks, and workflows.

[5] "Building effective agents." Anthropic. https://www.anthropic.com/engineering/building-effective-agents. Published/updated: 2024-12-19. Accessed: 2026-07-06. Used for: agent-computer interface framing, tool documentation, and start-simple guidance.

[6] "The Hitchhiker's Guide to Agentic AI: From Foundations to Systems." Haggai Roitman. Local source: agent-101/The Hitchhiker’s Guide to Agentic AI/book.tex. Published/updated: 2026. Accessed: 2026-07-06. Used for: MCP integration-fragmentation framing, host/client/server roles, transports, and tool capability packaging.