Skip to main content
Glama
Sign In

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

modrinth_files_update_many

Read-only

List every compatible update version for several Modrinth files in one native POST read and return a map from each requested hash to an array of matching version objects, so callers can see all candidates instead of only the newest. Send hashes plus optional loaders and game_versions arrays; an empty array is a valid result for a hash with no match.

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": {
      "hashes": "<hashes>"
    },
    "name": "modrinth_files_update_many"
  }
}

Input Schema

NameRequiredDescriptionDefault
hashesYesRequired JSON array of file hashes (40 hexadecimal SHA-1 or 128 hexadecimal SHA-512 characters). An empty array is valid.
loadersNoOptional loader names applied to every hash. Discover the values with modrinth_tags and type=loader. An explicit empty array stays distinct from omission.
algorithmNoOptional hash algorithm, sha1 or sha512; omit it for native auto-detection from the first hash.
game_versionsNoOptional game versions applied to every hash. Discover the values with modrinth_tags and type=game_version. An explicit empty array stays distinct from omission.

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

A3.7/5.0
Behavior4/5

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

With readOnlyHint=true and openWorldHint=true already supplied, the description still adds value by clarifying this is a 'native POST read' — resolving the common confusion that a POST implies a mutation. It also discloses that 'an empty array is a valid result for a hash with no match', which is meaningful non-obvious behavior. Rate limits and batching limits are not covered.

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, front-loaded with the operation and its payoff, then the input shape. The second sentence largely restates schema-level facts (which parameters to send, empty array allowed), so a small amount of content is redundant rather than load-bearing.

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?

An output schema exists, so the return map need not be fully explained, yet the description still characterizes it as a hash-to-version-array map, which orients the caller. For a 4-parameter batch read with full schema coverage and annotations, the definition covers what an agent needs, with only algorithm and any batch-size limits left unaddressed.

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 baseline is 3. The description reinforces that hashes, loaders and game_versions are arrays sent together and that an empty array is a legitimate value, but it omits the algorithm parameter entirely and adds no format detail beyond the schema.

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?

States a specific verb and resource ('List every compatible update version for several Modrinth files') and makes the batch nature explicit, with the phrase 'instead of only the newest' implicitly contrasting it with a newest-only variant. It does not name the singular sibling (modrinth_files_update), so differentiation is inferred rather than stated.

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?

Usage is implied by 'for several Modrinth files in one native POST read' and by 'so callers can see all candidates instead of only the newest', which hints at when the all-candidates behavior matters. However, there is no explicit when-to-use/when-not guidance and no named alternative to route to.

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