When AI Gets Your Types Wrong

Today I was writing some unit and integration tests using Claude Code, and I noticed something that was driving me nuts: it really preferred to type cast unknown properties as any. What I really wanted it to do was use the proper type definitions to mock the objects appropriately.

It's one of those small frustrations that compounds when you're trying to maintain type safety in your tests. You know the types exist—they're sitting right there in your node_modules—but the AI keeps reaching for the escape hatch.

The Workaround That Sparked an Idea

So I tried something different. I went to the node module type definition of the third-party library I was mocking inside my codebase. I passed that path to Claude Code. I asked it to look there, find the appropriate type definitions, and then create mocks based off those types. And it did pretty well.

But really, what this got me thinking was—I should think about how to solve this programmatically.

This is the pattern I've noticed with AI tools: they excel when they have the right context, but they struggle when that context is buried in places they can't easily access. The TypeScript definitions were always there, sitting in node_modules, but Claude Code couldn't efficiently parse and understand them in the moment it needed to create a mock.

Building TypeScript Definitions MCP

So I had Claude Code build an MCP server that basically can do lookups against type definitions in node modules to give you information regarding those interfaces and types—from creating mocks all the way to trying to understand the purpose behind why things are built.

Out of that, I built typescript-definitions-mcp. It's an MCP server that you can hook up to Claude Code, Cursor, or any other AI IDE, and you can ask it to give you information regarding types.

The beauty of this approach is its simplicity. Instead of trying to teach AI tools how to navigate and understand TypeScript definition files on the fly, we give them a dedicated interface to query type information. The MCP server handles the heavy lifting of parsing definitions, understanding inheritance, and extracting relevant properties.

How I'm Using It

Here's a snippet of how it works in practice. When I need to understand the structure of a complex type, I can simply ask:

> Okay, great. What are all the properties on the daily advanced config?

⏺ typescript-definitions - lookup_type (MCP)(typeName: "DailyAdvancedConfig",
                                            packageName: "@daily-co/daily-js")
  ⎿  {
       "query": {
         "typeName": "DailyAdvancedConfig",
     … +207 lines (ctrl+r to expand)

⏺ DailyAdvancedConfig properties:

  Video/Audio Settings:
  - keepCamIndicatorLightOn?: boolean
  - h264Profile?: string
  - ...

Instead of manually digging through definition files or settling for any types, I get structured, queryable information about complex types. The AI can now create properly typed mocks, understand API surfaces, and help me write more robust code.

The Bigger Picture

This experience reinforced something I've been thinking about: the most effective use of AI tools isn't about replacing human expertise—it's about removing the friction between having an idea and implementing it. The frustration I felt wasn't about not knowing how to create proper mocks; it was about the tedious process of manually cross-referencing type definitions every time.

Tools like this MCP server don't make me a better programmer in the traditional sense. They don't teach me new algorithms or design patterns. What they do is compress the time between “I need to understand this type structure” and “I have the information I need to proceed.” That compression is where the real value lies.

I wanted to share how I'm using this and how I'm using AI tools to solve real-world problems. It's not about the grand vision of AI replacing developers—it's about the small, pragmatic improvements that make daily work more pleasant and productive.

Below is a link to my GitHub repo to check it out. I hope it's as useful to you as it's become to me.

What's Next

I'm curious to see how other developers use this tool and what additional type information would be most valuable. The MCP standard makes it easy to extend and customize, so I'm thinking about what other development friction points could be solved with similar approaches.

The goal isn't to build the most sophisticated tool possible—it's to build the most useful one. Sometimes that means solving small, specific problems really well rather than trying to boil the ocean.

If you end up trying it out, I'd love to hear how it works for your use case. The best tools evolve from real-world usage, not theoretical perfection.