warframe-builds-mcp

Overview Schema Source Related Servers Discussions Admin

cost_of_leaving_out

Read-onlyIdempotent

Calculate what a Warframe build loses by omitting a mod or arcane, compare with-and-without results, and get a replacement and verdict for your chosen build or goal.

Instructions

What a build loses without a mod or arcane, such as one that's too expensive or not owned. Compares the best build, or the player's own through build_mods, with and without it, gives the replacement and a verdict. Pass goal for what the build is for, and too_expensive so the replacement isn't a dearer version. Be direct about a big loss, and offer a different build rather than patching this one.

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": {
      "leave_out": "<leave_out>"
    },
    "name": "cost_of_leaving_out"
  }
}

Input Schema

Name	Required	Description
`goal`	No	As in the suggest tools.
`mods`	No
`forma`	No
`attack`	No
`target`	No	The enemy, as a name or faction such as "Heavy Gunner" or "Grineer", or {enemy, level, steel_path, faction, armor}. An enemy with a level scales its armor, health and shields. steel_path adds 100 levels to that level and multiplies health and shields by 2.5, so if the level you have already includes the 100, ask rather than guess. armor_strip is the percentage of armor removed: the wiki lists Corrosive as 26% for the first stack and 6% more per stack, up to 80% at 10, and Heat as gradually up to 50%. Applies faction damage multipliers, armor reduction and faction mods. See list_enemies.
`weapon`	No
`arcanes`	No
`exclude`	No
`subsume`	No	An ability infused through the Helminth: {ability, replaces}, such as {ability: "Roar", replaces: "Molt"}. See explore_loadout.
`targets`	No
`warframe`	No
`leave_out`	Yes	Mods or arcanes to go without.
`build_mods`	No	The player's own mods, to measure their build rather than the best one.
`conditionals`	No
`too_expensive`	No	The reason is price, so Primed, Umbral, Archon and similar versions of it are left out too.
`status_types_on_target`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.12.0Nov 3, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare this a read-only, idempotent, non-destructive tool, so the safety profile is covered. The description adds useful behavioral context: which two builds are compared, that a replacement and a verdict are produced, and how to present a large loss. It does not describe the shape of the returned comparison or how the verdict is derived.

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?

Four sentences, front-loaded with the core comparison before parameter hints and output guidance, with no filler. Phrasing is slightly oblique ('such as one that's too expensive or not owned') where a plain statement of the input would be crisper.

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

Completeness3/5

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

For a 16-parameter tool with nested objects and no output schema, the description covers the central comparison and a handful of key parameters but leaves most inputs to the schema. Because it does explain the replacement-plus-verdict return, the gap is mainly on the many undocumented build-specification parameters.

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 only 38% across 16 parameters, so the description must compensate more than it does. It clarifies the intent of goal, build_mods and too_expensive (including that too_expensive also excludes Primed/Umbral/Archon variants), but says nothing about mods, forma, attack, weapon, arcanes, exclude, conditionals, subsume or status_types_on_target, and target is only documented inside the schema.

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 quantifies what a build loses when a mod or arcane is omitted, comparing the best build or the player's own with and without it and returning a replacement plus verdict. That is clearly distinct from the sibling build tools (suggest_weapon_build, explore_synergies), which construct rather than cost out a build.

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

Usage Guidelines4/5

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

Gives real routing guidance: pass goal to describe the build's purpose, use build_mods to measure the player's own build rather than the best one, and set too_expensive when the reason for omission is price. It also tells the agent how to frame the answer (be direct about a big loss, offer a different build instead of patching this one), but never names an explicit alternative sibling or a when-not-to-use condition.

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