@vinkius-core/mcp-fusion 0.1.0

package/LICENSE

@@ -0,0 +1,190 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to the Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   Copyright 2026 Vinkius Labs
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,391 @@
+# MCP Extensions for Primitive Grouping
+
+**Stop registering hundreds of individual MCP tools. Ship one.**
+
+A TypeScript framework that consolidates related MCP operations into a single tool behind a discriminator field — with a domain model layer for hierarchical entity management and a build-time strategy engine designed for 5,000+ endpoints. Fewer tools means less context pressure on the LLM, fewer routing errors, and cleaner server code.
+
+```
+npm install @vinkius-core/mcp-fusion
+```
+
+---
+
+## The Problem
+
+MCP servers that expose individual tools for every operation — `create_project`, `update_project`, `delete_project`, `list_projects`, `archive_project` — create two cascading failures:
+
+1. **Context exhaustion.** Every tool definition burns tokens in the LLM context window. At 30+ tools, the model starts losing track.
+2. **Routing confusion.** Semantically similar tools compete for selection. The LLM picks `update_project` when it should pick `create_project`.
+
+The workaround is writing fewer, bloated tools — or rotating tool sets per conversation. Both are brittle.
+
+## The Solution
+
+Group related operations under a single tool. The LLM sees one `projects` tool and selects the operation through an `action` enum — a discriminator field. The framework handles description generation, schema composition, annotation aggregation, middleware compilation, validation, and error formatting — all at build time.
+
+```typescript
+import { GroupedToolBuilder, ToolRegistry, success, error } from '@vinkius-core/mcp-fusion';
+import { z } from 'zod';
+
+const projects = new GroupedToolBuilder<AppContext>('projects')
+    .description('Manage projects')
+    .commonSchema(z.object({
+        workspace_id: z.string().describe('Workspace identifier'),
+    }))
+    .action({
+        name: 'list',
+        readOnly: true,
+        schema: z.object({ status: z.enum(['active', 'archived']).optional() }),
+        handler: async (ctx, args) => {
+            // args is fully typed: { workspace_id: string, status?: 'active' | 'archived' }
+            const projects = await ctx.db.projects.findMany({ where: { workspaceId: args.workspace_id, status: args.status } });
+            return success(projects);
+        },
+    })
+    .action({
+        name: 'create',
+        schema: z.object({ name: z.string(), description: z.string().optional() }),
+        handler: async (ctx, args) => {
+            const project = await ctx.db.projects.create({ data: { workspaceId: args.workspace_id, name: args.name, description: args.description } });
+            return success(project);
+        },
+    })
+    .action({
+        name: 'delete',
+        destructive: true,
+        schema: z.object({ project_id: z.string() }),
+        handler: async (ctx, args) => {
+            await ctx.db.projects.delete({ where: { id: args.project_id } });
+            return success('Project deleted');
+        },
+    });
+
+const registry = new ToolRegistry<AppContext>();
+registry.register(projects);
+registry.attachToServer(server, {
+    contextFactory: (extra) => createAppContext(extra),
+});
+```
+
+Five individual tools become one registered tool. The LLM sees:
+
+```
+Action: list | create | delete
+- 'list': Requires: workspace_id. For: list
+- 'create': Requires: workspace_id, name. For: create
+- 'delete': Requires: workspace_id, project_id ⚠️ DESTRUCTIVE
+```
+
+→ [Getting Started Guide](docs/getting-started.md)
+
+---
+
+## What Makes This Framework Extraordinary
+
+### Two-Layer Architecture
+
+This is not a simple utility wrapper. The framework has two distinct layers:
+
+**Layer 1 — Domain Model.** A hierarchical entity model for MCP primitives (`Group`, `Tool`, `Prompt`, `Resource`, `PromptArgument`) with tree traversal, multi-parent leaves, fully-qualified names (dot-separated, configurable separator), metadata maps, icons, and bidirectional type converters (`AbstractToolConverter`, `AbstractGroupConverter`, etc.). This is the structural backbone — think of it as the AST for your MCP server.
+
+**Layer 2 — Build-Time Strategy Engine.** `GroupedToolBuilder` orchestrates six pure-function strategy modules to generate a single MCP tool definition. All computation happens at build time. At runtime, `execute()` does a single `Map.get()` lookup and calls a pre-compiled function.
+
+### Per-Field Annotation Intelligence (4-Tier System)
+
+The `SchemaGenerator` analyzes every field across every action and produces one of four annotation tiers — automatically, from your Zod schemas:
+
+| Tier | Condition | Generated Annotation | LLM Reads As |
+|---|---|---|---|
+| **Always Required** | Field is in `commonSchema` and required | `(always required)` | "I must always send this field" |
+| **Required-For** | Required in every action that uses it | `Required for: create, update` | "I need this for these specific actions" |
+| **Required + Optional** | Required in some, optional in others | `Required for: create. For: update` | "Required for create, optional for update" |
+| **For** | Optional in all actions that use it | `For: list, search` | "Only relevant for these actions" |
+
+The LLM knows *exactly* which fields to populate for each action. No guessing. No hallucinated parameters. No manual annotation writing. This is extracted directly from Zod `isOptional()` introspection and cross-referenced across all registered actions.
+
+### Pre-Compiled Middleware Chains
+
+Middleware follows the `next()` pattern:
+
+```typescript
+const authMiddleware: MiddlewareFn<AppContext> = async (ctx, args, next) => {
+    if (!ctx.session) return error('Unauthorized');
+    return next();
+};
+```
+
+But unlike Express, chains are compiled at build time. The `MiddlewareCompiler` wraps handlers right-to-left into nested closures and stores the result in a `Map<string, ChainFn>`. At runtime, `execute()` does `this._compiledChain.get(action.key)` — one Map lookup, zero chain assembly, zero closure allocation per request.
+
+Middleware is hierarchical:
+- **Global** — `.use(mw)` on the builder. Runs for every action (outermost).
+- **Group-scoped** — `.use(mw)` inside a group's `ActionGroupBuilder`. Runs only for actions in that group (inner).
+
+### TOON Token Optimization
+
+Descriptions and responses can be encoded in TOON (Token-Oriented Object Notation) via `@toon-format/toon` — a compact pipe-delimited format that eliminates repeated key names:
+
+```typescript
+// Enable TOON for tool descriptions (saves tokens on tools/list)
+builder.toonDescription();
+
+// Enable TOON for handler responses (saves tokens on tools/call)
+return toonSuccess(users);  // Instead of success(users)
+```
+
+The `toonSuccess()` helper accepts any JSON-serializable value and encodes it with configurable delimiter (`|` by default). For arrays of uniform objects — the typical API response — TOON achieves significant token reduction because column names are written once as a header, not repeated per row.
+
+### Conservative Annotation Aggregation
+
+MCP tool annotations operate at the tool level, but your actions have individual behavioral properties. The `AnnotationAggregator` resolves this with conservative rules:
+
+- `destructiveHint: true` if **any** action is destructive (worst case assumption)
+- `readOnlyHint: true` only if **all** actions are read-only (one mutation breaks it)
+- `idempotentHint: true` only if **all** actions are idempotent (one non-idempotent breaks it)
+
+Explicit annotations via `.annotations()` override aggregated values. The `ToolAnnotations` class also supports `openWorldHint` and `returnDirect`.
+
+### Hierarchical Grouping for Large API Surfaces
+
+For large API surfaces, actions support `module.action` compound keys:
+
+```typescript
+new GroupedToolBuilder<AppContext>('platform')
+    .description('Platform management API')
+    .tags('core')  // ← Tag for selective exposure
+    .group('users', 'User management', g => {
+        g.use(requireAdmin)  // Group-scoped middleware
+         .action({ name: 'list', readOnly: true, handler: listUsers })
+         .action({ name: 'create', schema: createUserSchema, handler: createUser })
+         .action({ name: 'ban', destructive: true, schema: banSchema, handler: banUser });
+    })
+    .group('billing', 'Billing operations', g => {
+        g.action({ name: 'invoices', readOnly: true, handler: listInvoices })
+         .action({ name: 'refund', destructive: true, schema: refundSchema, handler: issueRefund });
+    })
+    .group('analytics', g => {
+        g.action({ name: 'report', readOnly: true, handler: generateReport })
+         .action({ name: 'export', readOnly: true, schema: exportSchema, handler: exportData });
+    });
+```
+
+The discriminator enum becomes: `users.list | users.create | users.ban | billing.invoices | billing.refund | analytics.report | analytics.export`. The description auto-generates group headers: `Modules: users (list,create,ban) | billing (invoices,refund) | analytics (report,export)`.
+
+**Flat mode** (`.action()`) and **hierarchical mode** (`.group()`) are mutually exclusive on the same builder — enforced at registration time with clear error messages.
+
+### Token Management at Scale — Tag-Based Selective Exposure
+
+> **"5,000 endpoints — won't that blow up the token context?"**
+
+No. The framework uses a 3-layer strategy to keep token usage under control, even with thousands of endpoints:
+
+**Layer 1 — Grouping reduces tool count.** Instead of 5,000 individual tools, you register them as grouped tools. A `platform` tool with 50 actions is ONE tool definition in `tools/list`. The LLM sees 1 tool, not 50.
+
+**Layer 2 — Tag filtering controls what the LLM sees.** You do NOT expose all tools at once. Each builder has `.tags()`, and `attachToServer()` accepts a `filter` with `tags` (include) and `exclude` options. Only matching tools appear in `tools/list`.
+
+**Layer 3 — TOON compresses descriptions.** For tools that ARE exposed, `.toonDescription()` encodes metadata as compact pipe-delimited tables instead of verbose markdown, reducing token cost per tool.
+
+Here's how this works in practice:
+
+```typescript
+// Register 5,000 endpoints across domain-specific grouped tools
+const usersTool = new GroupedToolBuilder<AppContext>('users')
+    .tags('core', 'user-management')
+    .group('profiles', g => { /* 20 actions */ })
+    .group('permissions', g => { /* 15 actions */ })
+    .group('notifications', g => { /* 10 actions */ });
+
+const billingTool = new GroupedToolBuilder<AppContext>('billing')
+    .tags('core', 'billing')
+    .toonDescription()  // Token-optimized descriptions
+    .group('invoices', g => { /* 12 actions */ })
+    .group('subscriptions', g => { /* 8 actions */ });
+
+const analyticsTool = new GroupedToolBuilder<AppContext>('analytics')
+    .tags('reporting')
+    .toonDescription()
+    .group('dashboards', g => { /* 25 actions */ })
+    .group('exports', g => { /* 10 actions */ });
+
+const adminTool = new GroupedToolBuilder<AppContext>('admin')
+    .tags('admin', 'internal')
+    .group('system', g => { /* 30 actions */ })
+    .group('audit', g => { /* 15 actions */ });
+
+const registry = new ToolRegistry<AppContext>();
+registry.registerAll(usersTool, billingTool, analyticsTool, adminTool);
+
+// Conversation about user management? Expose only core tools:
+registry.attachToServer(server, {
+    filter: { tags: ['core'] },  // LLM sees: users + billing (2 tools)
+});
+
+// Admin session? Expose admin tools, exclude reporting:
+registry.attachToServer(server, {
+    filter: { tags: ['admin'] },  // LLM sees: admin only (1 tool)
+});
+
+// Full access, but never internal tools:
+registry.attachToServer(server, {
+    filter: { exclude: ['internal'] },  // Everything except admin
+});
+```
+
+**The result:** 5,000 endpoints registered, but the LLM context only contains the 2-3 tools relevant to the current conversation. Tag filtering acts as a context gate — you control exactly what the LLM sees, per session.
+
+### Zod Parameter Stripping — Built-In Security Layer
+
+When the LLM sends arguments, `execute()` merges `commonSchema` + `action.schema` using Zod's `.merge().strip()`, then runs `safeParse()`. The framework uses `result.data` — not the raw args — which means:
+
+1. Unknown/injected fields are silently stripped.
+2. Type coercion happens through Zod.
+3. The handler receives exactly the shape it declared.
+
+The LLM cannot inject parameters that your schema does not declare. This is a security boundary, not just validation.
+
+### LLM-Friendly Error Messages
+
+When things fail, the framework produces errors that LLMs can parse and self-correct:
+
+```
+// Missing discriminator:
+Error: action is required. Available: list, create, delete
+
+// Unknown action:
+Error: Unknown action "remove". Available: list, create, delete
+
+// Validation failure (from Zod):
+Validation failed: name: Required; email: Invalid email format
+
+// Runtime error (from handler):
+[projects/delete] Database connection failed
+```
+
+Every error includes the `[toolName/action]` prefix for instant debugging. The LLM reads the structured error, fixes the arguments, and retries.
+
+### ⚠️ DESTRUCTIVE Warnings in LLM Descriptions
+
+When an action is marked `destructive: true`, the `DescriptionGenerator` appends a literal `⚠️ DESTRUCTIVE` warning to the description. LLMs trained on safety data recognize this signal and will often request user confirmation before executing.
+
+### Type-Safe Common Schema Propagation
+
+`commonSchema()` propagates types through generics. The return type narrows from `GroupedToolBuilder<TContext, Record<string, never>>` to `GroupedToolBuilder<TContext, TSchema["_output"]>`. Every subsequent handler receives `TSchema["_output"] & TCommon` — checked at compile time, not runtime. No `as any`, no type assertions needed.
+
+### Duck-Typed Server Resolution
+
+`attachToServer()` accepts `unknown` and performs runtime duck-type detection:
+
+1. Has `.server.setRequestHandler`? → `McpServer` (high-level). Unwrap the inner `Server`.
+2. Has `.setRequestHandler` directly? → `Server` (low-level). Use directly.
+3. Neither? → Clear error message.
+
+No imports from the MCP SDK server modules. No peer dependency coupling. If the SDK restructures its exports, this framework does not break. The method returns a `DetachFn` that resets handlers to no-ops — clean teardown for testing.
+
+### Freeze-After-Build Immutability
+
+Once `buildToolDefinition()` is called, the builder is permanently frozen. The `_actions` array is sealed with `Object.freeze()`. All mutation methods throw:
+
+```
+Builder "projects" is frozen after buildToolDefinition(). Cannot modify a built tool.
+```
+
+This eliminates an entire class of bugs where tools are accidentally mutated after registration — the same pattern Protocol Buffers uses.
+
+### Introspection API
+
+`getActionNames()` and `getActionMetadata()` provide runtime access to every action's properties:
+
+```typescript
+const meta = builder.getActionMetadata();
+// Returns: [{ key, actionName, groupName, description, destructive, idempotent, readOnly, requiredFields, hasMiddleware }]
+```
+
+Use this for: compliance audits, admin dashboards, middleware coverage validation, programmatic documentation generation, test coverage reports.
+
+---
+
+## Domain Model Layer
+
+Beyond the framework, the package provides a full domain model for MCP primitives:
+
+| Class | Purpose |
+|---|---|
+| `Group` | Tree node with parent/child relationships, configurable name separator, recursive FQN resolution |
+| `Tool` | Leaf node with input/output schemas and `ToolAnnotations` |
+| `Prompt` | Leaf node with `PromptArgument` list |
+| `Resource` | Leaf node with URI, size, mimeType, and `Annotations` (audience, priority, lastModified) |
+| `AbstractBase` | Name, title, description, meta, icons, hashCode/equals |
+| `AbstractLeaf` | Multi-parent group support, root traversal |
+
+**Bidirectional converters** (`AbstractToolConverter`, `AbstractGroupConverter`, `AbstractPromptConverter`, `AbstractResourceConverter`, `AbstractToolAnnotationsConverter`) provide a clean pattern for converting between domain model types and external representations — both directions, single or batch, with null filtering.
+
+→ [Architecture Guide](docs/architecture.md)
+
+---
+
+## Strategy Pattern Internals
+
+| Module | Responsibility | Design |
+|---|---|---|
+| `SchemaGenerator` | 4-tier per-field annotations from Zod schemas | Pure function, no state |
+| `DescriptionGenerator` | 3-layer descriptions with ⚠️ DESTRUCTIVE warnings | Pure function, no state |
+| `ToonDescriptionGenerator` | TOON-encoded descriptions via `@toon-format/toon` | Pure function, no state |
+| `AnnotationAggregator` | Conservative behavioral hint aggregation | Pure function, no state |
+| `MiddlewareCompiler` | Right-to-left closure composition at build time | Pure function, no state |
+| `SchemaUtils` | Zod field extraction shared by descriptions + introspection | Pure function, no state |
+
+Every module is independently testable. Every module is replaceable. Zero shared state between any of them.
+
+→ [API Reference](docs/api-reference.md)
+
+---
+
+## Key Capabilities
+
+| Capability | What It Solves |
+|---|---|
+| **Action Consolidation** | Reduces tool count, improves LLM routing accuracy |
+| **Hierarchical Groups** | Namespace 5,000+ actions with `module.action` compound keys |
+| **4-Tier Field Annotations** | LLM knows exactly which fields to send per action |
+| **Zod `.merge().strip()`** | Type-safe schema composition + unknown field stripping |
+| **Common Schema Propagation** | Shared fields with compile-time generic inference |
+| **Pre-Compiled Middleware** | Auth, rate limiting, audit — zero runtime chain assembly |
+| **Group-Scoped Middleware** | Different middleware per namespace (e.g., admin-only for users) |
+| **TOON Encoding** | Token reduction on descriptions and responses |
+| **Conservative Annotations** | Safe MCP behavioral hints from per-action properties |
+| **⚠️ DESTRUCTIVE Warnings** | Safety signal in LLM tool descriptions |
+| **Tag Filtering** | Include/exclude tags for selective tool exposure |
+| **Introspection API** | Runtime metadata for compliance, dashboards, audit trails |
+| **Freeze-After-Build** | `Object.freeze()` prevents mutation bugs after registration |
+| **Error Isolation** | `[tool/action]` prefixed errors for instant debugging |
+| **Duck-Typed Server** | Works with `Server` and `McpServer` — zero import coupling |
+| **Detach Function** | Clean teardown for testing via `DetachFn` |
+| **Domain Model** | Hierarchical tree with multi-parent, FQN, converters |
+| **Flat ↔ Hierarchical** | Mutual exclusion enforced with clear error messages |
+| **Auto-Build on Execute** | `execute()` triggers `buildToolDefinition()` if not called |
+| **Response Helpers** | `success()`, `error()`, `required()`, `toonSuccess()` |
+
+---
+
+## Documentation
+
+| Guide | What You Will Learn |
+|---|---|
+| [Getting Started](docs/getting-started.md) | First tool, context, common schema, groups, TOON — complete working examples |
+| [Architecture](docs/architecture.md) | Domain model, strategy pattern, build-time engine, execution flow |
+| [Middleware](docs/middleware.md) | Global, group-scoped, pre-compilation, real patterns (auth, rate-limit, audit) |
+| [API Reference](docs/api-reference.md) | Every public class, method, type, and interface |
+| [Introspection](docs/introspection.md) | Runtime metadata, compliance, dashboards, middleware validation |
+
+---
+
+## Requirements
+
+- Node.js 18+
+- TypeScript 5.7+
+- `@modelcontextprotocol/sdk ^1.12.1`
+- `zod ^3.25.1`
+- `@toon-format/toon` (for TOON features)
+
+## License
+
+Apache-2.0

package/dist/src/AbstractBase.d.ts

@@ -0,0 +1,24 @@
+import { Icon } from './Icon.js';
+export declare abstract class AbstractBase {
+    static readonly DEFAULT_SEPARATOR: string;
+    protected readonly nameSeparator: string;
+    protected readonly name: string;
+    protected title: string | undefined;
+    protected description: string | undefined;
+    protected meta: Map<string, unknown> | undefined;
+    protected icons: Icon[] | undefined;
+    protected constructor(name: string, nameSeparator?: string);
+    getName(): string;
+    getTitle(): string | undefined;
+    setTitle(title: string): void;
+    getDescription(): string | undefined;
+    setDescription(description: string): void;
+    getIcons(): Icon[] | undefined;
+    setIcons(icons: Icon[]): void;
+    getMeta(): Map<string, unknown> | undefined;
+    setMeta(meta: Map<string, unknown>): void;
+    hashCode(): number;
+    equals(obj: unknown): boolean;
+    abstract getFullyQualifiedName(): string;
+}
+//# sourceMappingURL=AbstractBase.d.ts.map

package/dist/src/AbstractBase.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"AbstractBase.d.ts","sourceRoot":"","sources":["../../src/AbstractBase.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAEjC,8BAAsB,YAAY;IAC9B,gBAAuB,iBAAiB,EAAE,MAAM,CAAO;IAEvD,SAAS,CAAC,QAAQ,CAAC,aAAa,EAAE,MAAM,CAAC;IACzC,SAAS,CAAC,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IAChC,SAAS,CAAC,KAAK,EAAE,MAAM,GAAG,SAAS,CAAC;IACpC,SAAS,CAAC,WAAW,EAAE,MAAM,GAAG,SAAS,CAAC;IAC1C,SAAS,CAAC,IAAI,EAAE,GAAG,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CAAC;IACjD,SAAS,CAAC,KAAK,EAAE,IAAI,EAAE,GAAG,SAAS,CAAC;IAEpC,SAAS,aAAa,IAAI,EAAE,MAAM,EAAE,aAAa,CAAC,EAAE,MAAM;IAQnD,OAAO,IAAI,MAAM;IAIjB,QAAQ,IAAI,MAAM,GAAG,SAAS;IAI9B,QAAQ,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI;IAI7B,cAAc,IAAI,MAAM,GAAG,SAAS;IAIpC,cAAc,CAAC,WAAW,EAAE,MAAM,GAAG,IAAI;IAIzC,QAAQ,IAAI,IAAI,EAAE,GAAG,SAAS;IAI9B,QAAQ,CAAC,KAAK,EAAE,IAAI,EAAE,GAAG,IAAI;IAI7B,OAAO,IAAI,GAAG,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS;IAI3C,OAAO,CAAC,IAAI,EAAE,GAAG,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,IAAI;IAIzC,QAAQ,IAAI,MAAM;IAYlB,MAAM,CAAC,GAAG,EAAE,OAAO,GAAG,OAAO;aAcpB,qBAAqB,IAAI,MAAM;CAClD"}

package/dist/src/AbstractBase.js

@@ -0,0 +1,63 @@
+export class AbstractBase {
+    constructor(name, nameSeparator) {
+        if (name === null || name === undefined) {
+            throw new Error("name must not be null");
+        }
+        this.name = name;
+        this.nameSeparator = nameSeparator !== undefined ? nameSeparator : AbstractBase.DEFAULT_SEPARATOR;
+    }
+    getName() {
+        return this.name;
+    }
+    getTitle() {
+        return this.title;
+    }
+    setTitle(title) {
+        this.title = title;
+    }
+    getDescription() {
+        return this.description;
+    }
+    setDescription(description) {
+        this.description = description;
+    }
+    getIcons() {
+        return this.icons;
+    }
+    setIcons(icons) {
+        this.icons = icons;
+    }
+    getMeta() {
+        return this.meta;
+    }
+    setMeta(meta) {
+        this.meta = meta;
+    }
+    hashCode() {
+        // Simple hash code implementation based on name
+        let hash = 0;
+        if (this.name.length === 0)
+            return hash;
+        for (let i = 0; i < this.name.length; i++) {
+            const chr = this.name.charCodeAt(i);
+            hash = ((hash << 5) - hash) + chr;
+            hash |= 0; // Convert to 32bit integer
+        }
+        return hash;
+    }
+    equals(obj) {
+        if (this === obj) {
+            return true;
+        }
+        if (obj === null || obj === undefined || typeof obj !== 'object') {
+            return false;
+        }
+        if (this.constructor !== obj.constructor) {
+            return false;
+        }
+        const other = obj;
+        return this.name === other.name;
+    }
+}
+AbstractBase.DEFAULT_SEPARATOR = ".";
+//# sourceMappingURL=AbstractBase.js.map