Crawlora MCP

modrinth_search_v3

Read-only

Search Modrinth's current version-aware project and server catalog with native v3 filters, ordering and paging, returning name, summary, project types and version-aware hits plus page, hits_per_page and total_hits. Offset and limit default to 0 and 10; the source normalizes 0 to 1 and clamps above 100, and page is derived as offset/limit+1. new_filters takes precedence over facets, filters and version, and version is a legacy filter-expression clause, not a bare game version. Discover accepted indexes and filter values with modrinth_search_v3_options.

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_v3"
  }
}

Input Schema

Name	Required	Description
`index`	No	Optional native result order. Discover the accepted values with modrinth_search_v3_options.
`limit`	No	Optional native limit; defaults to 10. The source normalizes 0 to 1 and clamps values above 100.
`query`	No	Optional native search text.
`facets`	No	Optional legacy JSON array of string arrays using v3 field names, for example [["project_types:plugin"]]. Numeric-looking version literals need the native quoting form.
`offset`	No	Optional native nonnegative offset; defaults to 0. Page is derived as offset/limit+1, so page one needs offset 100 with limit 100.
`filters`	No	Optional legacy filter-expression clause, combined with version using AND when new_filters is absent.
`version`	No	Optional legacy secondary filter-expression clause. This is not a bare game-version value; it is combined with filters using AND when new_filters is absent.
`new_filters`	No	Optional current native filter expression, forwarded unchanged. When supplied it takes precedence over facets, filters and version.

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

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external reach are covered. The description adds real behavioral context beyond that: it discloses the returned fields (name, summary, project types, version-aware hits, page, hits_per_page, total_hits) and the paging mechanics, including that limit/offset normalize 0 to 1, clamp above 100, and derive page as offset/limit+1.

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?

Front-loaded correctly, with the core purpose stated first and parameter caveats afterward. However, it is a single dense run-on paragraph with noticeable redundancy against the schema, so several clauses do not earn their place.

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 an 8-parameter, zero-required search tool with annotations and an output schema, the definition supplies pagination semantics, return-field hints, filter precedence, and a discovery pointer to the options sibling. The remaining gap is explicit differentiation from the other search siblings, which is not addressed.

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?

With 100% schema description coverage, the baseline is 3, and on inspection most of the description's parameter guidance is restated from the schema: offset/limit defaults and clamping, page derivation, new_filters precedence, and version being a filter-expression clause all appear in the property descriptions. It adds little genuinely new syntax or format detail beyond the schema other than reinforcing which parameters are legacy versus current.

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: search Modrinth's version-aware project and server catalog with native v3 filters, ordering and paging. The 'v3' marker plus the pointer to modrinth_search_v3_options helps separate it from the legacy modrinth_search sibling, though the description never explicitly contrasts the two.

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?

Guidance is concentrated on internal parameter interaction (new_filters takes precedence over facets, filters and version; version is a legacy clause, not a bare game version) rather than on when to choose this tool over modrinth_search or modrinth_search_v3_body. It does correctly route the agent to modrinth_search_v3_options for discovering accepted indexes and filter values, which is useful implied usage guidance.

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.