Skip to main content
Glama
Sign In

iDos Games

by com.idosgames
OverviewDiscussionsAdmin

Preview Jev tuning

tuning_preview

Ask the platform's decision model to tune the Title: with request (the publisher's words, e.g. "darker and calmer, more generous rewards") it picks variants only for the knobs the request is about; without request and without picks it tunes every unpinned knob. That costs one decision-model call (a fraction of an AI credit, no limits). With only picks ({knob_id: option_id | 0..1 level | true/false}) it is free. Saves NOTHING: returns the plan (picks and each config section before/after). Apply it with tuning_apply, passing the returned picks.

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": {
      "title_id": "<title_id>"
    },
    "name": "tuning_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
knobsNoOptional: limit to these knob ids.
picksNoExplicit choices that override the decision model: {knob_id: option_id | number 0..1 | boolean}.
requestNoWhat to change, in the publisher's own words. Up to 2000 characters.
title_idYesTitleID (the -DEV copy or the live one).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Well beyond the annotations, it discloses the cost model (one decision-model call worth a fraction of an AI credit, no limits; free when only `picks` is supplied), that nothing is persisted, and that the returned plan must be applied separately. The only friction is that 'Saves NOTHING' reads as read-only while readOnlyHint=false is set, leaving an agent to reconcile whether the credit-consuming model call counts as a write.

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?

Dense but front-loaded, with cost, no-persistence, return shape and next step each stated once and no filler. The opening clause 'tune the Title:' is slightly clipped and reads awkwardly, and the parenthetical example is long, but nothing is wasted.

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 4-parameter tool with no output schema, the description covers what the return value contains (picks plus each config section before/after), its cost, that it persists nothing, and the exact hand-off to `tuning_apply`. An agent has everything needed to call it and act on the result.

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

Parameters4/5

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

Schema coverage is 100%, so 3 is the baseline, but the description adds real meaning: `request` is the publisher's own words and restricts tuning scope to the knobs it mentions, and `picks` is a `{knob_id: option_id | 0..1 level | true/false}` override of the decision model. It also clarifies the unpinned-knob default that the `knobs` parameter interacts with.

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 specific verb and resource: it asks the platform's decision model to produce a tuning plan for a Title's knobs. It also separates itself from the nearby siblings by naming `tuning_apply` as the way to persist the result and by scoping behavior to knobs vs. pins.

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?

The three modes are spelled out explicitly: with `request` it tunes only the knobs the request is about; with neither `request` nor `picks` it tunes every unpinned knob; with only `picks` it is free. It also tells the agent the required follow-up (`tuning_apply` with the returned picks), so the when-and-how is unambiguous.

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

All iDos Games toolsInspect
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