Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

modrinth_project_versions

Retrieve a project’s public Modrinth version metadata by ID, with optional filters for loader, game version, featured status, and changelog inclusion.

Instructions

List project versions. Returns the native public Modrinth metadata for this resource. See the endpoint reference for exact request and response behavior.

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

Name	Required	Description
`id`	Yes	Native id
`loaders`	No	JSON array of loader names from the loader tag catalog
`featured`	No	Native featured selector; false is distinct from omission
`game_versions`	No	JSON array of game versions from the game_version tag catalog
`include_changelog`	No	Include changelog fields

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full burden, and it discloses almost nothing: no pagination behavior, no ordering of returned versions, no result-size or rate-limit expectations, and no statement of what happens when filters match nothing. "See the endpoint reference for exact request and response behavior" defers the entire behavioral contract rather than stating it.

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?

It is short, but the three sentences include one generic filler line about native metadata and one that outsources behavior to an external reference. The useful content (the list operation) is front-loaded, but the remaining bulk does little work.

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?

For a five-parameter listing tool with no annotations and no output schema, the description should explain what a returned version record contains and how the optional filters combine. Instead it relies on an external endpoint reference, leaving the agent without enough to call the tool confidently or interpret 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?

Schema description coverage is 100%, so every parameter (id, loaders, featured, game_versions, include_changelog) is already documented in the schema, and the description adds no interpretation beyond it. Per the high-coverage baseline, a 3 is appropriate; the description neither clarifies the array-in-string JSON convention nor explains filter interaction.

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 first sentence gives a clear verb and resource ("List project versions"), which is unambiguous about the operation. However, it does nothing to distinguish this from close siblings like modrinth_versions, modrinth_project_version, or modrinth_file_versions, and the second sentence ("Returns the native public Modrinth metadata for this resource") restates generically rather than sharpening scope.

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?

There is no guidance on when to pick this tool over the sibling version-listing tools, nor on prerequisites such as whether the project must be published or whether loaders/game_versions must come from the tag catalogs. The only nod toward context is "See the endpoint reference," which pushes the decision to an external document the agent may not have.

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

Deploy Server