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

Annotations indicate readOnly=false but description adds critical context: the project is created as a DRAFT, nothing public until submission or requested_status set. This is essential behavioral disclosure beyond the schema, though it could detail whether creation is reversible or requires auth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with purpose and key behavior, no fluff. Efficient use of words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (15 params, 4 enums) and no output schema, the description gives enough context for safe use: draft creation, explicit user request, next steps. Could note more about potential errors, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 15 parameters with descriptions, but the tool description adds the key semantic of the 'requested_status' field (stays draft until review) and clarifies the draft workflow. This supplements the schema without redundancy.

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

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

Description clearly states it creates a new Modrinth project, explicitly notes it's a draft, and contrasts with sibling tool modrinth_create_version ('After it exists, publish jars with...'). This distinguishes it from related tools effectively.

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

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

Provides explicit guidance: 'only call it when the user explicitly asks to create a new project' and explains draft status process. Names the alternative for publishing versions, offering clear when/why.

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

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

Annotations indicate readOnlyHint=false, so it's a write operation. The description adds context beyond annotations by emphasizing that it 'publishes public content' and requires explicit user consent, plus the existence prerequisite. It doesn't contradict annotations and provides extra safety-relevant context, though it could note that published content becomes publicly visible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the main action, followed by safety guidance and a prerequisite. No redundant details or fluff. Every sentence adds value: the first states the core action, the second sets usage boundaries, the third notes a prerequisite.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 10 parameters, no output schema, and annotations that cover safety hints, the description provides a high-level overview and important context (explicit user consent, existing project). It doesn't explain return values (no output schema required), and all parameters are documented in the schema. The description is sufficient for an agent to understand when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 10 parameters with descriptions and examples (e.g., dependencies example). The description adds minimal extra meaning by referencing 'uploading jar files' (file_paths) and 'existing project' (project_id), but it doesn't compensate beyond the schema. Baseline 3 is appropriate given high coverage.

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

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

The description clearly states the action: 'Publish a NEW version to an existing Modrinth project by uploading one or more built jar files.' It uses a specific verb ('publish') and resource ('version to existing project'), distinguishing it from siblings like modrinth_modify_version (modify) and modrinth_create_project (create project). It also scopes it to existing projects, which is clear.

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

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

The description provides explicit usage conditions: 'only call it when the user has explicitly asked to publish' and 'The project must already exist on Modrinth.' This gives clear when-to-use guidance and a prerequisite, though it does not explicitly name alternative tools for other operations (e.g., modify). It implies when not to use it but lacks direct sibling comparison.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the specific metadata fields returned, which is useful. However, it doesn't disclose any additional behavioral traits like rate limits, authentication requirements, or error behavior (e.g., what happens if the slug/id doesn't exist). With annotations covering the safety profile, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded with the core purpose. It lists the metadata fields in parentheses, which is efficient. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and no output schema, the description is fairly complete. It states what the tool does and what metadata is returned. The only gap is that it doesn't mention error handling or edge cases (e.g., invalid slug), but given the simplicity and the annotations, this is acceptable. A 4 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the only parameter 'id_or_slug' is described as 'Project slug (e.g. 'no-anvil-limit') or id.' The description adds the example slug and clarifies that it can be either a slug or an id, which is helpful. However, it doesn't add much beyond the schema, so baseline 3 is correct.

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

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

The description clearly states the tool's purpose: 'Get a Modrinth project's metadata by slug or id' and lists the specific metadata fields returned (title, type, loaders, game_versions, published version ids, status). This is a specific verb+resource combination that distinguishes it from siblings like modrinth_search_projects (search) and modrinth_list_project_versions (list versions).

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

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

The description implies usage: use this when you need project metadata by slug or id. It doesn't explicitly state when not to use it or mention alternatives, but the sibling names (search, list versions) provide context. The description could be improved by noting that this is for fetching a single project's metadata, not for searching or listing versions.

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

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

Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds behavioral context by explicitly listing the fields in the response, which is valuable given there is no output schema. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that directly states the action and the returned data, with no wasted words. It front-loads the purpose and keeps the detail relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, read-only, no output schema), the description sufficiently covers the return fields, which helps the agent understand what to expect. It omits potential details like pagination or ordering, but these are not critical for a basic listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter id_or_slug is described in the schema ('Project slug or id.'), and the description repeats that without adding further detail. Since schema coverage is 100%, the description adds no extra semantic meaning, so baseline 3 is appropriate.

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

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

The description specifies the exact action ('List a project's published versions') and enumerates the returned fields (version_number, id, type, loaders, game_versions, download url), clearly distinguishing it from siblings like modrinth_get_project (project metadata) and modrinth_search_projects.

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

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

The tool's purpose is self-evident from its name and description—use it to list versions of a known project. It doesn't explicitly state when not to use it (e.g., for modifications use modrinth_modify_version), but the context of sibling tools provides enough clarity.

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

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

Annotations already indicate this is a non-read-only but non-destructive operation. The description adds useful context that the target must be an existing published version and that files are not uploaded. However, it does not clarify partial-update semantics: when omitting optional fields, those fields remain unchanged, are reset, or some other behavior. This gap could lead the agent to invoke the tool incorrectly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the essential action and ends with an important boundary. Every element earns its place and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is enough to know what the tool does and where it applies, but it is still a mutation tool with 7 parameters and no output or side-effect details. It doesn't mention partial update semantics, what happens when omitted fields are used, or return value expectations, which matters because there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has very low individual property description coverage (14%), but the description lists all editable metadata fields. This provides grouping context, yet it does not explain meanings or constraints beyond the few schema types. The description partially compensates for the schema gap, but doesn't fully describe values like 'loaders' or 'game_versions' beyond their names.

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

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

The description uses a specific verb ('Edit'), identifies the exact resource ('metadata of an EXISTING published version'), and enumerates the fields affected. It also explicitly distinguishes itself from file-upload operations, making the tool's function unmistakable and differentiating it from siblings like modrinth_create_version.

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

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

The description clearly implies this is for modifying existing versions rather than creating or uploading, and the phrase 'Does not upload files' provides a useful exclusion. It does not explicitly name alternatives, but the target use case is evident from the wording and sibling tool names.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful context beyond annotations: it constrains the scope to public projects, promises a compact hit list, and enumerates returned fields (slug, title, project_type, downloads, description). This is useful given no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the verb and resource first, then summarizes the return shape. Every word contributes value, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with good annotations and full schema coverage, the description is mostly complete: it identifies scope, result compactness, and fields. It doesn't mention default limits or facet behavior in detail, but those are already addressed by parameter descriptions, so the gap is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter (query, limit, facets) has a meaningful description. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

Description uses a specific verb ('Search') and clearly identifies the resource ('public Modrinth projects'), which distinguishes it from sibling tools like get_project or list_project_versions. It also states the result shape, making the tool's function immediately clear.

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

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

The description implies when to use the tool by naming 'Search,' but it does not explicitly contrast it with alternatives or state when not to use it. For example, it doesn't mention that get_project would be preferable for retrieving a known project's full details.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which covers the safety profile. The description adds that it verifies the token and returns auth details, which is a modest extension beyond annotations. It doesn't mention potential side effects (there are none) or rate limits, but for a verification call, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, both essential. The first sentence states the action and return values, the second provides usage guidance. Zero waste, front-loaded purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description provides the necessary information: what it does, what it returns, and when to use it. Annotations cover safety. It lacks details like error cases or rate limits, but for a simple auth check, the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, and schema coverage is effectively complete (empty schema). The description adds meaning by explaining the output (username, id, email, role), which is valuable for the agent even though it's not required for parameter semantics. With no parameters, a baseline of 4 is appropriate since the description compensates for the lack of parameter documentation.

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

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

The description uses a specific verb ('Verify') and resource ('configured Modrinth token'), clearly stating it returns the authenticated user's details (username, id, email, role). This is unambiguous and distinct from sibling tools, which focus on projects or versions.

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

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

The description explicitly says 'Use this first to confirm auth works', providing clear context for when to invoke this tool. However, it doesn't explicitly mention alternatives or when not to use it, though the purpose is so specific that the usage is clear.

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