Skip to main content
Glama

execute

Execute server-side JavaScript to query and mutate fetched source code from npm, PyPI, crates.io, and GitHub repositories while keeping data 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
Behavior4/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 does an excellent job explaining the opensrc API's capabilities including read operations (list, has, get, files, tree, grep, astGrep, read, readMany, resolve) and mutation operations (fetch, remove, clean). It provides detailed interface definitions and practical examples, though it doesn't explicitly mention error handling or performance characteristics.

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 extremely long (over 100 lines) and includes extensive interface declarations, API documentation, and numerous examples. While informative, it's not appropriately sized or front-loaded. The core purpose is buried among implementation details. Many of the interface definitions could be streamlined or referenced rather than fully included.

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

Completeness4/5

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

Given the complexity of this tool (executing arbitrary JavaScript code against a source code API), the description provides substantial context. It defines all relevant interfaces, documents the opensrc API comprehensively, provides format specifications, and includes practical examples. Without annotations or output schema, this level of detail is quite helpful, though the organization could be improved.

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% description coverage with a clear parameter 'code' described as 'JavaScript async arrow function to execute.' The description doesn't add any additional parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline is 3. The description focuses on what code should contain rather than the parameter itself.

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 begins with 'Query and mutate fetched source code' which clearly states the tool's purpose as both reading and modifying source code. It distinguishes this as a server-side operation with 'Data stays server-side.' However, it doesn't need to differentiate from siblings since there are none, so it's not a full 5.

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

Usage Guidelines2/5

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

The description provides extensive examples of how to use the opensrc API, but lacks explicit guidance on when to use this tool versus alternatives. There's no discussion of prerequisites, constraints, or typical use cases beyond the examples. The examples imply usage patterns but don't offer structured guidance.

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