Skip to main content
Glama
devqxi

Pub.dev MCP Server

by devqxi

get_package_versions

Retrieve available versions and release dates for Dart/Flutter packages from pub.dev to manage dependencies and track updates.

Instructions

Get all available versions of a package with their release dates

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packageNameYesName of the package to get versions for
limitNoMaximum number of versions to return (default: 10)

Implementation Reference

  • The handler function that implements the core logic for the 'get_package_versions' tool: fetches package versions from pub.dev API with caching, limits to the specified number, and formats as JSON response.
    async getPackageVersions(packageName, limit = 10) {
        const url = `https://pub.dev/api/packages/${packageName}/versions`;
        const data = await this.fetchWithCache(url, `versions-${packageName}`);
        const versions = data.versions
            .slice(0, limit)
            .map((v) => ({
            version: v.version,
            publishedAt: v.published,
            description: v.pubspec?.description
        }));
        return {
            content: [
                {
                    type: "text",
                    text: JSON.stringify({
                        packageName,
                        totalVersions: data.versions.length,
                        versions
                    }, null, 2)
                }
            ]
        };
    }
  • Input schema definition for the 'get_package_versions' tool, specifying packageName as required and limit as optional.
    inputSchema: {
        type: "object",
        properties: {
            packageName: {
                type: "string",
                description: "Name of the package to get versions for"
            },
            limit: {
                type: "number",
                description: "Maximum number of versions to return (default: 10)"
            }
        },
        required: ["packageName"]
  • Tool registration in the list of available tools, including name, description, and input schema.
    {
        name: "get_package_versions",
        description: "Get all available versions of a package with their release dates",
        inputSchema: {
            type: "object",
            properties: {
                packageName: {
                    type: "string",
                    description: "Name of the package to get versions for"
                },
                limit: {
                    type: "number",
                    description: "Maximum number of versions to return (default: 10)"
                }
            },
            required: ["packageName"]
        }
    },
  • Switch case that registers and routes incoming tool calls for 'get_package_versions' to the handler method.
    case "get_package_versions":
        return await this.getPackageVersions(args.packageName, args.limit);
  • TypeScript version of the handler function implementing the 'get_package_versions' tool logic with type annotations.
    private async getPackageVersions(packageName: string, limit: number = 10) {
      const url = `https://pub.dev/api/packages/${packageName}/versions`;
      const data = await this.fetchWithCache<any>(url, `versions-${packageName}`);
      
      const versions: PackageVersion[] = data.versions
        .slice(0, limit)
        .map((v: any) => ({
          version: v.version,
          publishedAt: v.published,
          description: v.pubspec?.description
        }));
    
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify({
              packageName,
              totalVersions: data.versions.length,
              versions
            }, null, 2)
          }
        ]
      };
    }
Behavior2/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. While it mentions that versions come 'with their release dates', it doesn't describe important behavioral aspects like whether this is a read-only operation, whether it requires authentication, what format the versions are returned in, whether there's pagination, or any rate limits. For a tool with zero annotation coverage, this represents significant gaps in behavioral transparency.

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, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for the tool's purpose and front-loads the essential information. Every word earns its place in conveying what the tool does.

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?

Given that there are no annotations and no output schema, the description is insufficiently complete. While it states what the tool retrieves, it doesn't describe the return format, what happens when a package doesn't exist, whether there are authentication requirements, or how the versions are ordered. For a tool with zero annotation coverage and no output schema, the description should provide more contextual information about the operation's behavior and results.

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 both parameters ('packageName' and 'limit') clearly documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions. According to the scoring guidelines, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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 tool's purpose with a specific verb ('Get') and resource ('all available versions of a package'), including the additional detail of 'with their release dates'. It distinguishes from siblings like 'get_package_info' by focusing specifically on versions rather than general package information. However, it doesn't explicitly differentiate from 'check_package_updates' or 'compare_package_versions', which prevents a perfect score.

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 no guidance on when to use this tool versus alternatives. With sibling tools like 'check_package_updates', 'compare_package_versions', and 'get_package_info' available, there's no indication of when this specific version-retrieval tool is appropriate versus those other options. The description simply states what the tool does without contextual usage information.

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/devqxi/pubdev-mcp-server'

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