@Tool decorator loses autocomplete and does not surface TypeScript errors when config is partially invalid

[alexmercerpo]

Summary

When using the @Tool(...) decorator in TypeScript, if the tool config is slightly invalid or incomplete, editor autocomplete can disappear and TypeScript errors are not shown clearly.

This makes the developer experience confusing, because a small mistake in the decorator config breaks IntelliSense and also hides the actual typing problem.

Example

import { Tool, ToolContext } from '@frontmcp/sdk';
import { z } from 'zod';

@Tool({
  name: 'add',
  description: 'Add two numbers',
  inputSchema: { a: z.number(), b: z.number() },
  outputSchema: { result: z.number() },

  concurrency: {
    // maxConcurrent: 1
  },
})
export default class AddTool extends ToolContext {
  async execute(input: { a: number; b: number }) {
    return {
      result: input.a + input.b,
    };
  }
}

Actual behavior

When the decorator config is not fully aligned with the expected schema:

• autocomplete stops working or becomes unreliable
• the editor does not show a clear TypeScript error in the decorator usage
• "Go to Definition" for Tool is also confusing

In my case, Tool resolves to:

export { FrontMcpTool, FrontMcpTool as Tool, frontMcpTool, frontMcpTool as tool };

and going to FrontMcpTool shows:

• Cannot find declaration to go to

But when the config is fully aligned with the expected schema, the richer declaration/type view appears correctly.

Expected behavior

• @Tool({...}) should keep autocomplete even when the config is partially invalid
• TypeScript should surface a clear error on the problematic field
• Go to Definition on Tool should consistently point to a useful public type/declaration
• small config mistakes should not degrade the entire editor experience

Notes

This seems related to how the decorator typing is exposed and how schema inference is coupled to the public API.

It also looks related to the Zod-shape-based inference for inputSchema / outputSchema, where once the generic inference path breaks, the decorator loses useful IntelliSense instead of showing a friendly typing error.

Suggestion

A possible improvement would be:

1. expose explicit public decorator config interfaces/types
2. keep those types stable for editor IntelliSense
3. derive validation/schema behavior from those types internally
4. ensure invalid fields produce direct TS errors instead of collapsing autocomplete

This would make the decorator API much easier to use in IDEs.