Custom Tools: This is BETTER Than MCP & SAVES 90% OF YOUR TOKENS!

Key Concepts

• MCP (Model-Centric Programming) Servers: A framework for defining tools and capabilities that AI agents can use.
• Token Efficiency: Minimizing the number of tokens an AI model needs to process to perform a task, impacting cost and speed.
• Composable Tools: Small, independent tools that can be combined to achieve complex tasks.
• Bash and Node Scripts: Lightweight scripting languages that agents can readily understand and execute.
• Context Window: The amount of information an AI model can consider at any given time.
• Puppeteer Core: A Node.js library for controlling headless Chrome or Chromium.
• DOM (Document Object Model): A programming interface for HTML and XML documents.
• CDP (Chrome DevTools Protocol): A protocol for instrumenting, inspecting, debugging and profiling Chrome, Muse, and other Chromium-based browsers.
• Unix Philosophy: Emphasizing small, single-purpose tools that can be combined through pipes.
• VLM (Vision-Language Model): AI models that can process both visual and textual information.

MCP Servers vs. Composable Tools for Agent Work

This video explores the necessity of large MCP (Model-Centric Programming) servers for day-to-day AI agent tasks versus the efficacy of using small, composable tools that agents already understand. The core argument centers on token efficiency and developer control, advocating for bash and tiny node scripts to keep agents fast, cheap, and intelligent, rather than relying on heavy MCP manifests that consume significant context window space.

Token Overhead of Popular MCP Servers

The author highlights the substantial token cost associated with popular MCP servers:

• Playwright MCP: Features 21 tools, consuming approximately 13.7,000 tokens, which is about 6.8% of Claude's context window.
• Chrome DevTools MCP: Includes 26 tools, using around 18.0,000 tokens, roughly 9.0% of the context window.

This pre-computation token burn is significant, and combining multiple MCP servers can lead to agent confusion. Furthermore, MCP outputs often require a round trip through the agent's context, further inflating token usage and hindering composability.

The Composable Toolkit Approach

In contrast, a minimal toolkit is presented, consisting of a concise README and a few node scripts utilizing Puppeteer Core.

• README: Approximately 225 tokens.
• Agent Understanding: Agents are assumed to already understand bash and JavaScript, enabling them to call these scripts directly.

This approach is lauded as "insanely good" compared to the 13-18,000 token manifest method, aligning with the classic Unix philosophy of small tools, pipes, and files.

Hands-On Walkthrough of the Minimal Toolkit

The video details specific tools within this composable toolkit:

1. start.js:

   • Functionality: Kills running Chrome instances, sets up a cache directory, optionally synchronizes the Chrome profile for faster subsequent runs, and launches Chrome with remote debugging enabled on port 9222. It connects to Puppeteer once the debugging port is available.
   • Benefits: Deterministic, honest, no complex RPC schema or skill catalog parsing, a known port and simple contract for the agent to reason about.

2. nav.js:

   • Functionality: Navigates the current tab to a specified URL or opens a new tab. It connects via Puppeteer, grabs the active page, and uses goto with waitUntil: 'domcontentloaded'.
   • Output: Clean, indicating success (e.g., "opened" or "navigated").
   • Benefits: Fast, legible, avoids the "tool explosion" problem, and maps to agent thinking (perform action, confirm action) without redundant variations.

3. evil.js:

   • Functionality: Executes arbitrary JavaScript code within the page context. It constructs an async function and evaluates the provided code. Results are printed as key-value pairs for arrays/objects or as scalars.
   • Benefits: Enables agents to write plain DOM code that models already understand, reducing token overhead for descriptions and decision-making. Outputs can be saved to disk, avoiding streaming large results through the prompt. This is similar to client-side work with light CDP harnesses.

4. screenshot.js:

   • Functionality: Connects to the active page, takes a viewport screenshot, saves it to the OS temp directory with a timestamped filename, and prints the path. The agent then reads the image from disk for vision processing.
   • Benefits: Minimalist, hits exact needs without a large manifest. Images as files don't inflate context unless explicitly sent, saving costs.

5. pick.js (Fun Extra):

   • Functionality: Allows users to visually select elements on a webpage. It injects a window.pick helper, overlays a banner, and highlights elements as the cursor moves. Clicking selects an element, Ctrl/Cmd+click allows multi-selection. Pressing Enter finishes, Escape cancels.
   • Output: Structured information for selected elements, including tag, ID, class, trimmed text, appearance chain, and outer HTML snippet.
   • Benefits: Enables visual intent sharing. Useful for scraping, allowing agents to convert selections into robust CSS selectors or XPath and synthesize deterministic scrapers. Similar to classic dev tools pickers but integrated within the agent's controlled context.

Stitching the Workflow Together

The author outlines a practical workflow for integrating these tools:

1. Create a Directory: Create an agent-tools folder in the home directory.
2. Clone Repos: Clone individual tool repositories (e.g., browser tools) into this folder.
3. Set Alias: Create an alias that appends these tool directories to the system's PATH when launching the agent CLI.
4. Agent Launch: Launch a Claude code session with a temporary path and a skip-permissions flag in a trusted setup.
5. Prefix Scripts: Prefix script names to avoid collisions (e.g., browser-tools-start.js).
6. README Instruction: Add a single line in the README indicating these scripts are globally available.
7. Working Directory: Add the agent-tools directory as a working directory in Claude Code, allowing direct reference to README.md and on-demand context pulling.

This setup ensures agents use minimal commands via bash, avoiding constant directory changes or large skill manifests.

Strengths of the Composable Toolkit

• Fewer Tokens: Significantly reduces token consumption.
• Higher Composability: Tools are independent and can be easily combined.
• Rapid Customization: Scripts can be tweaked for specific output formats or site DOM changes.
• Artifact Processing: Outputs can be saved to disk and processed later with various programming languages (TypeScript, Python, Bun, Go) or fed into local VLM pipelines.

When MCP Servers Are Still Beneficial

MCP servers remain valuable in specific enterprise scenarios:

• Governance and Access Constraints: Companies often restrict raw API or file system access.
• Brokerage Role: MCP servers can act as secure brokers for fetching internal data with role-based permissions, curated routes, and auditability.

However, even in these cases, the token footprint of MCP tool descriptions (6.8-9.0% of the window) should be considered. Strategies like trimming descriptions, loading capabilities on demand, and pushing results into artifacts (files) are recommended.

Concluding Thoughts

While the author initially found MCP servers to be token-heavy and cumbersome, they acknowledge their utility when governance or access constraints are paramount. The practical recommendation is to default to the small, composable toolkit (including start.js, nav.js, evil.js, screenshot.js, pick.js, and a cookies helper) and only adopt MCP when truly necessary. Key practices include keeping outputs on disk, maintaining tight READMEs, and leveraging the agent's inherent ability to execute bash and code.