Skip to main content
Glama
Sign In

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

modrinth_project_versions

Read-only

List every Modrinth version of one project and return each version's id, name, version number, release channel, release date, loaders, game versions, featured flag, downloads and file list with hashes and URLs. Filter with the loaders and game_versions JSON arrays validated against the modrinth_tags catalogs, and use featured (false is distinct from omission) and include_changelog for the site's own selectors.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "modrinth_project_versions"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesRequired Modrinth project id or slug.
loadersNoOptional JSON array of loader names. Discover the current values with modrinth_tags and type=loader.
featuredNoOptional native featured selector; false is distinct from omission.
game_versionsNoOptional JSON array of game versions. Discover the current values with modrinth_tags and type=game_version.
include_changelogNoOptional include-changelog selector; omit it for the native default of true.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered, and the description adds the notable nuance that 'featured' false is distinct from omission. It says 'every version' but discloses nothing about result bounds, ordering, or pagination for projects with many releases — a meaningful gap for a listing tool operating against an open-world API.

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?

Two sentences, purpose front-loaded, no filler. The second sentence is a long run-on stacking four filter conditions, which slightly hurts scanability, and the exhaustive return-field enumeration is arguably wasted when an output schema exists.

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?

An output schema exists, so the return-value enumeration in the description is largely redundant rather than compensating for anything. For a read-only listing tool with five well-documented parameters, what's missing is behavioral rather than structural: ordering, result limits, and empty-project behavior.

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 all five parameters, including the featured false-vs-omission nuance and the include_changelog default of true. The description largely restates those same points and adds no format examples or constraints beyond what the schema supplies, making the baseline 3 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 opens with a specific verb and resource: 'List every Modrinth version of one project', and enumerates the returned fields, so the intent is unambiguous. It does not name the sibling that handles the single-version case (modrinth_project_version) or the cross-project case (modrinth_versions), so the agent must infer the boundary from names alone.

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?

It gives real usage context for the filters — loaders and game_versions must be JSON arrays whose values are validated against the modrinth_tags catalogs, which implies a discovery step before calling. However, there is no explicit when-to-use/when-not guidance relative to alternatives, and no statement of what happens with projects that have no versions.

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

All Crawlora MCP toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources