Skip to main content
Glama
mozicim

Node Code Sandbox MCP

by mozicim

get_dependency_types

Fetch TypeScript definitions for npm packages to inspect APIs and types before running Node.js scripts with unfamiliar dependencies.

Instructions

Given an array of npm package names (and optional versions), fetch whether each package ships its own TypeScript definitions or has a corresponding @types/… package, and return the raw .d.ts text.

Useful whenwhen you're about to run a Node.js script against an unfamiliar dependency and want to inspect what APIs and types it exposes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dependenciesYes

Implementation Reference

  • The handler function for the get_dependency_types tool. It takes a list of dependencies, fetches their TypeScript definitions from npm registry or @types packages, and returns whether types are available along with the raw .d.ts content.
    export default async function getDependencyTypes({
      dependencies,
    }: {
      dependencies: { name: string; version?: string }[];
    }): Promise<McpResponse> {
      const results: {
        name: string;
        hasTypes: boolean;
        types?: string;
        typesPackage?: string;
        version?: string;
      }[] = [];
    
      for (const dep of dependencies) {
        const info: (typeof results)[number] = { name: dep.name, hasTypes: false };
        try {
          const pkgRes = await fetch(`https://registry.npmjs.org/${dep.name}`);
          if (pkgRes.ok) {
            const pkgMeta = (await pkgRes.json()) as any;
            const latestTag = pkgMeta['dist-tags']?.latest as string;
            const versionToUse = dep.version || latestTag;
            const versionData = pkgMeta.versions?.[versionToUse];
            // Check for in-package types
            if (versionData) {
              const typesField = versionData.types || versionData.typings;
              if (typesField) {
                const url = `https://unpkg.com/${dep.name}@${versionToUse}/${typesField}`;
                const contentRes = await fetch(url);
                if (contentRes.ok) {
                  info.hasTypes = true;
                  info.types = await contentRes.text();
                  info.version = versionToUse;
                  results.push(info);
                  continue;
                }
              }
            }
    
            // Fallback to @types package
            const sanitized = dep.name.replace('@', '').replace('/', '__');
            const typesName = `@types/${sanitized}`;
            const typesRes = await fetch(
              `https://registry.npmjs.org/${encodeURIComponent(typesName)}`
            );
            if (typesRes.ok) {
              const typesMeta = (await typesRes.json()) as any;
              const typesVersion = typesMeta['dist-tags']?.latest as string;
              const typesVersionData = typesMeta.versions?.[typesVersion];
              const typesField =
                typesVersionData?.types ||
                typesVersionData?.typings ||
                'index.d.ts';
              const url = `https://unpkg.com/${typesName}@${typesVersion}/${typesField}`;
              const contentRes = await fetch(url);
              if (contentRes.ok) {
                info.hasTypes = true;
                info.typesPackage = typesName;
                info.version = typesVersion;
                info.types = await contentRes.text();
              }
            }
          }
        } catch (e) {
          logger.info(`Failed to fetch type info for ${dep.name}: ${e}`);
        }
        results.push(info);
      }
    
      return { content: [textContent(JSON.stringify(results))] };
    }
  • Zod schema defining the input for the get_dependency_types tool: an array of dependencies with name and optional version.
    export const argSchema = {
      dependencies: z.array(
        z.object({
          name: z.string(),
          version: z.string().optional(),
        })
      ),
    };
  • src/server.ts:100-112 (registration)
    Registration of the 'get_dependency_types' tool on the MCP server, specifying name, description, input schema, and handler function.
    server.tool(
      'get_dependency_types',
      `
      Given an array of npm package names (and optional versions), 
      fetch whether each package ships its own TypeScript definitions 
      or has a corresponding @types/… package, and return the raw .d.ts text.
      
      Useful whenwhen you're about to run a Node.js script against an unfamiliar dependency 
      and want to inspect what APIs and types it exposes.
      `,
      getDependencyTypesSchema,
      getDependencyTypes
    );
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (fetches TypeScript definitions) and the output (raw .d.ts text), which is helpful. However, it doesn't disclose important behavioral traits like whether this makes network calls, potential rate limits, authentication requirements, error handling, or what happens when packages don't have TypeScript definitions. The description adds value but leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded. The first sentence clearly states the tool's function, and the second sentence provides useful context without unnecessary elaboration. Every sentence earns its place, and there's no wasted verbiage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (fetching TypeScript definitions for npm packages), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It explains the purpose and usage context well, but lacks details about behavioral traits, parameter specifics, and output format beyond 'raw .d.ts text.' For a tool that likely involves network calls and complex data retrieval, more completeness would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It mentions 'array of npm package names (and optional versions)' which maps to the 'dependencies' parameter, providing basic semantics. However, it doesn't explain the structure of the array items (objects with name and version properties), format expectations for version strings, or constraints on the array size. The description adds some meaning but doesn't fully compensate for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'fetch whether each package ships its own TypeScript definitions or has a corresponding @types/… package, and return the raw .d.ts text.' This specifies the verb (fetch/return), resource (TypeScript definitions), and output format. However, it doesn't explicitly distinguish this tool from its siblings (like run_js or sandbox_exec), which could potentially be used for similar dependency inspection tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'Useful when you're about to run a Node.js script against an unfamiliar dependency and want to inspect what APIs and types it exposes.' This gives a specific scenario and motivation. However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools, which would be needed for a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mozicim/node-code-sandbox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server