Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

modrinth_file_update

Resolve a compatible Modrinth update for a file by hash and return native public metadata, using optional loader and game-version filters.

Instructions

Resolve a compatible update for a file. 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": {
      "hash": "<hash>",
      "body": "<body>"
    },
    "name": "modrinth_file_update"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	Native metadata lookup body
`hash`	Yes	Native hash
`algorithm`	No	File-hash algorithm; omitted uses native auto-detection

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it does not say whether this is a read-only metadata resolution or a state-changing update, nor does it mention permissions, side effects, or rate limits. Saying it 'Returns the native public Modrinth metadata' is the only behavioral detail, and it is insufficient for a tool whose name suggests mutation.

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 definition is short and front-loads the purpose, but the final sentence ('See the endpoint reference for exact request and response behavior') is an offloading pointer rather than useful content. Two of three sentences are largely boilerplate.

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 tool with a nested body object, multiple similarly named update siblings, no annotations, and no output schema, the description is materially incomplete. It does not explain what 'compatible update' resolution means, how the body filters versions/loaders, or what happens on invocation.

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 hash, algorithm, and body parameters are already documented in the schema; baseline 3 applies. The description adds no meaning about the nested loaders/game_versions body fields or how the hash/algorithm interact with output resolution.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description has a verb and resource ('Resolve a compatible update for a file') but leaves the outcome ambiguous: it is unclear whether the tool computes/resolves an update or applies one, especially given the overlapping sibling names like modrinth_files_update and modrinth_files_update_individual. It also does not distinguish itself from those siblings.

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 use this tool versus the several similarly named update/resolve siblings, and no prerequisites or exclusions are stated. The only routing advice is a generic pointer to an external endpoint reference.

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

Deploy Server