Searching by return type and by JSDoc description are the queries you cannot make against a pile of .d.ts files in a prompt, and they are exactly what an agent needs when writing against an internal SDK it was never trained on. The repository's own test API is written in a deliberately odd dialect so that a model cannot fake its way through — a good sign about what the project was trying to verify. Read the suspension notice before building on it.
An MCP server that loads TypeDoc-generated JSON for a TypeScript API and indexes it for querying. Instead of dumping the whole documentation into the prompt, an agent asks targeted questions about the parts it needs.
- `search_symbols` — find symbols by name, optionally filtered by kind
- `get_symbol_details` — full detail for one symbol
- `list_members` — the methods and properties of a class or interface
- `get_parameter_info` — the parameters of a function
- `find_implementations` — implementations of an interface, or subclasses of a class
- `search_by_return_type` and `search_by_description` — find functions by what they return, or by their JSDoc text
- `get_type_hierarchy` and `find_usages` — inheritance relationships, and where a type or function is used
Node.js and npm. Generate the TypeDoc JSON for your API first — there is a documented path for starting from an existing .d.ts file — then run `mcp-typescribe` with that JSON file as an argument in your client config. Note the banner on the repository: public development is suspended, with the authors directing yFiles users to a successor server.
One command — npx -y mcp-typescribe