Modkeel

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

Annotations already mark this read-only, idempotent and non-destructive, so the safety profile is covered; the description goes further with the 300-id cap, the exact-version semantics of mc, the fact that crashed mods return the author's current build, and the verdict/coverage caveat (pairs.tested out of pairs.total, no_known_problem is not a guarantee). That is meaningful behavioral context beyond structured fields.

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?

Front-loaded with the core purpose and the sibling routing, then dense supporting detail; nothing is clearly filler. It is packed close to the limit, running several ideas together per sentence, which costs a bit of scanability but not substance.

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?

Covers invocation limits, id sourcing, version scoping, output bucket names, verdict semantics and the coverage caveat, which is everything needed to call and interpret this tool; since an output schema exists, no further return-value documentation is owed.

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 baseline is 3, but the description adds genuine meaning: mod_ids are lowercase loader ids derived from mod names or jar filenames, and unrecognized ids degrade gracefully into untested_mods rather than erroring. The mc parameter's narrowing semantics are also restated usefully, though partly duplicating the schema text.

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?

Names a specific verb+resource (check a whole mod list/modpack against the Modkeel lab) and enumerates the four result buckets: clashed pairs, crashed jars, pairs that ran together, and untested mods. It explicitly distinguishes itself from the sibling check_mod_pair, so an agent can route without opening either schema.

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?

Gives explicit triggers ("will these mods work together?", before updating a pack) and a named alternative with the condition that selects it ("for two mods, check_mod_pair is enough"). It also prescribes a prerequisite workflow: resolve names via search_mods first.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: unknown ids are not an error but yield an 'untested' verdict, mc narrows to exact-version runs, and clash takes precedence if any run clashed. However it does not describe the shape or size of the returned run list, so this is solid supplemental context rather than exhaustive.

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?

Front-loads the outcome definition, then prerequisites, semantics, and precedence rules, closing with the return summary. Sentences are dense but each carries distinct information; no repetition of annotation or schema content.

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?

Covers the outcome vocabulary, the untested/unknown-id edge case, the version-narrowing parameter, ordering insensitivity, and precedence of clash, with an output schema handling return details. Nothing an agent needs to invoke or interpret this correctly appears to be missing.

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 coverage is 100%, so parameter formats are already documented. The description nevertheless adds non-obvious semantics beyond the schema: the two ids are interchangeable ("any order"), ids may come from names via search_mods, and mc restricts to exactly one version. That exceeds the baseline for a fully covered schema.

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 names a specific verb-and-resource pair (compare whether two mods ran together) and enumerates the possible outcomes: worked together, clashed, or never tested. It also names the sibling it is not (get_mod_runs) for the one-mod case, so an agent can route between them without opening schemas.

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?

Gives explicit triggering scenarios ("can I use X with Y?", or two suspects from diagnose_crash) plus an explicit alternative (get_mod_runs for one mod's whole record) and a prerequisite (call search_mods first if unsure of ids). When-to-use, when-not, and alternatives are all present.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial context beyond them: cross-checking against the Modkeel lab, the 10+ player threshold for fix reporting, a NONE confidence fallback, an error on logs containing no crash, a 4 MB cap, and 'read and dropped, never stored.' That is a rich disclosure of behavior, limits, and data handling.

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?

Front-loaded with purpose and trigger, and nearly every clause carries operational information. It is a dense single paragraph that runs long, but the length is justified by the tool's complexity rather than padding.

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?

Even though an output schema exists, the description covers inputs, the text/url choice, size limits, error behavior, privacy, and the shape of the ranking output. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the schema already documents both parameters and the paste-site list. The description still adds real meaning the schema lacks: 'Pass the whole file as text, unedited: trimming it loses the mod list,' which tells the agent why fidelity matters.

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?

States a specific verb and outcome ('Find the mod most likely behind a modded Minecraft crash') and names the supported loaders. It also separates itself from siblings with 'It is the only tool that reads logs,' so an agent can tell it apart from check_mod_list, check_mod_pair, and get_mod_runs without opening a schema.

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?

Gives explicit trigger conditions ('whenever the user shares a crash report or latest.log or says the game will not start') and effectively excludes alternatives by declaring itself the only log-reading tool. The url-vs-text branch is spelled out with the exact paste sites that select the url path.

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 readOnly/idempotent/openWorld, but the description adds substantial behavior beyond them: live Modrinth calls (2-5, nothing cached), failure/retry guidance when Modrinth is down, and the full ranked resolution order (official, port, older_build, build_from_source, other_loader, none) with what each status means and how next_step warns on harmful older builds.

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?

It is front-loaded with the core purpose and the resolution ordering, and every sentence carries routing or behavior information rather than filler. The single dense paragraph is on the long side, but the length is justified by the multi-branch resolution logic it must convey.

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?

With an output schema present, the description needn't enumerate return fields, yet it still explains the status values and next_step semantics the agent will see. For an openWorld, live-calling tool with 3 required params, nothing needed to invoke it correctly is missing.

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 coverage is 100%, so the baseline is 3; the description still adds usable context by restating that mod_id accepts a user-typed name, lab mod id, or Modrinth slug and, crucially, that no search_mods call is needed first. It adds little on mc/loader beyond the enum already documented in the schema.

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 gives a specific verb+resource+scope: it returns the exact file to install for one mod on one Minecraft version and loader, plus the download link. It explicitly differentiates from siblings by naming get_mod_info (what the mod is) and get_mod_runs (whether it ran in the lab), so an agent can route without opening schemas.

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?

It states concrete when-to-use triggers ("where do I get X for 26.2 Fabric?", after diagnose_crash names a mod needing another build, when updating a pack) and names alternatives with their selecting conditions. Nothing is left to inference about when this tool is the right choice versus get_mod_info or get_mod_runs.

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 cover read-only/idempotent/open-world, but the description adds real behavior: no caching, a live Modrinth call per invocation, potential failure when Modrinth is down with a retry hint, resolution by jar SHA-1 then slug, and found:false rather than an error for unknown mods. This is far beyond the annotation set.

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?

One dense paragraph that is front-loaded with purpose, then usage, then resolution/failure semantics; nearly every clause carries information. It is long for a single-parameter tool, and the resolution detail could be tightened, but nothing is filler.

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?

With an output schema present, return-value detail is unnecessary, and the description still covers prerequisites, resolution order, the found:false non-error case, and the live-call failure mode. Nothing needed to invoke it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds meaning: the value may be a lab mod id or a Modrinth slug, is matched by jar hash then slug, and a plain name requires search_mods first. That is more than the schema's format hint.

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?

States a concrete verb and resource (fetch a mod's Modrinth catalog page plus a Modkeel lab record) and enumerates the fields returned, so an agent knows exactly what it gets. It explicitly separates itself from siblings get_mod_runs, check_mod_pair and search_mods.

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?

Gives explicit trigger questions ("what does this mod do?", "is it client-only?", "where do I download it?"), names the alternatives for adjacent needs (get_mod_runs for observed behavior, check_mod_pair for two mods together), and states the prerequisite of calling search_mods when only a name is known.

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds genuinely non-obvious behavior: an untested mod returns tested:false with empty lists rather than erroring, and results are returned unpaginated with a bounded count (a few dozen per mod). These are edge-case and result-shape facts an agent could not infer.

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?

Front-loaded with what the tool returns, then routing alternatives, then the input contract, then the empty-result and pagination caveats. Every sentence carries distinct information; nothing is restated from annotations or schema.

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 two-parameter read tool with an output schema, the description covers everything an agent needs: what the rows mean, how versions are scoped, the name-vs-id prerequisite, and the no-data-vs-error distinction. Return-value documentation is appropriately left to the 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?

Schema description coverage is 100%, so both parameters are fully documented in the schema, including the mc narrowing semantics and the lowercase-id requirement. The description only reiterates that it takes a mod id and to use search_mods for names, adding nothing the schema lacks; baseline 3 applies.

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?

States a concrete verb+resource: everything the lab observed one mod do, broken down into per-version run/crash outcomes plus co-run and clash relationships. It is immediately distinguishable from check_mod_pair (pair verdict), get_mod_info (metadata), and diagnose_crash (suspect analysis), none of which are duplicated.

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?

Gives explicit sample queries ('does this mod work on 1.21.1?', 'which versions was it tested on?'), names the exact sibling to use for a pair verdict, for mod metadata, and for name-to-id resolution, and states the prerequisite (call search_mods first when you only have a name).

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 readOnly, idempotent, non-destructive and closed-world, yet the description still adds real behavior: case/space/punctuation-insensitive matching, ordering (best match first, then most lab data), empty-query listing everything, return contents, and the important no-match semantics (absence of lab data, not a broken mod). That last point is a genuine failure-mode disclosure an agent would otherwise misread.

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?

Dense but front-loaded: the core purpose and the primary routing decision come first, then matching rules, then result shape, then parameter notes. All sentences carry information, though the final parameter recap sentence is somewhat redundant against the schema and could be trimmed.

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 3-param, zero-required search tool with an output schema present, the description covers what an agent needs: purpose, routing, matching behavior, empty/no-match edge cases, and parameter effects. It even explains the return shape, which the output schema makes optional, so completeness is not in question.

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 coverage is 100%, so the baseline is 3, but the description adds interpretation: mc counts only runs on that exact version, limit caps the list, and total reports how many matched regardless of limit. That clarifies the mc filtering semantics and the limit/total relationship beyond the schema text.

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?

States a specific verb and resource: turning a display name or partial id into the exact mod id other lab tools consume, and revealing which mods the lab has data on. It explicitly distinguishes itself from siblings find_mod_download and get_mod_info, so an agent can route without opening any schema.

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?

Gives an explicit when-to-use trigger (only have a name or unsure of the id), an explicit when-to-skip rule (already have the id), and names two alternatives with their selecting conditions: find_mod_download for downloading, get_mod_info for Modrinth slug lookup. Nothing is left to inference.

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