Crawlora MCP

modrinth_search

Read-only

Search Modrinth's public project catalog and return native search rows (project id, slug, title, description, author, project type, categories, loaders, game versions, download and follow counters, gallery icon) plus offset, limit and total_hits. Use this to find a project id or slug for modrinth_project; facets is a JSON array of OR groups joined by AND, for example [[project_type:mod],[categories:optimization]], validated against the modrinth_tags catalogs, and index, offset and limit are the site's own native order and paging controls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`index`	No	Optional native result order: relevance (default), downloads, follows, newest or updated.
`limit`	No	Optional native result limit from 0 to 100; omit it for the native default of 10. An explicit 0 is a real limit, not the default.
`query`	No	Optional free-text search text; omit it to list projects under the facet filter.
`facets`	No	Optional native facet filter as a JSON array of OR groups joined by AND, for example [["project_type:mod"],["categories:optimization"]]. Discover valid field names and catalog values with modrinth_tags.
`offset`	No	Optional zero-based result offset, at least 0; defaults to 0.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so the read-only, public-API nature needs no restating. The description adds real behavior beyond that: results are 'native search rows' plus offset/limit/total_hits, and facet values must come from the modrinth_tags catalogs (implying invalid facets are rejected). It stops short of stating error behavior, rate limits, or what happens when query is omitted alongside facets beyond a brief mention.

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?

Purpose is correctly front-loaded in the first clause, and the facets explanation is efficient. However, it is delivered as one dense run-on paragraph, and the long parenthetical inventory of return fields duplicates information the output schema already provides. The facets JSON example is also repeated verbatim from the schema.

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?

For a parameterless, read-only public search with a full schema, an output schema, and annotations covering safety, the description supplies what the structured fields cannot: when to reach for this tool, how facets compose, and that paging is native. The remaining gap is disambiguation from the search_v3 family, which is the one piece an agent would still have to guess.

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 coverage is 100%, so the schema already documents all five parameters, giving a baseline of 3. The description adds some meaning on top: facets is described as OR groups joined by AND (matching the schema example) and index/offset/limit as the site's own native ordering and paging controls, but no new syntax or edge-case detail beyond what the schema text states. Its main added value, the modrinth_tags validation requirement, is already repeated in the schema's facets description.

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?

Opens with a specific verb and resource ('Search Modrinth's public project catalog') and enumerates exactly what comes back (project id, slug, title, author, categories, loaders, counters, offset/limit/total_hits), which makes the tool's output shape unmistakable. It names modrinth_project and modrinth_tags as related tools, but never distinguishes itself from the three search_v3 siblings, so an agent cannot tell when this search differs from those.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this to find a project id or slug for modrinth_project' gives a concrete purpose-driven use case and a downstream handoff target. It also states that facets values must be validated against the modrinth_tags catalogs, which is actionable prerequisite guidance. It gives no explicit 'don't use this when...' or a comparison against the alternative search tools.

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

All Crawlora MCP tools Inspect

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.