Modkeel

What the Modkeel lab saw a mod do

get_mod_runs

Read-onlyIdempotent

Everything the Modkeel lab saw one Minecraft mod do: each Minecraft version where it ran on a server or a client, or crashed, and every mod it ran with or clashed with. Use it for "does this mod work on 1.21.1?", "which versions was it tested on?" or to check a suspect from diagnose_crash. For one specific pair of mods, check_mod_pair gives a direct verdict; for what the mod is and where to get it, get_mod_info. Takes a mod id; from a name, call search_mods first. A mod the lab never ran returns tested: false with empty lists, not an error. Returns every matching row, unpaginated: a few dozen at most per mod.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mc`	No	Minecraft version to narrow the answer to, e.g. 1.21.1, 1.20.1 or 26.2. Omit it to get every version the lab ran; with it, only runs on exactly that version count.
`mod_id`	Yes	Lowercase mod id as the loader knows it (the Modrinth/Fabric/NeoForge id, e.g. sodium, create, entityculling), not the display name. Unsure of the id? Call search_mods first.

Output Schema

TableJSON Schema

Name	Required	Description
`mc`	No
`mod`	Yes
`data`	Yes	Snapshot date and license of the lab data; attribute when quoting.
`runs`	Yes	One per jar the lab ran; env: server, client or crashes.
`pairs`	Yes	Mods it shared a run with; env: server, client or clash.
`tested`	Yes	False: the lab never ran this mod.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedOutput schema / properties / runs / items / properties / how_to_get / description

Previous value: -"For a ported build: the jar is not hosted; the command that builds it. Relay it."New value: +"For a ported build: the jar is not hosted; the command that builds it, and whether the lab ran it on a client. Relay it."

Changed2 schema fields changedOct 13, 2026

addedOutput schema / properties / runs / items / properties / how_to_get

Added value: +{
+  "description": "For a ported build: the jar is not hosted; the command that builds it. Relay it.",
+  "type": "string"
+}

changedOutput schema / properties / runs / items / properties / repo / description

Previous value: -"For a ported build: the GitHub repo (owner/name) the lab built it from; find_mod_download says how a player gets it."New value: +"For a ported build: the GitHub repo (owner/name) the lab built it from."

Changed5 schema fields changedOct 13, 2026
- addedOutput schema / properties / runs / items / properties / branch
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / runs / items / properties / file
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / runs / items / properties / loader
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / runs / items / properties / repo
```
Added value: +{
+  "description": "For a ported build: the GitHub repo (owner/name) the lab built it from; find_mod_download says how a player gets it.",
+  "type": "string"
+}
```
- addedOutput schema / properties / runs / items / properties / version
```
Added value: +{
+  "type": "string"
+}
```
AddedOct 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Modkeel 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.

Resources

Need Help?