en es ja ko zh

mcp-server-pacman

Name: mcp-server-pacman
Author: oborchers

by oborchers

Overview Schema Source Related Servers Discussions Admin

Python

Remote

팩맨 로고

팩맨 MCP 서버

패키지 인덱스 쿼리 기능을 제공하는 모델 컨텍스트 프로토콜 서버입니다. 이 서버를 통해 LLM은 PyPI, npm, crates.io, Docker Hub, Terraform Registry와 같은 패키지 저장소에서 정보를 검색하고 가져올 수 있습니다.

사용 가능한 도구

search_package - 패키지 인덱스에서 패키지 검색
- index (문자열, 필수): 검색할 패키지 인덱스("pypi", "npm", "crates", "terraform")
- query (문자열, 필수): 패키지 이름 또는 검색 쿼리
- limit (정수, 선택 사항): 반환할 최대 결과 수(기본값: 5, 최대값: 50)
package_info - 특정 패키지에 대한 자세한 정보를 가져옵니다.
- index (문자열, 필수): 쿼리할 패키지 인덱스("pypi", "npm", "crates", "terraform")
- name (문자열, 필수): 패키지 이름
- version (문자열, 선택 사항): 정보를 가져올 특정 버전(기본값: 최신)
search_docker_image - Docker Hub에서 Docker 이미지 검색
- query (문자열, 필수): 이미지 이름 또는 검색 쿼리
- limit (정수, 선택 사항): 반환할 최대 결과 수(기본값: 5, 최대값: 50)
docker_image_info - 특정 Docker 이미지에 대한 자세한 정보를 가져옵니다.
- name (문자열, 필수): 이미지 이름(예: 사용자/저장소 또는 라이브러리/저장소)
- tag (문자열, 선택 사항): 특정 이미지 태그(기본값: 최신)
terraform_module_latest_version - Terraform 모듈의 최신 버전을 가져옵니다.
- name (문자열, 필수): 모듈 이름(형식: 네임스페이스/이름/공급자)

프롬프트

검색_파이파이
- PyPI에서 Python 패키지 검색
- 인수:
  - query (문자열, 필수): 패키지 이름 또는 검색 쿼리
pypi_info
- 특정 Python 패키지에 대한 정보 얻기
- 인수:
  - name (문자열, 필수): 패키지 이름
  - version (문자열, 선택 사항): 특정 버전
검색_npm
- npm에서 JavaScript 패키지 검색
- 인수:
  - query (문자열, 필수): 패키지 이름 또는 검색 쿼리
npm_info
- 특정 JavaScript 패키지에 대한 정보 가져오기
- 인수:
  - name (문자열, 필수): 패키지 이름
  - version (문자열, 선택 사항): 특정 버전
검색 상자
- crates.io에서 Rust 패키지를 검색하세요
- 인수:
  - query (문자열, 필수): 패키지 이름 또는 검색 쿼리
상자 정보
- 특정 Rust 패키지에 대한 정보 가져오기
- 인수:
  - name (문자열, 필수): 패키지 이름
  - version (문자열, 선택 사항): 특정 버전
검색_도커
- Docker Hub에서 Docker 이미지 검색
- 인수:
  - query (문자열, 필수): 이미지 이름 또는 검색 쿼리
도커_인포
- 특정 Docker 이미지에 대한 정보 가져오기
- 인수:
  - name (문자열, 필수): 이미지 이름(예: 사용자/저장소)
  - tag (문자열, 선택 사항): 특정 태그
검색_테라폼
- Terraform 레지스트리에서 Terraform 모듈 검색
- 인수:
  - query (문자열, 필수): 모듈 이름 또는 검색 쿼리
테라폼_인포
- 특정 Terraform 모듈에 대한 정보 가져오기
- 인수:
  - name (문자열, 필수): 모듈 이름(형식: 네임스페이스/이름/공급자)
테라폼 최신 버전
- 특정 Terraform 모듈의 최신 버전을 받으세요
- 인수:
  - name (문자열, 필수): 모듈 이름(형식: 네임스페이스/이름/공급자)

설치

uv 사용(권장)

uv 사용하면 별도의 설치가 필요하지 않습니다. uvx 사용하여 mcp-server-pacman을 직접 실행합니다.

PIP 사용

또는 pip를 통해 mcp-server-pacman 설치할 수 있습니다.

지엑스피1

설치 후 다음을 사용하여 스크립트로 실행할 수 있습니다.

python -m mcp_server_pacman

Docker 사용하기

Docker 이미지를 사용할 수도 있습니다.

docker pull oborchers/mcp-server-pacman:latest
docker run -i --rm oborchers/mcp-server-pacman

Related MCP server: JSR MCP

구성

Claude.app에 대한 구성

Claude 설정에 추가:

"mcpServers": {
  "pacman": {
    "command": "uvx",
    "args": ["mcp-server-pacman"]
  }
}

"mcpServers": {
  "pacman": {
    "command": "docker",
    "args": ["run", "-i", "--rm", "oborchers/mcp-server-pacman:latest"]
  }
}

"mcpServers": {
  "pacman": {
    "command": "python",
    "args": ["-m", "mcp-server-pacman"]
  }
}

VS Code에 대한 구성

수동 설치의 경우, VS Code의 사용자 설정(JSON) 파일에 다음 JSON 블록을 추가하세요. Ctrl + Shift + P 를 누르고 Preferences: Open User Settings (JSON) 입력하면 됩니다.

원하는 경우, 작업 공간의 .vscode/mcp.json 파일에 추가할 수 있습니다. 이렇게 하면 다른 사용자와 구성을 공유할 수 있습니다.

mcp.json 파일을 사용하려면 mcp 키가 필요합니다.

{
  "mcp": {
    "servers": {
      "pacman": {
        "command": "uvx",
        "args": ["mcp-server-pacman"]
      }
    }
  }
}

{
  "mcp": {
    "servers": {
      "pacman": {
        "command": "docker",
        "args": ["run", "-i", "--rm", "oborchers/mcp-server-pacman:latest"]
      }
    }
  }
}

사용자 정의 - 사용자 에이전트

기본적으로 서버는 사용자 에이전트를 사용합니다.

ModelContextProtocol/1.0 Pacman (+https://github.com/modelcontextprotocol/servers)

구성의 args 목록에 --user-agent=YourUserAgent 인수를 추가하여 이를 사용자 정의할 수 있습니다.

개발

테스트 실행

모든 테스트를 실행합니다.
```
uv run pytest -xvs
```

특정 테스트 카테고리를 실행하세요:

# Run all provider tests
uv run pytest -xvs tests/providers/

# Run integration tests for a specific provider
uv run pytest -xvs tests/integration/test_pypi_integration.py

# Run specific test class
uv run pytest -xvs tests/providers/test_npm.py::TestNPMFunctions

# Run a specific test method
uv run pytest -xvs tests/providers/test_pypi.py::TestPyPIFunctions::test_search_pypi_success

코드 스타일 확인:

uv run ruff check .
uv run ruff format --check .

형식 코드:
```
uv run ruff format .
```

디버깅

MCP 검사기를 사용하여 서버를 디버깅할 수 있습니다. UVX 설치의 경우:

npx @modelcontextprotocol/inspector uvx mcp-server-pacman

또는 특정 디렉토리에 패키지를 설치했거나 해당 디렉토리에서 개발 중인 경우:

cd path/to/pacman
npx @modelcontextprotocol/inspector uv run mcp-server-pacman

릴리스 프로세스

이 프로젝트에서는 자동화된 릴리스를 위해 GitHub Actions를 사용합니다.

pyproject.toml 에서 버전을 업데이트하세요
git tag vX.YZ 로 새 태그를 만듭니다(예: git tag v0.1.0 )
git push --tags 로 태그를 푸시합니다.

이렇게 하면 자동으로 다음이 수행됩니다.

pyproject.toml 의 버전이 태그와 일치하는지 확인하세요.
테스트 및 린트 검사 실행
PyPI에 빌드하고 게시
oborchers/mcp-server-pacman:latest 및 oborchers/mcp-server-pacman:XYZ 로 Docker Hub에 빌드하고 게시합니다.

프로젝트 구조

코드베이스는 다음 구조로 구성됩니다.

src/mcp_server_pacman/
├── models/             # Data models/schemas
├── providers/          # Package registry API clients
│   ├── pypi.py         # PyPI API functions
│   ├── npm.py          # npm API functions
│   ├── crates.py       # crates.io API functions
│   ├── dockerhub.py    # Docker Hub API functions
│   └── terraform.py    # Terraform Registry API functions
├── utils/              # Utilities and helpers
│   ├── cache.py        # Caching functionality
│   ├── constants.py    # Shared constants
│   └── parsers.py      # HTML parsing utilities
├── __init__.py         # Package initialization
├── __main__.py         # Entry point
└── server.py           # MCP server implementation

테스트는 비슷한 구조를 따릅니다.

tests/
├── integration/        # Integration tests (real API calls)
├── models/             # Model validation tests
├── providers/          # Provider function tests
└── utils/              # Test utilities

기여하다

mcp-server-pacman의 확장 및 개선을 위한 여러분의 참여를 기다립니다. 새로운 패키지 인덱스 추가, 기존 기능 개선, 문서 개선 등 어떤 목적이든 여러분의 의견은 소중합니다.

다른 MCP 서버 및 구현 패턴의 예는 https://github.com/modelcontextprotocol/servers를 참조하세요.

풀 리퀘스트를 환영합니다! mcp-server-pacman을 더욱 강력하고 유용하게 만들기 위한 새로운 아이디어, 버그 수정, 개선 사항을 자유롭게 공유해 주세요.

특허

mcp-server-pacman은 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 조건에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.

Available Tools

5 tools

docker_image_infoC

Get detailed information about a specific Docker image

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Image name (e.g., user/repo or library/repo)
`tag`	No	Specific image tag (default: latest)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states a generic 'get information' without specifying side effects, required permissions, network dependencies, or the nature of the returned data. This is insufficient for an agent to anticipate tool behavior.

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 single sentence is concise and front-loaded with the key action. No extraneous words or redundancy.

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

Completeness2/5

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

The tool has 2 parameters and no output schema. The description fails to explain what 'detailed information' includes (e.g., layers, config, metadata). An agent cannot predict the return format or completeness without additional context.

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 coverage is 100% (both parameters have descriptions). The tool description adds no additional meaning beyond what the schema provides. Per guidelines, baseline 3 applies; the description does not enhance understanding of parameter usage.

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 'Get detailed information about a specific Docker image' clearly states the tool's purpose with a specific verb ('Get') and resource ('Docker image'). However, it does not differentiate from sibling tools like search_docker_image, leaving ambiguity about what 'detailed information' entails.

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?

No guidance is provided on when to use this tool versus alternatives such as search_docker_image or package_info. The agent receives no indication of prerequisites, exclusions, or appropriate context.

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

package_infoC

Get detailed information about a specific package

ParametersJSON Schema

Name	Required	Description
`index`	Yes	Package index to query (pypi, npm, crates, terraform)
`name`	Yes	Package name
`version`	No	Specific version to get info for (default: latest)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the basic action. It does not confirm whether the operation is read-only, destructive, or has any side effects, which is a significant gap for a tool likely performing external queries.

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 a single, concise sentence with no wasted words. It is efficiently front-loaded with the action and resource.

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

Completeness2/5

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

The tool has no output schema, yet the description only vaguely says 'detailed information'. It does not specify what fields or structure the response contains, leaving the agent without adequate context for handling the result.

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 for parameters, so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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 verb 'Get' and resource 'detailed information about a specific package'. It is specific enough to distinguish from sibling tools like 'search_package' and 'docker_image_info', though it does not explicitly differentiate them.

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?

No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

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

search_docker_imageB

Search for Docker images in Docker Hub

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Image name or search query
`limit`	No	Maximum number of results to return

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries the full burden, but it only states the function without disclosing behavioral traits like read-only nature, rate limits, or default pagination. Basic search behavior is implied but not explicitly guaranteed.

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

Conciseness4/5

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

The description is a single, efficient sentence with no repetition or fluff. While brief, it front-loads the core purpose, earning points for conciseness, though slightly more context could fit without becoming verbose.

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 no output schema and simple parameters, the description suffices for a basic search. However, it does not clarify return format (e.g., tags, repositories, pagination), leaving some ambiguity for an agent. Adequate but not fully complete.

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 covers 100% of parameters with clear descriptions (e.g., 'Image name or search query', 'Maximum number of results'). The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.

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 verb 'Search' and the resource 'Docker images' with location 'Docker Hub', making the purpose unmistakable. It effectively distinguishes from sibling tools like `docker_image_info` and `search_package`.

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?

No guidance is provided on when to use this tool versus alternatives such as `docker_image_info` (for details) or `search_package` (for non-Docker packages). The description lacks any context for tool selection.

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

search_packageB

Search for packages in package indices (PyPI, npm, crates.io, Terraform Registry)

ParametersJSON Schema

Name	Required	Description
`index`	Yes	Package index to search (pypi, npm, crates, terraform)
`query`	Yes	Package name or search query
`limit`	No	Maximum number of results to return

TDQS

B3.4/5.0

Behavior2/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 only states the basic purpose without disclosing behavioral traits such as rate limits, authentication requirements, error handling, or the structure of the response. This is minimal transparency for a search tool.

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 a single, well-structured sentence that immediately conveys the verb and resource. It is front-loaded and contains no unnecessary words.

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

Completeness2/5

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

The description lacks information about the output format or what the search results contain. Since there is no output schema, the description should have provided context on the return structure to help the agent interpret results. This gap reduces completeness.

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 for all parameters. The tool description adds no extra meaning beyond what the schema already provides (e.g., listing indices that match the enum). Baseline 3 is appropriate given high schema coverage.

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 specifies the action 'search for packages' and the resource 'package indices', with explicit examples (PyPI, npm, crates.io, Terraform Registry). It effectively distinguishes from sibling tools like 'package_info' which likely provides details on a specific package.

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 implies usage for searching packages but does not provide explicit guidance on when to use this tool versus alternatives like 'package_info' or 'search_docker_image'. No exclusions or context-driven triggers are mentioned.

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

terraform_module_latest_versionB

Get the latest version of a Terraform module

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Module name (format: namespace/name/provider)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 'Get', implying read-only, but no disclosure of potential errors, caching, rate limits, or behavior when module not found.

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

Conciseness4/5

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

The description is a single, clear sentence. It is concise and front-loaded, though slightly minimal for a simple tool.

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 simplicity (one parameter, no output schema, no annotations), the description is minimally complete. However, it lacks details about return values or error states, which are needed for full understanding.

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 coverage is 100% (the single parameter is well-described). The description does not add extra semantics beyond the schema's parameter description, earning a baseline score of 3.

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 action: 'Get the latest version of a Terraform module'. It uses a specific verb and resource, and distinguishes from sibling tools (docker_image_info, package_info, etc.) that deal with different domains.

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?

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or explicit when-to-use context.

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.

5 tool updatesv1.0.0Aug 14, 2025
- First observeddocker_image_info
- First observedpackage_info
- First observedsearch_docker_image
- First observedsearch_package
- First observedterraform_module_latest_version

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-04-29 16:05 across 5 tools

Disambiguation5/5

Each tool targets a distinct resource and action: Docker images have separate search and info tools, packages similarly, and Terraform modules have a dedicated version lookup. No overlap between resources.

Naming Consistency3/5

Names use snake_case but the ordering of resource and action varies: e.g., 'docker_image_info' (resource_action) vs 'search_docker_image' (action_resource). 'terraform_module_latest_version' uses a different pattern with an adjective. This inconsistency could cause confusion.

Tool Count4/5

With 5 tools, the server is focused and well-scoped for an informational package manager. It covers Docker, general packages, and Terraform modules without being too sparse.

Completeness3/5

The server provides search and info for Docker and packages, which is reasonable for an informational tool. However, only one Terraform module operation exists, and missing CRUD operations like install or delete are on the boundary of the domain.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
MCP Registry Search A
io.github.Spacemandomains
Search and browse every MCP server in the Model Context Protocol registry.
Search Developer Tools
321
todo.vu AOAuth
io.github.mooball
Model Context Protocol server for todo.vu task management and time tracking.
Payments & Billing Project Management Workplace & Productivity
2

Related MCP Servers

MCP Server RubyGems
Developer Tools Data Platforms
6
F
license
A
quality
D
maintenance
A Model Context Protocol server that allows interaction with the RubyGems.org API to fetch metadata about Ruby packages, search gems, and explore dependencies and ownership information.
Updated 2 years ago (2025-03-08 04:32 UTC)
6
1
-
JSR MCP
RAG Systems Developer Tools Version Control
wyattjoh
A
license
Not graded
quality
D
maintenance
Model Context Protocol server for the JSR (JavaScript Registry)
Updated 9 months ago (2026-01-11 09:08 UTC)
4
MIT
PyPI Query MCP Server
Developer Tools Search
loonghao
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server for querying PyPI package information, dependencies, and compatibility checking. Supports advanced dependency analysis, download statistics, and trending analysis.
Updated 15 days ago (2026-09-14 01:31 UTC)
34 PyPI
18
MIT
Package Intel MCP Server
Developer Tools CI/CD & DevOps Search
BUZDOLAPCI
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server for querying package registries (npm, PyPI, crates.io) to retrieve metadata, release timelines, and maintenance signals.
Updated 8 months ago (2026-01-17 10:19 UTC)
1
-