warframe-builds-mcp

Overview Schema Source Related Servers Discussions Admin

build_variations

Read-onlyIdempotent

Generate multiple Warframe or weapon builds that compare trade-offs across ability groups or stat tiers at 100%, 75%, and 50% gain for recommended and max build requests.

Instructions

Several builds for the same item, showing the trade-offs. For a recommended build on a Warframe, gives a build for each group of abilities that scale the same way, saying which abilities it prioritizes. With stat, such as a max duration build, gives max, 75% and 50% of the possible gain, with what each wins back. Also takes weapon. Use this rather than one suggestion when the player asks for a recommended or max build.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "build_variations"
  }
}

Input Schema

Name	Required	Description
`aura`	No
`mods`	No	Mods every variation must use, such as an augment.
`stat`	No	Warframes: the stat to push: strength, duration, range, efficiency, health, shields, armor, energy or effective_health.
`forma`	No	Extra Forma allowed. Default 3.
`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
`ability`	No	Warframes: only build around this ability.
`arcanes`	No
`exclude`	No	Mods not to use.
`subsume`	No	An ability infused through the Helminth: {ability, replaces}, such as {ability: "Roar", replaces: "Molt"}. See explore_loadout.
`warframe`	No
`conditionals`	No
`archon_shards`	No
`status_types_on_target`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.12.0Nov 3, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real behavioral value by describing the shape of the result (one build per ability-scaling group with prioritized abilities; max, 75% and 50% variants with trade-off notes). It also includes a useful caution about not guessing whether a level already includes Steel Path's +100, which is genuine behavioral guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the prose is loose: 'Also takes weapon.' is a dangling fragment, and the Warframe/stat clauses run together without clear structure. Tightening into a short bulleted breakdown of the two variation modes would remove ambiguity without losing content.

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 15-parameter, nested-object tool with no output schema, the description does well on return shape (variation tiers and grouping) but leaves the majority of inputs unaddressed and gives no guidance on defaults or how the many optional parameters interact. Adequate to call, not adequate to call well.

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

Parameters2/5

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

Schema description coverage is only 47% across 15 parameters, and the description compensates for very little of it — it explains what 'stat' produces and mentions 'weapon' in a fragment, but says nothing about aura, arcanes, archon_shards, attack, conditionals, status_types_on_target, exclude, mods or forma. The example 'max duration build' adds meaning to stat, but most undocumented parameters remain unexplained in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific statement of what is returned: several builds for the same item showing trade-offs, with distinct behavior for Warframes (per ability-scaling group) and stat-pushes (max/75%/50% tiers). It is clearly a 'variations' generator rather than a single-build tool, though it never names the sibling it is contrasted with (e.g. suggest_warframe_build or warframe_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?

It gives an explicit routing rule: 'Use this rather than one suggestion when the player asks for a recommended or max build,' which tells the agent when this tool wins over a single-suggestion alternative. The alternative is referenced only as 'one suggestion' rather than by name, and no when-not-to-use cases are given, so it stops short of a 5.

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