Which integrations are available for this server?

Provides tools to check the latest version, rate package quality, and fetch llms.txt documentation for Dart/Flutter packages on pub.dev. Provides tools to check the latest version, rate package quality, and fetch llms.txt documentation for JavaScript/TypeScript packages on npm. Provides tools to check the latest version, rate package quality, and fetch llms.txt documentation for Python packages on PyPI. Provides tools to check the latest version, rate package quality, and fetch llms.txt documentation for Rust packages on crates.io.

How do I use MCP Package Hero?

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., "@MCP Package Hero Check the latest version and quality rating for 'requests'" 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.

MCP Package Hero

by moinsen-dev

Overview Schema Related Servers Score Discussions

Python

Remote

🦸 MCP Package Hero

PyPI Python 3.10+ FastMCP License: MIT Tests Coverage Type Check

A comprehensive Model Context Protocol (MCP) server for checking package versions and rating package quality across Python (PyPI), JavaScript/TypeScript (npm), Dart (pub.dev), and Rust (crates.io).

🎯 Purpose

MCP Package Hero helps you make informed decisions about packages by providing:

Version Information: Get the latest stable version of any package
Quality Ratings: Comprehensive quality analysis across multiple dimensions
llms.txt Documentation: Fetch and generate LLM-friendly documentation files

Package Hero focuses on four major ecosystems:

✅ Python packages on PyPI
✅ JavaScript/TypeScript packages on npm
✅ Dart/Flutter packages on pub.dev
✅ Rust packages on crates.io

Related MCP server: mcpypi

🚀 Features

Version Checking

Simple API: Get latest version for one or multiple packages
Fast: Sub-second response times with async operations
Batch Support: Check up to 10 packages at once

Quality Rating (v1.1.0+)

Comprehensive Analysis: Multi-dimensional package quality scoring
- 🔧 Maintenance Health (35%): Release frequency, issue resolution, PR activity
- 📊 Popularity (25%): Downloads, GitHub stars, community adoption
- ✨ Quality Metrics (40%): Documentation (35%), license (25%), tests (25%), llms.txt (15%)
Letter Grades: A+ to F rating system for quick assessment
Actionable Insights: Key strengths and red flags for each package
Ecosystem Integration: Leverages native scores (pub.dev pub points, npms.io scores)
llms.txt Bonus (v1.2.0+): Packages with llms.txt get bonus points (70 for llms.txt, 100 for both llms.txt + llms-full.txt)

llms.txt Support (v1.2.0+)

Fetch llms.txt: Get LLM-friendly documentation from package repositories
Generate llms.txt: Create standardized documentation for your projects
Multi-Source: Searches GitHub, homepages, and documentation sites
Validation: Parses and validates llms.txt format compliance
Smart Scanning: Automatically discovers documentation files in projects

Technical Excellence

LLM-Friendly: Designed specifically for AI assistants and agents
Type-Safe: Full type hints, Pydantic validation, and mypy compliance
Well-Tested: Comprehensive coverage for all features
Production-Ready: Modern Python best practices, timezone-aware, Pydantic V2

📦 Installation

From PyPI (Recommended)

The fastest and easiest way to use MCP Package Hero is directly from PyPI:

# No installation needed! Just use uvx to run it directly
uvx mcp-package-hero

# Or install it as a tool for repeated use
uv tool install mcp-package-hero

From Source (Development)

For development or contributing:

# Install uv if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh

# Clone the repository
git clone https://github.com/moinsen-dev/mcp-package-hero.git
cd mcp-package-hero

# Install dependencies
uv sync

# Install the package in editable mode
uv pip install -e .

🔧 Configuration

Add to your MCP client configuration (e.g., Claude Desktop, Cline, etc.):

Claude Desktop

Option 1: From PyPI (Recommended - Fast!)

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "package-hero": {
      "command": "uvx",
      "args": ["mcp-package-hero"]
    }
  }
}

Startup time: ~1-2 seconds (first run), ~0.5 seconds (cached) ⚡

Option 2: From GitHub (Slower)

{
  "mcpServers": {
    "package-hero": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/moinsen-dev/mcp-package-hero.git",
        "mcp-package-hero"
      ]
    }
  }
}

Option 3: From local directory (Development)

{
  "mcpServers": {
    "package-hero": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/mcp-package-hero",
        "mcp-package-hero"
      ]
    }
  }
}

Cline VSCode Extension

Edit ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json:

Option 1: From PyPI (Recommended - Fast!)

{
  "mcpServers": {
    "package-hero": {
      "command": "uvx",
      "args": ["mcp-package-hero"]
    }
  }
}

Option 2: From GitHub (Slower)

{
  "mcpServers": {
    "package-hero": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/moinsen-dev/mcp-package-hero.git",
        "mcp-package-hero"
      ]
    }
  }
}

Option 3: From local directory (Development)

{
  "mcpServers": {
    "package-hero": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/mcp-package-hero",
        "mcp-package-hero"
      ]
    }
  }
}

Claude Code

Add the server globally to Claude Code using the CLI:

Option 1: From PyPI (Recommended - Fast!)

claude mcp add-json package-hero '{"type":"stdio","command":"uvx","args":["mcp-package-hero"]}'

Option 2: From GitHub (Slower)

claude mcp add-json package-hero '{"type":"stdio","command":"uvx","args":["--from","git+https://github.com/moinsen-dev/mcp-package-hero.git","mcp-package-hero"]}'

Option 3: From local directory (Development)

claude mcp add-json package-hero '{"type":"stdio","command":"uv","args":["run","--directory","/path/to/mcp-package-hero","mcp-package-hero"]}'

📖 Usage

Tool 1: Get Latest Version

Check the latest version of a single package:

# Example queries for your LLM:
"What's the latest version of requests in Python?"
"Check the current version of react"
"Show me the latest version of the http package for Dart"
"What's the latest version of serde in Rust?"

Tool Name: get_latest_version

Parameters:

package_name (string): Name of the package
ecosystem (string): One of "python", "javascript", "dart", or "rust"

Example Response:

{
  "package_name": "requests",
  "ecosystem": "python",
  "latest_version": "2.31.0",
  "registry_url": "https://pypi.org/project/requests/",
  "checked_at": "2025-10-06T10:30:00Z",
  "status": "success"
}

Tool 2: Batch Version Check

Check multiple packages at once (max 10):

# Example query:
"Check the latest versions of requests (python), react (javascript), http (dart), and serde (rust)"

Tool Name: get_latest_versions_batch

Parameters:

packages (array): List of objects with package_name and ecosystem
max_packages (integer, optional): Limit (default: 10)

Example Response:

{
  "results": [
    {
      "package_name": "requests",
      "ecosystem": "python",
      "latest_version": "2.31.0",
      "status": "success"
    },
    {
      "package_name": "nonexistent-pkg",
      "ecosystem": "python",
      "latest_version": null,
      "status": "not_found"
    }
  ],
  "checked_at": "2025-10-06T10:30:00Z"
}

Tool 3: Rate Package Quality (v1.1.0+)

Get comprehensive quality rating for a package:

# Example queries:
"Rate the quality of the requests package"
"How good is the react package?"
"Give me a quality assessment of flutter_bloc"
"How does the serde crate rate?"

Tool Name: rate_package

Parameters:

package_name (string): Name of the package
ecosystem (string): One of "python", "javascript", "dart", or "rust"

Example Response:

{
  "package_name": "requests",
  "ecosystem": "python",
  "overall_score": 86.6,
  "letter_grade": "A-",
  "maintenance": {
    "score": 78.8,
    "last_release_days": 48,
    "release_frequency_score": 80.0,
    "issue_resolution_score": 100.0,
    "pr_merge_score": 44.2
  },
  "popularity": {
    "score": 100.0,
    "downloads": 855587647,
    "stars": 53340,
    "downloads_score": 100.0,
    "stars_score": 100.0
  },
  "quality": {
    "score": 85.0,
    "has_documentation": true,
    "has_license": true,
    "has_tests": null,
    "documentation_score": 100.0,
    "license_score": 100.0,
    "test_score": 50.0
  },
  "repository_url": "https://github.com/psf/requests",
  "license": "Apache-2.0",
  "description": "Python HTTP for Humans.",
  "insights": [
    "Strong issue resolution track record",
    "Highly popular with 100K+ monthly downloads",
    "Well-starred project (1000+ stars)",
    "High quality package with good documentation and license"
  ],
  "red_flags": [],
  "status": "success"
}

Tool 4: Get llms.txt (v1.2.0+)

Fetch llms.txt documentation file for a package:

# Example queries:
"Get the llms.txt file for fasthtml"
"Show me the documentation structure for react"
"Fetch llms.txt and llms-full.txt for flutter_bloc"
"Get the llms.txt for tokio"

Tool Name: get_llms_txt

Parameters:

package_name (string): Name of the package
ecosystem (string): One of "python", "javascript", "dart", or "rust"
include_full (boolean, optional): Also fetch llms-full.txt (default: false)

Example Response:

{
  "package_name": "fasthtml",
  "ecosystem": "python",
  "llms_txt_content": {
    "project_name": "FastHTML",
    "summary": "FastHTML is a python library which brings together Starlette, Uvicorn, HTMX, and fastcore's FT FastTags",
    "sections": [
      {
        "title": "Docs",
        "links": [
          {
            "title": "FastHTML quick start",
            "url": "https://fastht.ml/docs/tutorials/quickstart_for_web_devs.html.md",
            "description": "Overview of features"
          }
        ]
      }
    ],
    "raw_content": "# FastHTML\n\n> FastHTML is a python library...",
    "is_valid": true,
    "validation_warnings": []
  },
  "source_url": "https://raw.githubusercontent.com/AnswerDotAI/fasthtml/main/llms.txt",
  "source_type": "github_main",
  "repository_url": "https://github.com/AnswerDotAI/fasthtml",
  "status": "success"
}

Tool 5: Create llms.txt (v1.2.0+)

Generate an llms.txt file for your project:

# Example queries:
"Create an llms.txt file for my project called 'My Library'"
"Generate llms.txt documentation for this codebase"
"Create llms.txt with only documentation and examples sections"

Tool Name: create_llms_txt

Parameters:

project_name (string): Name of your project
description (string): Brief project description
scan_directory (string, optional): Directory to scan (default: ".")
sections (list, optional): Specific sections to include (e.g., ["documentation", "examples"])

Available Sections: documentation, examples, api, guides, configuration

Example Response:

{
  "content": "# My Project\n\n> A comprehensive Python library\n\n## Documentation\n\n- [README](README.md): Project overview and getting started\n- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing\n\n## Examples\n\n- [Basic Example](examples/basic.py): Example code\n",
  "discovered_files": {
    "documentation": ["README.md", "CONTRIBUTING.md"],
    "examples": ["examples/basic.py"]
  },
  "suggested_path": "./llms.txt",
  "status": "success"
}

🧪 Testing

Run the test suite:

# Run all tests
uv run pytest

# Run with coverage
uv run pytest --cov=src/mcp_package_hero --cov-report=html

# Run with coverage summary
uv run pytest --cov=src/mcp_package_hero --cov-report=term-missing

# Run specific test file
uv run pytest tests/test_registries/test_pypi.py

Test Results

✅ 68/68 tests passing
✅ Comprehensive coverage for version checking, rating, and llms.txt features
✅ All four ecosystems validated with live API calls

🏗️ Development

Project Structure

mcp-package-hero/
├── src/mcp_package_hero/
│   ├── __init__.py
│   ├── server.py              # Main FastMCP server
│   ├── models.py              # Pydantic models
│   ├── github_client.py       # GitHub API client
│   ├── rating_calculator.py   # Rating algorithms
│   ├── registries/            # Version checking
│   │   ├── base.py
│   │   ├── pypi.py
│   │   ├── npm.py
│   │   └── pubdev.py
│   └── raters/                # Quality rating
│       ├── python_rater.py
│       ├── javascript_rater.py
│       └── dart_rater.py
├── tests/
├── README.md
└── pyproject.toml

Code Quality

# Format code
uv run ruff format .

# Lint code
uv run ruff check .

# Auto-fix safe linting issues
uv run ruff check --fix .

# Type check
uv run mypy src/

Quality Standards

✅ Type Safety: Full mypy compliance with Pydantic plugin
✅ Code Style: Ruff linting and formatting
✅ Modern Python: Python 3.10+ type hints (PEP 604)
✅ Timezone-Aware: All timestamps use UTC timezone
✅ Pydantic V2: Using latest ConfigDict patterns

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

📝 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Built with FastMCP by Prefect
Inspired by mcp-package-version by Sam McLeod
Part of the Model Context Protocol ecosystem

📞 Support

Issues: GitHub Issues
Discussions: GitHub Discussions

🗺️ Roadmap

v1.2.0 ✅ (Current)

llms.txt support - fetch documentation from packages
llms.txt generation - create documentation for projects
Multi-source fetching (GitHub, homepages)
Documentation validation and parsing

v1.1.0 ✅

Package quality rating system
Multi-dimensional scoring (maintenance, popularity, quality)
GitHub integration for repository metrics
Integration with ecosystem-native scores (pub.dev, npms.io)

v1.3.0 ✅

Rust ecosystem support (crates.io)
Full integration with existing tools (version checking, quality rating, llms.txt)
Comprehensive test coverage for Rust packages

v1.4.0 (Planned)

Additional ecosystems (Go, Swift)
Cache layer for improved performance
Support for specific version queries

v2.0 (Future)

Dependency tree analysis
Version compatibility checking
Security vulnerability detection

Made with ☕️ by moinsen-dev

Available Tools

5 tools

create_llms_txtB

Generate an llms.txt file for your project.

Creates a standardized llms.txt file by scanning your project directory for documentation files and generating structured markdown.

ParametersJSON Schema

Name	Required	Description	Default
`sections`	No	Specific sections to include (optional, e.g., ["documentation", "examples", "api"]) Available sections: documentation, examples, api, guides, configuration
`description`	Yes	Brief project description (will appear in blockquote)
`project_name`	Yes	Name of your project
`scan_directory`	No	Directory to scan for documentation (default: current directory)	.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 only mentions scanning and generating, but does not disclose important behavioral traits like whether it overwrites an existing file, file permissions needed, or error conditions.

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 concise with two sentences, front-loading the core purpose. However, it could be slightly more structured to separate usage from behavior.

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 tool's low complexity and the presence of an output schema, the description covers the basic functionality but omits details like file location or overwrite behavior, leaving some gaps.

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% and the description does not add extra parameter context. Baseline 3 applies as the schema adequately describes the parameters.

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 generates an llms.txt file by scanning the project directory, with a specific verb and resource. It is easily distinguishable from siblings like get_llms_txt or rate_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 on when to use this tool vs. alternatives (e.g., get_llms_txt). It does not provide context such as prerequisites or when not to use it.

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

get_latest_versionA

Get the latest stable version of a package.

ParametersJSON Schema

Name	Required	Description	Default
`ecosystem`	Yes	The package ecosystem - one of: "python", "javascript", "dart", or "rust"
`package_name`	Yes	The name of the package (e.g., "requests", "react", "http", "serde")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as error handling (e.g., package not found), authentication needs, or rate limits. The simple read operation is implied but not elaborated.

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?

A single clear sentence with no unnecessary words. Efficiently communicates the tool's primary function.

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 tool's simplicity (2 parameters, no nested objects, output schema present), the description is adequate. It covers the core purpose but could mention the return type (version string) for completeness, though output schema likely covers that.

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% with both parameters described meaningfully. The description adds no extra meaning beyond the schema, meeting the baseline for high 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 states the action (get) and resource (latest stable version of a package). It distinguishes from siblings like get_latest_versions_batch (batch) and rate_package (rating). Verb+resource combination is specific and unambiguous.

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 use for stable versions but lacks explicit guidance on when to use this tool vs alternatives like get_latest_versions_batch. No exclusions or prerequisites are mentioned.

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

get_latest_versions_batchB

Get latest versions for multiple packages at once.

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of dictionaries, each with 'package_name' and 'ecosystem' keys
`max_packages`	No	Maximum number of packages to check (default: 10, hard limit)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It implies a read operation but does not disclose idempotency, rate limits, failure modes, or any side effects. The lack of behavioral detail makes it difficult to predict 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.

Conciseness3/5

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

The single-sentence description is concise but too brief. It lacks structure and fails to convey important context such as parameter constraints or output, making it under-specified.

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?

Despite having an output schema and two parameters, the description omits return value details, hard limits on max_packages, and any examples. It is incomplete for a tool with non-trivial input structure.

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% with descriptions for both parameters. The description adds no additional meaning beyond the schema, meeting the baseline of 3 but failing to enrich understanding.

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 retrieves latest versions for multiple packages simultaneously, using the verb 'Get' and specifying the resource 'latest versions' and scope 'for multiple packages at once'. It distinguishes from the sibling get_latest_version which handles single packages.

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 batch versus single version retrieval (get_latest_version). No mention of prerequisites, alternatives, or when not to use this tool.

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

get_llms_txtB

Get llms.txt documentation file for a package.

llms.txt is an emerging standard for providing LLM-friendly documentation. This tool fetches llms.txt files from package repositories, homepages, or documentation sites.

ParametersJSON Schema

Name	Required	Description
`ecosystem`	Yes	The package ecosystem - one of: "python", "javascript", "dart", or "rust"
`include_full`	No	Whether to also fetch llms-full.txt (optional, default: False)
`package_name`	Yes	The name of the package (e.g., "requests", "react", "http", "serde")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, description carries full burden but only states it fetches from multiple sources. Does not disclose behavior on missing files, error handling, or source priority. Incomplete for a fetch tool.

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?

Three sentences, front-loaded with core purpose. Could be slightly more efficient by merging explanation of llms.txt into the first sentence, but overall no wasted words.

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?

Output schema exists, so return value explanation is not needed. However, for a documentation-fetch tool, it lacks details on success/failure conditions and multi-source behavior, which is a gap.

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 baseline is 3. Description adds minimal extra meaning beyond schema (e.g., does not clarify how include_full affects behavior or ecosystem differences).

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?

Description clearly states the tool fetches llms.txt documentation for a package and explains what llms.txt is. It distinguishes from sibling tools like create_llms_txt (which writes) and other get tools (which fetch version info).

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 (e.g., when to prefer get_latest_version or rate_package). Lacks context for appropriate usage scenarios or prerequisites.

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

rate_packageA

Get a comprehensive quality rating for a package.

This tool analyzes multiple dimensions of package quality including:

Maintenance health (release frequency, issue resolution, PR activity)
Popularity and adoption (downloads, stars, dependents)
Quality metrics (documentation, license, tests)

ParametersJSON Schema

Name	Required	Description	Default
`ecosystem`	Yes	The package ecosystem - one of: "python", "javascript", "dart", or "rust"
`package_name`	Yes	The name of the package (e.g., "requests", "react", "http", "serde")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. 'Get' implies a safe read operation, but no explicit mention of side effects, permissions, or rate limits. Adequate but not explicit.

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?

Description is three paragraphs, front-loaded with main purpose. Each sentence adds value, though could be slightly more concise. No wasted 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?

Given the complexity of rating multiple dimensions, the description outlines key areas. Output schema exists, so return values need not be covered. Complete enough for an AI agent.

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%, so schema already documents both parameters (package_name, ecosystem) with enums and examples. Description adds no parameter details beyond listing dimensions, which doesn't enhance parameter understanding.

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 it gets a comprehensive quality rating for a package, listing specific dimensions. Sibling tools (e.g., create_llms_txt, get_latest_version) are distinct, so no confusion.

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?

Clear context for using this tool to rate a package. No explicit when-not-to-use or alternatives, but the sibling tools are sufficiently different that usage guidance is implied.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: generating llms.txt, getting package version (single/batch), fetching llms.txt, and rating package quality. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (create_llms_txt, get_latest_version, etc.), making them predictable and easy to understand.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose - providing package metadata, llms.txt generation, and quality ratings. Neither too sparse nor excessive.

Completeness4/5

The tool set covers key operations: version lookup (batch and single), documentation (fetch and generate), and quality assessment. A minor gap is the lack of basic package info retrieval (description, homepage), but the core workflows are covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

Hex.pm MCP B
io.github.joshrotenberg
MCP server for hex.pm and hexdocs.pm: search, inspect, compare, and audit Elixir packages
Developer Tools Documentation Access
2422
MCP Verify B
io.sentinelsignal
Trust, freshness, policy, and discovery layer for public MCP servers.
Agent Orchestration Developer Tools Testing & QA Tools
222
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
MCP Registry Server A
ai.com.mcp
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
Developer Tools Search
336,314

Related MCP Servers

versionator-mcp
Developer Tools Search
trianglegrrl
A
license
A
quality
C
maintenance
An MCP server that queries 19 package registries (npm, PyPI, crates.io, etc.) to retrieve the latest version of packages and their metadata.
Updated a year ago (2025-08-20 10:26 UTC)
21
1
MIT
mcpypi
Developer Tools Security Code Analysis
rsp2k
A
license
Not graded
quality
C
maintenance
MCP server for comprehensive PyPI package intelligence, providing tools for dependency analysis, security scanning, health scoring, license compliance, and trend tracking.
Updated a year ago (2025-09-21 17:15 UTC)
MIT
@registry/mcp
Developer Tools Search
broisnischal
A
license
Not graded
quality
D
maintenance
Unified MCP server for searching, analyzing, and managing packages across npm, JSR, Deno, and multiple CDN providers with auto-detection.
Updated 9 months ago (2025-12-16 17:02 UTC)
MIT
Dependency MCP Server
Developer Tools CI/CD & DevOps
niradler
A
license
A
quality
D
maintenance
A Model Context Protocol server for checking package versions and metadata across multiple package managers including npm, PyPI, Maven, NuGet, RubyGems, Crates.io, and Go modules.
Updated 10 months ago (2025-10-29 10:33 UTC)
6
60
1
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/moinsen-dev/mcp-package-hero'

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