tdmcp-tool-builder

Implement tdmcp tools with xSchema, xImpl, registerX, and offline unit tests.

30|6|Updated May 25, 2026
One-click install
npx skills add https://github.com/Pantani/tdmcp --skill tdmcp-tool-builder
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdmcp-tool-builder
Source: https://github.com/Pantani/tdmcp/tree/main/.agents/skills/tdmcp-tool-builder
Command: npx skills add https://github.com/Pantani/tdmcp --skill tdmcp-tool-builder

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Authoring a new tdmcp MCP tool is complex and boilerplate-heavy. This Skill provides a canonical, end-to-end blueprint to implement a tool using the standard file shape (XImpl + registerX), the Python-bridge pattern (buildPayloadScript/parsePythonReport), and the offline unit-test scaffolding, ensuring consistency with the project’s architecture and testing practices.

Core Features & Use Cases

  • Canonical template: Implement a tdmcp tool using the standard file shape (XImpl + registerX) and the recommended template src/tools/layer2/manageComponent.ts.
  • Bridge pattern & safety: Use the bridge approach (buildPayloadScript + parsePythonReport) with in-script TD globals and guard logic to avoid runtime crashes.
  • Testing strategy: Provide a unit-test scaffold under tests/unit that runs offline with msw to validate happy paths, fatal conditions, and bad input.
  • Style & conventions: Adhere to Biome/ESM style, NodeNext imports, and clear annotations to ensure predictable tooling behavior.

Quick Start

Follow the canonical template in src/tools/layer*/ to create a new tool: implement xSchema, xImpl, and registerX, then add unit tests under tests/unit to validate the bridge workflow.

Frequently Asked Questions about tdmcp-tool-builder

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce boilerplate when building a new MCP tool with TypeScript?

To reduce boilerplate when building a TypeScript MCP tool, use a single-file pattern with three exports (xSchema, xImpl, registerX) and a registrar to ensure consistent bridge-based execution and structured results.

How does the bridge pattern work for tool execution without throwing runtime errors?

The bridge pattern works by using buildPayloadScript and parsePythonReport with in-script guard logic, ensuring handlers do not throw runtime errors and return predictable structured results instead.

How do I unit test an MCP tool offline without hitting live network endpoints?

You can unit test an MCP tool offline by using msw (Mock Service Worker) to validate happy paths, fatal conditions, and bad input within your local test suite without external network dependencies.

What is the standard file structure for implementing a new MCP tool?

The standard file structure for implementing an MCP tool involves defining xSchema, xImpl, and registerX in a single file under the src/tools directory, following NodeNext ES module conventions.

Do I need to configure Biome and NodeNext to ensure predictable tooling behavior?

Yes, you need to configure Biome and NodeNext ES module conventions to ensure predictable tooling behavior, clear annotations, and consistent style across the tool implementation and testing scaffolding.

Why do my MCP tool handlers crash when processing bad input?

MCP tool handlers crash on bad input when robust guard TD error handling is missing; implementing non-throwing handlers with structured guard logic prevents crashes and ensures predictable results.