get_ge_infoRead Grand Exchange database metadata, including lastConfigUpdateRuneday. This is not item prices; use get_item_price or lookup_item for those. Takes no arguments. Public Jagex endpoint, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": true,
+ "description": "Raw Jagex JSON. Price fields may be integers or compact strings such as \"80k\".",
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description usefully adds that it is a public Jagex endpoint requiring no auth and that it takes no arguments — context the annotations do not supply. It stops short of describing response shape, but with an output schema present that is not required.
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 short sentences, front-loaded with the resource, then the exclusion, then the invocation constraints. No filler; every sentence carries new information.
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?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers purpose, sibling routing, argument count and auth requirements — everything needed to invoke this metadata endpoint correctly.
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?
Zero parameters, so the baseline is 4. The description confirms 'Takes no arguments', which is consistent with the empty, additionalProperties:false schema and prevents an agent from inventing inputs.
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 ('Read Grand Exchange database metadata') and even names a concrete field ('lastConfigUpdateRuneday'). It explicitly distinguishes itself from the item-price tools, so an agent can tell it apart from get_item_price and lookup_item 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?
Explicit when-not guidance ('This is not item prices') paired with named alternatives ('use get_item_price or lookup_item for those'). Nothing about tool selection 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.
Add one secure layer between your agents and this server.