What can you do with this server?

The @penqwin/mcp server provides token-efficient, AST-based structural "skeletons" of a codebase to LLM agents, reducing token usage by 80–95% compared to sending raw source files. * get_repo_index: Retrieve a compact table of contents of the entire repository, listing all tracked source files and their top-level exported symbol names (~10–20 tokens per file). Always recommended as the first call. * get_folder_skeleton: Fetch structural skeletons (exports, function signatures, type definitions, doc comments) for all source files under a specified folder prefix (~50 tokens per file) — ideal for exploring a module or feature area. * get_file_skeleton: Retrieve the detailed AST skeleton of a single file, including all exports with signatures, imports, class members, and JSDoc comments — useful when deep detail on one file is needed. * search_symbols: Search the entire repository's AST index for files that export a specific symbol (function, class, type, or interface) by name, returning the file path, language, kind, signature, and doc comment. * get_repo_stats: Obtain aggregate statistics about the repository, including total file count and a breakdown by programming language, for a quick overview of the tech stack and codebase scale.

How do I use @penqwin/mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@penqwin/mcp show me the skeleton of src/main.ts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@penqwin/mcp

by Penqwin

Overview Schema Related Servers Score Discussions

JavaScript

Remote

@penqwin/mcp

An AST-based Model Context Protocol (MCP) server that provides token-efficient codebase skeletons to LLM agents (like Cursor, Claude Desktop, and Antigravity).

Instead of sending full raw source code files to the LLM, this server exposes structural "skeletons" (imports, exports, signatures, and JSDoc comments) of files and directories. This reduces token context sizes by 80% to 95% during codebase exploration and navigation.

Features & Tools

The server registers 5 core tools with the MCP protocol:

Tool Name	Description
`get_repo_index`	Returns a compact Table of Contents of the repository (all files + top-level exported names). ~10–20 tokens/file.
`get_folder_skeleton`	Retrieves structural skeletons for all files matching a directory/folder prefix.
`get_file_skeleton`	Retrieves the detailed structural skeleton (signatures, types, methods, parameters, and JSDocs) of a single file.
`search_symbols`	Queries the AST index to find files that export a specific class, function, struct, or type.
`get_repo_stats`	Returns aggregate statistics of the repository, including file counts and language breakdown.

Related MCP server: cctx-mcp

Configuration

The MCP server is configured entirely via environment variables.

Environment Variable	Description	Example
`PENQWIN_API_KEY`	Machine-to-machine API key generated from the DB	`ed_live_0e21cf14...`
`PENQWIN_ORG_ID`	The organization ID associated with the API key	`0db9f7b5-7206-...`
`PENQWIN_REPO`	The repository owner and name to target	`<org_name>/<repo_name>`
`PENQWIN_API_URL`	The REST API gateway URL of the `penqwin` backend	`http://app.penqwin.com`

IDE Integrations

You can integrate this MCP server with your favorite IDE using either npx (highly recommended for end-users, as it doesn't require cloning/building) or by pointing to your local build.

1. Direct Integration (via npm/npx)

This is the easiest setup for users. The IDE will automatically fetch and run the latest version of the package.

Cursor

Go to Cursor Settings -> Features -> MCP, and click + Add New MCP Server:

Name: penqwin
Type: command
Command: npx -y @penqwin/mcp
Add the required environment variables under the env settings.

Antigravity / Gemini Code Assistant

Add this to your mcp_config.json:

{
  "mcpServers": {
    "penqwin": {
      "command": "npx",
      "args": ["-y", "@penqwin/mcp"],
      "env": {
        "PENQWIN_API_KEY": "your_api_key",
        "PENQWIN_ORG_ID": "your_org_id",
        "PENQWIN_REPO": "your_repo",
        "PENQWIN_API_URL": "https://app.penqwin.com"
      }
    }
  }
}

Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "penqwin": {
      "command": "npx",
      "args": ["-y", "@penqwin/mcp"],
      "env": {
        "PENQWIN_API_KEY": "your_api_key",
        "PENQWIN_ORG_ID": "your_org_id",
        "PENQWIN_REPO": "your_repo",
        "PENQWIN_API_URL": "https://app.penqwin.com"
      }
    }
  }
}

2. Local Source Integration

If you have cloned the repository locally and compiled it:

Cursor

Command: node d:/Projects/EngDoc/eng-doc-mcp/dist/index.js (Use forward slashes for Windows paths)

Antigravity / Claude Desktop

Command: node
Args: ["d:/Projects/EngDoc/eng-doc-mcp/dist/index.js"]

Learn more:

Available Tools

5 tools

get_file_skeletonA

Returns the AST skeleton for a single specific source file. The skeleton includes: all exports with signatures, imports, class members, and doc comments. Use this when you need the details of one specific file after narrowing down from get_repo_index. For multiple related files, prefer get_folder_skeleton — it is one round trip.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes	Exact file path as it appears in the repository. Example: 'src/app/api/auth/route.ts'. Use the path from get_repo_index output.

TDQS

A4.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It describes what the tool returns (exports, imports, class members, doc comments) and implies it is a read operation. No side effects are mentioned, but the tool is inherently safe.

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?

Two sentences, front-loaded with the main purpose. Every sentence provides necessary information without fluff. Very efficient.

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 simplicity of the tool (one parameter, no output schema, no nesting), the description is complete enough. It might lack detail on the exact format of the AST skeleton, but that is acceptable for a simple tool.

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

Parameters4/5

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

The schema has 100% coverage for the single 'file' parameter with a clear example. The description adds value by specifying to use the exact path from get_repo_index output, which helps the agent understand how to construct the parameter.

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

Purpose5/5

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

The description clearly states the tool returns the AST skeleton for a specific source file, listing exports, imports, class members, and doc comments. It distinguishes from siblings by naming get_folder_skeleton and get_repo_index.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool (after narrowing down from get_repo_index for a single file) and when not to (for multiple related files, prefer get_folder_skeleton for one round trip).

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

get_folder_skeletonA

Returns compact AST skeletons for all source files under a given folder path prefix. Use this to understand a module or feature area without reading raw source files. Skeletons include: exports, function signatures, type definitions, and doc comments. Cost: ~50 tokens per file — much cheaper than raw source code. Tip: call get_repo_index first to discover valid folder paths.

ParametersJSON Schema

Name	Required	Description	Default
`folder`	Yes	Folder path prefix to fetch skeletons for. Example: 'src/auth', 'lib/utils'. Do NOT include a trailing slash.

TDQS

A5/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It discloses cost (~50 tokens per file), what skeletons include (exports, function signatures, types, doc comments), and that it's cheaper than raw source code.

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?

Four sentences, front-loaded with purpose, followed by usage, content description, and a cost tip. No unnecessary words; every sentence adds value.

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

Completeness5/5

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

Given no output schema, description adequately explains return content. Cost information and sibling differentiation make it complete for an effective selection and invocation.

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

Parameters5/5

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

Single parameter 'folder' is well-described in schema (100% coverage). Description adds example values and an important note ('Do NOT include a trailing slash'), enhancing understanding beyond schema.

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

Purpose5/5

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

The description clearly states it returns compact AST skeletons for source files under a folder path. It explicitly distinguishes from siblings like get_file_skeleton (single file) and get_repo_index (discover paths).

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

Usage Guidelines5/5

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

Provides explicit guidance: 'Use this to understand a module or feature area without reading raw source files.' Also includes a tip to call get_repo_index first, showing when to use this tool vs alternatives.

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

get_repo_indexA

Returns a compact table-of-contents for the repository 'myorg/myrepo'. Lists all tracked source files with their exported symbol names. ALWAYS call this FIRST before any other tool to understand the repository structure. Use the file paths returned here as input to get_folder_skeleton or get_file_skeleton. Cost: ~10-20 tokens per file — very cheap.

ParametersJSON Schema

Name	Required	Description	Default
`include_stats`	No	If true, also returns language breakdown and total file count.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses approximate cost (10-20 tokens per file) and behavior (returns file paths and symbols). No side effects or contradictions.

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?

Three concise sentences, front-loaded with purpose, then usage guidance, then cost. No unnecessary words.

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

Completeness5/5

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

Given the tool's simplicity (one optional param, no output schema), the description fully covers purpose, usage, cost, and relationship to sibling tools.

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?

Schema description coverage is 100%, so the schema already documents the parameter. Description does not add extra meaning beyond the schema's description of include_stats.

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

Purpose5/5

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

Clearly states 'returns a compact table-of-contents' with specific verb and resource ('myorg/myrepo'), listing files and symbols. Distinguishes from sibling tools like get_file_skeleton and get_folder_skeleton.

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?

Explicitly instructs to call this tool FIRST before others, and provides specific downstream usage (input to get_folder_skeleton or get_file_skeleton). Lacks explicit when-not-to-use but strong on when-to-use.

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

get_repo_statsA

Returns aggregate statistics for the repository 'myorg/myrepo'. Includes: total file count and a breakdown by programming language. Use this to understand the tech stack and scale of the codebase at a glance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It correctly indicates a read-only operation returning stats, with no side effects. It does not explicitly state read-only, but the behavior is straightforward.

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?

Two sentences, no redundancy. The first sentence states the action, the second gives usage context. Every word earns its place.

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

Completeness5/5

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

For a simple read-only aggregate tool with 0 parameters and no output schema, the description is complete. It specifies what is returned (total count and breakdown by language) and the target repository.

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

Parameters4/5

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

No parameters exist, and the schema coverage is 100%. According to guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter info.

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

Purpose5/5

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

The description clearly states it returns aggregate statistics for a specific repository, including total file count and breakdown by language. It distinguishes from siblings like get_file_skeleton (file structure) and search_symbols (search).

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?

Explicitly says 'Use this to understand the tech stack and scale of the codebase at a glance.' This provides clear when-to-use guidance, though it does not explicitly mention when not to use or alternatives.

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

search_symbolsA

Searches the entire repository for files that export a specific symbol name. Use this to find where a function, class, type, or interface is defined. Returns: file path, language, kind (function/class/type/etc.), signature, and doc comment. Example: search for 'createClient' to find all files that export a function by that name.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	The exact exported symbol name to search for. Case-sensitive. Example: 'createClient', 'UserSchema', 'POST'.

TDQS

A4/5.0

Behavior3/5

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

The description lists return fields and gives an example, but lacks additional behavioral context such as performance or case-sensitivity (though case-sensitivity is in the schema). With no annotations, the burden is on the description, which is adequate but not thorough.

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?

Two sentences plus an example, all front-loaded with purpose and usage, no unnecessary words.

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?

For a simple tool with one parameter and no output schema, the description adequately covers what the tool does and what it returns, but could mention that only exported symbols are searched.

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 single parameter is well-documented in the schema (100% coverage), and the description reinforces its usage with an example, but does not add significant new meaning beyond the schema.

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

Purpose5/5

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

The description clearly states it searches for exported symbol names across the repository, distinguishing it from sibling tools that deal with file skeletons, indexes, or stats.

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?

Provides guidance on when to use (to find where symbols are defined) and includes an example, but does not explicitly mention when not to use or compare to alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 21, 2026
- First observedget_file_skeleton
- First observedget_folder_skeleton
- First observedget_repo_index
- First observedget_repo_stats
- First observedsearch_symbols

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct aspect of repository exploration (index, stats, file skeleton, folder skeleton, symbol search) with clear instructions to avoid overlap.

Naming Consistency4/5

Most tools follow the get_* pattern, but search_symbols deviates slightly. Overall pattern is clear and predictable.

Tool Count5/5

Five tools cover the essential needs for repository exploration without being excessive or insufficient.

Completeness5/5

The set covers structure overview, detailed file analysis, and symbol search, meeting common code exploration needs.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
Axis Iliad — Codebase Intelligence For Agentic Commerce A
io.github.lastmanupinc-hub
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Code Analysis Developer Tools Documentation Access
4
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211

Related MCP Servers

token-pilot
Developer Tools Code Analysis File Systems
Digital-Threads
A
license
A
quality
B
maintenance
MCP server that reduces token consumption in AI coding assistants by up to 90% via structural reads, PreToolUse hooks, and tp-\* subagents.
Updated 11 days ago (2026-08-27 10:17 UTC)
25
687
5
MIT
cctx-mcp
Developer Tools Code Analysis Version Control
nikondrat
A
license
Not graded
quality
C
maintenance
An MCP server that provides structure-aware code analysis (symbol trees, dependencies, docs) to reduce AI agent token consumption by up to 99%, along with Git commit intelligence.
Updated 2 months ago (2026-06-29 14:16 UTC)
MIT
CodeSift
Code Analysis Developer Tools
greglas75
A
license
Not graded
quality
B
maintenance
Token-efficient code intelligence MCP server that indexes codebases with tree-sitter AST parsing and provides 150 tools for AI agents, using 61-95% fewer tokens than traditional grep/Read workflows.
Updated 11 hours ago (2026-09-06 16:01 UTC)
380
4
Business Source 1.1
cerberus-mcp
Code Analysis Developer Tools
Undermybelt
A
license
Not graded
quality
C
maintenance
An MCP server that provides ultra-efficient code exploration through AST analysis, reducing LLM token usage by up to 95% while enabling instant call graph generation and dependency analysis for massive codebases.
Updated 7 months ago (2026-02-11 07:23 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Penqwin/penqwin-mcp'

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