Skip to main content
Glama

execute

Run JavaScript code to query, search, and modify fetched source code from npm, PyPI, crates, and GitHub repositories directly on the server.

Instructions

Query and mutate fetched source code. Data stays server-side.

Types:

interface Source { type: "npm" | "pypi" | "crates" | "repo"; name: string; version?: string; ref?: string; path: string; fetchedAt: string; repository: string; }

interface FileEntry { path: string; size: number; isDirectory: boolean; }

interface TreeNode { name: string; type: "file" | "dir"; children?: TreeNode[]; }

interface GrepResult { source: string; file: string; line: number; content: string; }

interface AstGrepMatch { file: string; line: number; column: number; text: string; metavars: Record<string, string>; // captured $VAR values }

interface ParsedSpec { type: "npm" | "pypi" | "crates" | "repo"; name: string; version?: string; ref?: string; repoUrl?: string; }

interface FetchedSource { source: Source; alreadyExists: boolean; }

interface RemoveResult { success: boolean; removed: string[]; }

declare const sources: Source[]; declare const cwd: string;

declare const opensrc: { // Read operations list(): Source[]; has(name: string, version?: string): boolean; get(name: string): Source | undefined; files(sourceName: string, glob?: string): Promise<FileEntry[]>; tree(sourceName: string, options?: { depth?: number }): Promise; grep(pattern: string, options?: { sources?: string[]; include?: string; maxResults?: number; }): Promise<GrepResult[]>; astGrep(sourceName: string, pattern: string, options?: { glob?: string; lang?: string | string[]; limit?: number; }): Promise<AstGrepMatch[]>; read(sourceName: string, filePath: string): Promise; readMany(sourceName: string, paths: string[]): Promise<Record<string, string>>; resolve(spec: string): Promise;

// Mutation operations fetch(specs: string | string[], options?: { modify?: boolean; }): Promise<FetchedSource[]>; remove(names: string[]): Promise; clean(options?: { packages?: boolean; repos?: boolean; npm?: boolean; pypi?: boolean; crates?: boolean; }): Promise; };

Fetch spec formats (input to opensrc.fetch):

  • zod -> npm package (latest or lockfile version)

  • zod@3.22.0 -> npm specific version

  • pypi:requests -> Python/PyPI package

  • crates:serde -> Rust/crates.io package

  • vercel/ai -> GitHub repo (default branch)

  • vercel/ai@v3.0.0 -> GitHub repo at tag/branch/commit

Source names (returned in FetchedSource.source.name, used for read/grep):

  • npm packages: "zod", "drizzle-orm", "@tanstack/react-query"

  • pypi packages: "requests", "numpy"

  • crates: "serde", "tokio"

  • GitHub repos: "github.com/vercel/ai", "github.com/anthropics/sdk"

IMPORTANT: After fetching, always use source.name for subsequent API calls.

Examples:

// List all fetched sources async () => { return opensrc.list().map(s => ({ name: s.name, type: s.type, version: s.version || s.ref })); }

// Fetch and explore structure with tree() async () => { const [{ source }] = await opensrc.fetch("zod"); return await opensrc.tree(source.name, { depth: 2 }); }

// Fetch a GitHub repo and read key files async () => { const [{ source }] = await opensrc.fetch("vercel/ai"); const files = await opensrc.readMany(source.name, [ "package.json", "README.md", "src/index.ts" ]); return { sourceName: source.name, files: Object.keys(files) }; }

// readMany with globs async () => { return await opensrc.readMany("zod", ["packages/*/package.json"]); }

// Fetch multiple packages async () => { const results = await opensrc.fetch(["zod", "drizzle-orm", "hono"]); return results.map(r => r.source.name); }

// Text search with grep async () => { const results = await opensrc.grep("export function parse", { sources: ["zod"], include: "*.ts" }); if (matches.length === 0) return "No matches"; const { source, file, line } = matches[0]; const content = await opensrc.read(source, file); return content.split("\n").slice(line - 1, line + 29).join("\n"); }

// Search across all sources async () => { const results = await opensrc.grep("throw new Error", { include: "*.ts", maxResults: 20 }); return results.map(r => ${r.source}:${r.file}:${r.line}); }

// AST search with astGrep (use $VAR for single node, $$$VAR for multiple) // Patterns: "function $NAME($$$)" | "const $X = $Y" | "useState($INIT)" | "$OBJ.$METHOD($$$)" async () => { const matches = await opensrc.astGrep("zod", "function $NAME($$$ARGS)", { glob: "**/*.ts", limit: 10 }); return matches.map(m => ({ file: m.file, name: m.metavars.NAME, line: m.line })); }

// Find entry points async () => { const files = await opensrc.files("github.com/vercel/ai", "**/{index,main}.{ts,js}"); if (files.length > 0) return await opensrc.read("github.com/vercel/ai", files[0].path); return "No entry point found"; }

// Batch read with error handling async () => { const files = await opensrc.readMany("zod", ["src/index.ts", "src/types.ts", "nonexistent.ts"]); // Failed reads have "[Error: ...]" as value return Object.keys(files).filter(p => !files[p].startsWith("[Error:")); }

// Remove sources async () => { return await opensrc.remove(["zod", "github.com/vercel/ai"]); }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesJavaScript async arrow function to execute
Behavior3/5

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

The description mentions that data stays server-side, which is a key behavioral trait. It also indicates the tool supports both query and mutation operations. However, without annotations, it lacks details on side effects, error handling, or resource limits. The extensive description of the opensrc API indirectly clarifies behavior but is not focused on the tool itself.

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

Conciseness2/5

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

The description is excessively long, containing type definitions, a full API declare block, and many examples. While the first two sentences are front-loaded and clear, the rest is verbose and repetitive. Many details could be moved to reference documentation, making the tool description hard to parse quickly.

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?

The description is comprehensive about the environment (opensrc API) but lacks explicit information about the tool's return value, error handling, or execution context. Given the complexity of the runtime, the description covers the code execution environment well, but not the tool's own behavior completely. The output schema is absent, so some completeness is lost.

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 input schema has 100% coverage with a description for the only parameter ('code' as JavaScript async arrow function). The description adds value by providing extensive examples of valid code snippets, but it does not explain parameter semantics beyond what the schema already states. The baseline of 3 is appropriate since schema coverage is complete.

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 that the tool queries and mutates fetched source code and that data stays server-side. This provides a clear verb+resource description, distinguishing the tool from hypothetical others that might expose data. However, the purpose could be slightly more specific about executing user-provided JavaScript code.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives, but since there are no siblings, this is less critical. It provides examples of common use cases like fetching and exploring code, which imply usage. However, there is no guidance on when not to use it (e.g., for non-code tasks).

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/dmmulroy/opensrc-mcp'

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