MCP Tools and Dependent Types

Summary

August 17, 2025 MCP tools with dependent types This summer, I’ve been playing a bit with writing an MCP server for Defold editor. The idea was to give Claude access to evaluating Lua code in the editor scripting context, so it can use the APIs available for querying and modifying game content. The best word to describe the experience is entertaining — it has a very vague idea of the available APIs, and prefers to experiment by evaluating code instead of browsing documentation, which results in low accuracy and a need to steer it: It was entertaining because it was inaccurate, but still trying really hard, and eventually succeeding. I think, as novelty wears off and agentic LLM approaches mature, the need for accuracy will increase dramatically — this “entertainment” will become an annoying bug. Of course, there is already a solution for this inaccuracy: every LLM service worth its salt supports structured outputs defined by JSON schemas; in the context of MCP, it means that tools define input schemas, and it’s a responsibility of the AI agent to construct an input satisfying the schema. For example, here is a tool definition: { "name": "get_weather", "inputSchema": { "type": "object", "properties": { "location": {"type": "string"} }, "required": ["location"] } } By the way, since tools are essentially functions, the same thing can be written in a more concise way, which I think fits better for this post: get_weather({location: string}) The problem As soon as I started thinking about designing proper tools with JSON schemas for Defold, I hit an issue. There is something you can easily do with structured outputs if you make your own integrated LLM chat, that you can’t do in MCP: resolving input JSON schemas dynamically. Or, in programming terms, there is no way to define generic functions with dependent types: edit_resource({resource: string, props: PropsOf resource}) Simple example tools like get_weather have well-defined inputs. In more complex domains, it’s common ...