Skip to main content
Glama

modrinth_collection

Read-only

Read one public Modrinth collection by base62 ID and return its id, name, nullable description/icon/color fields, created and updated timestamps, visibility status (listed, unlisted or unknown) and the complete ordered project-ID array. Owner account identifiers and unreviewed metadata are excluded, and project details are not fetched or inferred. Invalid identifiers are rejected and unavailable or inaccessible collections return not found.

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

Input Schema

NameRequiredDescriptionDefault
idYesRequired base62 collection ID from a public /collection/{id} URL. Returns the collection metadata and its complete ordered project-ID list; private or rejected collections are not exposed.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description goes further by disclosing excluded data (owner account identifiers, unreviewed metadata) and that project details are not fetched or inferred. It also specifies failure behavior: invalid identifiers are rejected and unavailable/inaccessible collections return not found.

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?

Three sentences, front-loaded with the scope (one public collection, base62 ID), then return shape, then exclusion and error rules. Dense but each clause carries information; minor redundancy exists with the schema's ID description.

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?

A read-only one-parameter lookup with an output schema, so return-value documentation is not strictly needed, yet the description covers return fields, exclusions, and error cases. An agent has everything needed to call it correctly; only a pointer to ID discovery is missing.

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% and the schema itself already documents the base62 ID as coming from a public /collection/{id} URL. The description restates the base62 format and confirms the ID yields the ordered project-ID list, but adds no new syntax beyond what the schema already supplies, so the baseline 3 applies.

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: 'Read one public Modrinth collection by base62 ID', which makes the singular-vs-list distinction against the modrinth_collections sibling apparent. It does not name that sibling or any other alternative, so differentiation is inferential rather than explicit.

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 'public collection by base62 ID' and by the note that private or rejected collections are not exposed, which tells the agent the access precondition. There is no explicit when-to-use/when-not framing or pointer to the list/search sibling for discovering an ID before calling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.