tool-synthesis-from-code

Guides curation of analyzed source code into consolidated, outcome-named LLM tool sets.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/dperussina/function2agent --skill tool-synthesis-from-code-dperussina
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tool-synthesis-from-code
Source: https://github.com/dperussina/function2agent/tree/main/.cursor/skills/tool-synthesis-from-code
Command: npx skills add https://github.com/dperussina/function2agent --skill tool-synthesis-from-code-dperussina

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Mechanical one-to-one conversion of functions or endpoints into LLM tools is a documented anti-pattern that pollutes model context and degrades tool selection accuracy. This Skill provides the design rules for turning analyzed source code into a small, curated set of outcome-named tools instead of a per-function dump. ## Core Features & Use Cases - Promotion gate: A checklist that filters discovered functions to only reachable, user-meaningful, effect-classifiable candidates, with default-deny for unclassifiable ones. - Consolidation guidance: Rules for collapsing call-graph clusters and framework-generated CRUD into single outcome-named tools, targeting roughly 20-25 tools from a 300-endpoint app. - Effects metadata mandate: Requires read_only, egress, idempotent, destructive, and auth_scope fields per tool, kept in a typed internal IR since MCP schemas cannot represent them. - Use Case: When reviewing a v2 design that proposes emitting one tool per OpenAPI endpoint, apply this Skill to gate candidates, consolidate clusters, and enforce effect classification before generation. ## Quick Start Ask the agent to review the proposed tool generation design against the tool-synthesis-from-code promotion gate and consolidation rules.

Frequently Asked Questions about tool-synthesis-from-code

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

FAQPage Schema
How do I convert a codebase into LLM tools without one tool per function?▼

Derive the tool surface from external boundaries like HTTP routes, resolvers, and CLI commands rather than arbitrary functions. Then consolidate call-graph clusters into single outcome-named tools, targeting roughly a 15:1 reduction from endpoints to tools.

What is wrong with auto-converting REST APIs or OpenAPI specs to MCP tools?▼

Auto-converted servers technically work but fail in practice because every tool schema is reprocessed each reasoning turn and atomic calls force slow, error-prone chaining. FastMCP's own author publicly warns against this pattern.

How many tools can an LLM agent handle before accuracy degrades?▼

Tool selection accuracy degrades beyond roughly 30-50 tools. A 300-endpoint application should yield about 20-25 tools plus a search or dispatch tool, using deferred loading and code execution as escape valves.

Why should tools call HTTP routes instead of application functions in-process?▼

Application functions expect middleware-supplied context like authentication, transactions, and tenant scope. Invoking them in-process bypasses authorization, while external boundaries already enforce validation and audit.

How should effect classification work for generated tools?▼

Derive read_only, egress, idempotent, destructive, and auth_scope statically where possible, and default unclassifiable candidates to the most dangerous class with default-deny. Destructive operations require out-of-band confirmation that is not itself a callable tool.

When should I not use this tool synthesis skill?▼

Do not use it for v1 effect classification work, which happens per call at a runtime interception point covered by the agent-safety-and-sandboxing skill. This skill governs v2 generation-time synthesis and promotion decisions only.