Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@warframe-builds-mcp what's the best Soma Prime build against Grineer?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets an AI assistant calculate and suggest Warframe builds. Ask things like "what's the best Soma Prime build against Grineer?" or "get Saryn to 175% efficiency with as much strength as possible", and it answers with real game data and shows its numbers.
It needs Node 18 or newer and has no other dependencies. It runs on your computer and makes no network calls.
Claude Code
claude mcp add --scope user warframe-builds -- npx -y github:pregamer189/warframe-builds-mcpClaude Desktop, Cursor and other MCP clients. Add this to the client's MCP config:
{
"mcpServers": {
"warframe-builds": {
"command": "npx",
"args": ["-y", "github:pregamer189/warframe-builds-mcp"]
}
}
}From a local copy
git clone https://github.com/pregamer189/warframe-builds-mcp.gitThen point your client at node /path/to/warframe-builds-mcp/server.mjs.
Related MCP server: warframe-mcp
Tool | What it does |
| Picks the mods that do the most damage to the enemy you name, within capacity, polarities and conflicts. It can also plan Forma |
| Picks mods towards a goal such as strength or effective health, or minimums such as 175% efficiency |
| Works out a weapon, Zaw or Kitgun build: damage by type, crit, status, damage over time, DPS and capacity. Melee adds range, heavy attacks and per-combo stance DPS |
| Works out a Warframe, companion, Archwing or Necramech build: stats, ability stats, effective health and capacity |
| Find weapons, frames, and Zaw and Kitgun parts |
| Find mods and arcanes by name or effect |
| Shows the version, the data's import date, coverage and limits |
Names forgive case, punctuation and typos. Build results warn about mod conflicts, the wrong weapon class, PvP-only mods and going over capacity, and they list anything the calculator could not include under not_calculated.
{
"weapon": "Soma Prime",
"mods": ["Serration", { "name": "Split Chamber", "slot_polarity": "madurai" }, "Vital Sense"],
"riven": { "effects": { "critChance": 120, "multishot": 90 }, "polarity": "madurai" },
"arcanes": ["Primary Merciless"],
"conditionals": true,
"target": { "faction": "Grineer", "armor": 500 }
}Build inputs also take exilus, stance, combo_multiplier, status_types_on_target, attack, catalyst, level (for rank 40 items), base_stats and extra_effects, which covers buffs from abilities the tool can't see, such as { "damage": 50 }. Zaws and Kitguns replace weapon with zaw: { strike, grip, link } or kitgun: { chamber, grip, loader }.
Frames: 119 Warframes, 32 companions, 5 Archwings and 2 Necramechs.
Weapons: 677 primaries, secondaries, melee, Exalted, Archwing and companion weapons, every Zaw and Kitgun combination, and all their attack modes.
Mods: 1,269 mods including stances, auras, Exilus and PvP-only ones, plus 168 arcanes. You enter Rivens with the stats you rolled.
Damage: elements and combinations in mod order, crit, multishot, status procs, damage over time, enemy armor, faction damage, faction mods, heavy attacks, combo scaling and stance combos.
Formulas come from the Warframe wiki, and the tests check them against the wiki's worked examples. The data is cross-checked between WFCD and the wiki where both have it, and the import stops rather than writing data if known values stop matching.
Nothing was checked in-game, and both sources are community maintained, so they can lag behind patches or contain mistakes. Treat the numbers as well-founded theory.
Left out of damage: weak points, shields, armor stripped by status effects, ability buffs (unless passed through extra_effects), status duration mods, forced procs and the game's 1/32 damage rounding.
Triggered effects: Galvanized mods and arcanes only count when you set conditionals: true, and then always at full stacks. That makes the result a peak, not an average.
Listed, not calculated: set bonuses, most aura effects on squadmates and weapons, and other effects with no fixed number. They appear in not_calculated.
Melee: per-combo stance DPS ignores stance slash and status multipliers. Plain burst_dps ignores the stance completely.
Heavy attacks: they exclude Bleed and wind-up mods. Many multi-hit classes don't match their listed class multiplier in the sources, and those results are marked unconfirmed.
Other frames: companions, Archwings and Necramechs use the stats the sources list, since they publish no rank 30 rule. Necramechs have 12 slots. The tool caps the others at 12 too, as the sources don't confirm their counts, and suggests at most 8 mods for them.
Exalted weapons: Ability Strength scaling isn't included.
Suggestions: they assume you own every mod at max rank, so use exclude for any you don't. They only choose mods with effects the calculator can model, and they don't choose arcanes. The search is heuristic, so a better build can exist. Against brute force over each weapon's 15 strongest mods it matched in all 16 cases tested, but a wider 17-mod run found one heavy attack build 4.3% better.
Not supported: Railjack, Necramech melee, vehicles, amps and Operator gear.
data.json is generated, so don't edit it by hand. A GitHub Action refreshes it weekly when the sources change and the tests still pass. To refresh it yourself:
npm run import-datanpm testPath | Contents |
| MCP protocol, tool definitions and input checks |
| Calculations: |
| The data import, and a parser for the wiki's Lua tables |
The code is under the MIT license. The game data has its own terms, including a non-commercial license on the wiki-derived parts. See NOTICE.md. This project is not affiliated with Digital Extremes.
Show the server version, when the game data was imported, what it covers and its limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world access, so the safety profile is fully covered. The description adds something annotations cannot: that the response reports data provenance and known limitations, which matters because no output schema exists. It stops short of describing format or freshness guarantees.
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?
One sentence, front-loaded with the verb, with every clause adding a distinct returned field. Nothing is redundant or wasted.
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?
With no parameters and no output schema, the description carries the burden of describing return content, and it lists all four categories of information. It could go slightly further on how 'limits' or 'coverage' are expressed, but the essential picture is complete.
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?
The tool takes zero parameters, so there is no parameter semantics burden; baseline is 4. The description correctly implies a parameterless, unconditional call.
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?
The description uses a specific verb ('Show') and enumerates exactly what metadata is returned: server version, import timestamp, coverage, and limits. It is clearly distinct from the sibling tools, which all list or search game entities, though it never explicitly says so.
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?
Usage is only implied: an agent can infer this is a health/dataset-metadata check to run before trusting list/search results. There is no explicit statement of when to call it, when not to, or which sibling it complements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the parts for building a Zaw or Kitgun with weapon_build.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without description help. The description adds only the workflow linkage to weapon_build; it says nothing about result shape (e.g., grouping by part slot or per-kind fields) that would exceed the annotations.
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?
A single compact sentence with the action, the resource, the parameter scope, and the downstream consumer all front-loaded. No filler and nothing wasteful.
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?
For a one-parameter read-only lookup with no output schema, the description covers what the tool returns (parts) and why (to feed weapon_build). A little more on how results are organized per kind would make it fully complete, but nothing essential for correct invocation is missing.
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?
There is one parameter, kind, whose enum values (zaw, kitgun) are already self-documenting in the schema; the description echoes both by name, confirming that Zaw and Kitgun are the supported part categories. That is adequate meaning for a single enum parameter even at 0% schema description coverage.
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 (List) and a specific resource (parts for building a Zaw or Kitgun), so an agent can tell it apart from sibling builders like weapon_build. It does not explicitly contrast with list_weapons or search_mods, but the noun scope is narrow enough to be unambiguous.
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?
The phrase 'with weapon_build' implies this is a prerequisite lookup step before calling weapon_build, which is useful implied workflow. However, there is no explicit when-to-use/when-not statement, no mention of whether it is required before weapon_build, and no exclusion of other part-related paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Warframes, companions, Archwings or Necramechs by name, with stats, polarities and abilities.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Default warframe. | |
| limit | No | ||
| query | No | Part of a name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds that results include stats, polarities and abilities, which is useful, but says nothing about how the 'limit' parameter affects the response or whether results are partial matches.
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?
A single dense sentence that front-loads the verb, the resource scope and the returned data. No filler, no repetition of the tool name.
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?
For a read-only search tool with no output schema, the description does the essential work of stating what fields come back (stats, polarities, abilities). The only gap is how 'limit' and the 'kind' default behave, which an agent may need to call it 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?
Schema coverage is 67%: 'query' is documented as 'Part of a name' and 'kind' has an enum, while 'limit' has no description anywhere. The description's 'by name' reinforces the query semantics (substring matching) but adds nothing for limit or kind defaults.
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?
The description names a specific verb ('Find') and enumerates the exact resource set (Warframes, companions, Archwings, Necramechs) plus what data comes back (stats, polarities, abilities). This clearly separates it from siblings like list_weapons or search_mods, though no sibling is named explicitly.
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?
The phrase 'by name' implies a lookup use case, but there is no explicit when-to-use or when-not guidance, and no pointer to alternatives such as warframe_build or suggest_warframe_build when the agent actually wants build data. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find primary, secondary, melee, Exalted, Archwing and companion weapons by name or type, with attack modes and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | A class such as Rifle, Shotgun, Bow, Nikana or Exalted Weapon, or a slot: primary, shotgun, secondary, melee, archgun, archmelee or claws. | |
| limit | No | ||
| query | No | Part of a name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior, and the description adds that results include attack modes and stats — useful given there is no output schema. It says nothing about result volume, default/max values of 'limit', or whether an empty query returns everything.
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?
A single front-loaded sentence with no filler; every clause (categories, name/type matching, attack modes and stats) carries information. Slightly list-heavy but efficient.
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?
The absence of an output schema makes the note about returned attack modes and stats valuable, but the description leaves open how 'limit' behaves and how the arbitrary 'type' strings from the schema combine with 'query'. Adequate for a simple read tool, not fully complete.
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?
Schema coverage is 67%; the description's 'by name or type' loosely maps to 'query' and 'type', which the schema already documents in more detail. The 'limit' parameter is undocumented in both schema and description, so the description adds little beyond the structured fields.
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 ('Find') and resource ('weapons') and enumerates the covered weapon categories (primary, secondary, melee, Exalted, Archwing, companion), which lets an agent distinguish it from list_warframes and search_mods. It stops short of naming a sibling tool as the alternative, so it is clear but not maximally differentiated.
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?
The 'by name or type' phrasing implies a lookup use case, but there is no explicit when-to-use or when-not-to-use guidance relative to weapon_build, suggest_weapon_build, or list_modular_parts. The agent must infer that this is the discovery step before the build tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arcanes by name or effect text.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | warframe, primary, shotgun, bow, secondary, melee, zaw, kitgun, operator or amp. | |
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds that matching is by name or effect text, but it omits return format, pagination, and how the limit parameter affects results.
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?
A single front-loaded sentence with no wasted wording. It immediately states the action and the matching behavior.
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?
For a read-only search tool, the description identifies the resource and matching fields, and annotations cover safety. Yet with no output schema and an undocumented limit parameter, the definition does not explain result size, ordering, or how type filtering interacts with the search.
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?
Schema description coverage is only 33%: the type parameter is documented in the schema, but query and limit are not. The description adds useful meaning for query by specifying name/effect text matching, but it gives no guidance on limit and does not compensate for the undocumented parameters.
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: search arcanes, and clarifies the searchable fields (name or effect text). It is clear what the tool does, but it does not explicitly distinguish itself from sibling search tools such as search_mods.
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?
The description implies when to use the tool by saying it searches arcanes by name or effect text. However, it does not state when to prefer it over sibling search/list tools or mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search mods by name, effect (for example strength or multishot) or effect text. Leaves out PvP-only mods unless asked.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No | ||
| include_pvp | No | Include Conclave-only mods. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, read-only, idempotent search. The description adds a meaningful behavioral detail beyond annotations: PvP-only mods are excluded by default unless requested, which affects result interpretation.
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?
Two short sentences, front-loaded and free of filler. The default PvP exclusion is placed after the core search behavior where it is easy to scan.
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?
For a simple read-only search tool with annotations and no output schema, the description covers the essential purpose and the key default filtering behavior. It is slightly thin on category semantics and result limiting, but those gaps are minor.
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?
Schema coverage is only 25%, and the description partially compensates by explaining that the query can match mod name, effect name, or effect text. It does not clarify the category or limit parameters, so important semantics remain undocumented.
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 ('Search mods') plus the searchable fields (name, effect, effect text). It is clear what the tool does, though it does not explicitly differentiate itself from sibling search/list tools such as search_arcanes.
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?
Usage is implied by the search-by-fields phrasing, and the description notes the default PvP exclusion. However, it gives no explicit guidance about when to choose this tool over alternatives or what happens when the query is broad.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest mods for a Warframe, companion, Archwing or Necramech towards a goal or targets, within capacity, polarities and conflicts. Stats: strength, duration, range, efficiency, health, shields, armor, energy or effective_health.
| Name | Required | Description | Default |
|---|---|---|---|
| aura | No | Aura mod name or {name, rank, slot_polarity}. | |
| goal | No | One stat, or weights such as {strength: 2, efficiency: 1}. Stats: strength, duration, range, efficiency, health, shields, armor, energy or effective_health. | |
| mods | No | Mods that must be in the build. | |
| forma | No | Extra Forma you are willing to add. The result lists the polarities to add. Default 0. | |
| level | No | The item's rank, which sets its capacity. Default 30. Kuva and Tenet-style weapons and Necramechs can reach 40. | |
| exilus | No | Exilus mod name or {name, rank, slot_polarity}. | |
| arcanes | No | Arcane names or {name, rank} objects. Their triggered effects count when conditionals is true. | |
| exclude | No | Mods not to use, such as ones you do not own. | |
| reactor | No | Orokin Reactor installed. Default true. | |
| targets | No | Minimums to reach first, such as {efficiency: 175, strength: 145}. Results list any it could not reach. | |
| warframe | Yes | ||
| base_stats | No | ||
| polarities | No | The frame's current slot polarities, if you have added Forma. Defaults to its own. | |
| use_exilus | No | Pick an Exilus mod if none is named. Default true. | |
| second_aura | No | Jade only. Second aura mod name or {name, rank, slot_polarity}. | |
| conditionals | No | Count triggered effects, such as Galvanized mods and arcanes, at full stacks. Gives a peak figure. Default false. | |
| archon_shards | No | Shards to include, as a stat name or {stat, tauforged}. | |
| extra_effects | No | Extra percentage bonuses for buffs this tool cannot see, by effect name, such as {damage: 50, critChance: 25}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish the safety profile (readOnlyHint: true, destructiveHint: false). The description adds crucial functional context by explaining that it manages complex interactions like capacity, polarities, and conflicts, which are behavioral traits not captured by simple safety hints.
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?
The definition is efficient. The first sentence front-loads the core functionality and its scope, while the second sentence concisely summarizes the data points it handles, achieving maximum information density without unnecessary padding.
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?
Given the complexity and number of parameters (18), the description adequately explains *what* the tool does and *how* it calculates results. However, it lacks completeness regarding the structure or ambiguity of the output, such as whether it returns a single best build or a list of viable options.
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?
With high schema coverage (89%), the baseline is strong. The description adds specific value by explicitly listing the exact stat types that can be referenced in the goal and targets (e.g., 'efficiency', 'effective_health'), reinforcing the allowed semantic vocabulary for complex input parameters.
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?
The description specifies the exact action ('Suggest mods') and the resources it affects ('Warframe, companion, Archwing or Necramech'). It clearly defines the operational constraints by mentioning goals, targets, capacity, polarities, and conflicts, making it easy to distinguish from general 'build' tools.
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?
The description implicitly tells the agent two usage paths: optimizing toward a 'goal' or achieving minimum 'targets'. However, it offers no guidance on when to use this highly complex tool versus simpler alternatives like 'warframe_build' or 'search_mods' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest the mods that give a weapon, Zaw or Kitgun the most damage, within its capacity, polarities and mod conflicts. Pass target to pick for a specific enemy instead of raw damage.
| Name | Required | Description | Default |
|---|---|---|---|
| zaw | No | A Zaw from parts: {strike, grip, link}. See list_modular_parts. | |
| goal | No | Defaults to sustained_dps for guns and burst_dps for melee. heavy_attack is melee only. | |
| mods | No | Mods that must be in the build. | |
| forma | No | Extra Forma you are willing to add. The result lists the polarities to add. Default 0. | |
| level | No | The item's rank, which sets its capacity. Default 30. Kuva and Tenet-style weapons and Necramechs can reach 40. | |
| riven | No | A Riven with your rolled stats: {effects, polarity, drain, slot_polarity}, such as {effects: {critChance: 120, multishot: 90}, polarity: "madurai", drain: 18}. Fills a regular slot. | |
| attack | No | Attack mode from list_weapons. Defaults to the first. | |
| kitgun | No | A Kitgun from parts: {chamber, grip, loader}. See list_modular_parts. | |
| stance | No | Melee only. Defaults to a fitting stance, chosen only for its capacity. | |
| target | No | The enemy: {faction, armor}. Applies faction damage multipliers, armor reduction and faction mods. See data_info for factions. | |
| weapon | No | Weapon name. Use this, zaw or kitgun. | |
| arcanes | No | Arcane names or {name, rank} objects. Their triggered effects count when conditionals is true. | |
| exclude | No | Mods not to use, such as ones you do not own. | |
| catalyst | No | Orokin Catalyst installed. Default true. | |
| polarities | No | The weapon's current slot polarities, if you have added Forma. Defaults to the weapon's own. | |
| use_exilus | No | The weapon has an Exilus adapter. Default false. | |
| conditionals | No | Count triggered effects, such as Galvanized mods and arcanes, at full stacks. Gives a peak figure. Default false. | |
| extra_effects | No | Extra percentage bonuses for buffs this tool cannot see, by effect name, such as {damage: 50, critChance: 25}. | |
| combo_multiplier | No | Melee only. Combo multiplier from 1 to 12. Default 12. | |
| status_types_on_target | No | Status types on the enemy, for mods such as Condition Overload. Default 0. |
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 and the description doesn't need to repeat it. It adds the useful behavioral fact that the result recommends polarities to add and that mods are chosen subject to capacity and conflicts. It does not describe what the returned suggestion actually contains (mod list, damage figure, forma count) — a notable gap since there is no output schema.
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?
Two sentences with no filler. The core purpose is front-loaded, and the one optional usage tip follows immediately after. Nothing is wasted and nothing is buried.
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?
For a 20-parameter tool with nested objects (zaw, kitgun, riven, target) and no output schema, the description is thin: it never outlines the shape of the returned build suggestion or how the competing optimization goals are resolved. The schema covers inputs thoroughly, but the output side rests entirely on the description, which gives it only a passing mention.
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?
Schema description coverage is 100%, so all 20 parameters are already documented in the schema, including defaults and enum values. The description adds only marginal semantics ('target' switches from raw damage to a specific enemy; capacity/polarity constraints bind the `forma`, `polarities` and `level` params). Baseline 3 is appropriate when the schema carries the detail.
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: suggests mods maximizing damage for a weapon, Zaw, or Kitgun. The 'suggest' framing and the constraint vocabulary ('within its capacity, polarities and mod conflicts') distinguish it from the sibling weapon_build, which evaluates an existing build. It never names that sibling explicitly, so differentiation is inferred rather than stated.
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?
The second sentence gives a genuine routing hint — pass `target` for a specific enemy instead of raw damage — which is a use-case condition. However, there is no guidance on when to use this versus weapon_build, no prerequisites (weapon/zaw/kitgun are mutually exclusive per the schema but the description doesn't say so), and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a Warframe, companion, Archwing or Necramech build: final stats, ability stats, armor mitigation and mod capacity.
| Name | Required | Description | Default |
|---|---|---|---|
| aura | No | Warframes only. Aura mod name or {name, rank, slot_polarity}. | |
| mods | No | Mod names, or {name, rank, slot_polarity} objects. Rank defaults to max. Use slot_polarity "none" for an empty slot. | |
| level | No | The item's rank, which sets its capacity. Default 30. Kuva and Tenet-style weapons and Necramechs can reach 40. | |
| exilus | No | Exilus mod name or {name, rank, slot_polarity}. | |
| arcanes | No | Arcane names or {name, rank} objects. Their triggered effects count when conditionals is true. | |
| reactor | No | Orokin Reactor installed. Default true. | |
| warframe | Yes | Name of a Warframe, companion, Archwing or Necramech. | |
| base_stats | No | Overrides for health, shields, armor or energy. | |
| second_aura | No | Jade only. Second aura mod name or {name, rank, slot_polarity}. | |
| conditionals | No | Count triggered effects, such as Galvanized mods and arcanes, at full stacks. Gives a peak figure. Default false. | |
| archon_shards | No | Up to 5 shards, as a stat name or {stat, tauforged}: strength, duration, health, shields, armor or energy. | |
| extra_effects | No | Extra percentage bonuses for buffs this tool cannot see, by effect name, such as {damage: 50, critChance: 25}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only, idempotent, non-destructive annotations already cover the safety profile, and the description adds useful behavioral context by naming the outputs: final stats, ability stats, armor mitigation, and mod capacity. It still omits assumptions and caveats such as default handling of conditionals or peak-stack behavior.
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?
The description is a single front-loaded sentence with no filler. Every clause contributes either scope or output 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?
For a 12-parameter calculation tool with no output schema, the description names the covered item classes and the main output categories, while the schema handles parameter details. It is nearly complete, though it could say more about the returned structure and calculation assumptions.
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?
Schema description coverage is 100%, and the 12 parameters including nested objects are fully documented in the input schema. The description itself adds no parameter-level detail beyond the general calculation purpose, so baseline 3 is appropriate.
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?
The description has a specific verb (Calculate), a specific resource (build), and a clear scope (Warframe, companion, Archwing, Necramech) plus the main computed outputs. It does not explicitly differentiate this from the sibling suggest_warframe_build, which is also Warframe-build-oriented, so it falls short of a 5.
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?
The description states what the tool calculates but gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as suggest_warframe_build or weapon_build. An agent must infer that this is for final stat calculation rather than build suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a weapon, Zaw or Kitgun build: damage by type, crit, status, damage over time, DPS and mod capacity. Melee results add range, heavy attacks and per-combo stance DPS. Pass target for damage against an enemy.
| Name | Required | Description | Default |
|---|---|---|---|
| zaw | No | A Zaw from parts: {strike, grip, link}. See list_modular_parts. | |
| mods | No | Mod names, or {name, rank, slot_polarity} objects. Rank defaults to max. Use slot_polarity "none" for an empty slot. | |
| level | No | The item's rank, which sets its capacity. Default 30. Kuva and Tenet-style weapons and Necramechs can reach 40. | |
| riven | No | A Riven with your rolled stats: {effects, polarity, drain, slot_polarity}, such as {effects: {critChance: 120, multishot: 90}, polarity: "madurai", drain: 18}. Fills a regular slot. | |
| attack | No | Attack mode from list_weapons, such as Incarnon Form. Defaults to the first. | |
| exilus | No | Exilus mod name or {name, rank, slot_polarity}. | |
| kitgun | No | A Kitgun from parts: {chamber, grip, loader}. See list_modular_parts. | |
| stance | No | Melee only. Stance mod name or {name, rank, slot_polarity}. Adds capacity and gives per-combo DPS. Defaults to the weapon's stance polarity. | |
| target | No | The enemy: {faction, armor}. Applies faction damage multipliers, armor reduction and faction mods. See data_info for factions. | |
| weapon | No | Weapon name. Use this, zaw or kitgun. | |
| arcanes | No | Arcane names or {name, rank} objects. Their triggered effects count when conditionals is true. | |
| catalyst | No | Orokin Catalyst installed. Default true. | |
| base_stats | No | Overrides: damage (by type), critChance, critDamage, statusChance, fireRate, pellets, magazine, reload, ammoCost, heavyAttack, range, windUp. | |
| conditionals | No | Count triggered effects, such as Galvanized mods and arcanes, at full stacks. Gives a peak figure. Default false. | |
| extra_effects | No | Extra percentage bonuses for buffs this tool cannot see, by effect name, such as {damage: 50, critChance: 25}. | |
| combo_multiplier | No | Melee only. Combo multiplier from 1 to 12. Scales heavy attacks, Blood Rush and Weeping Wounds. | |
| status_types_on_target | No | Status types on the enemy, for mods such as Condition Overload. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral detail by listing computed outputs and noting that melee results include range, heavy attacks, and per-combo stance DPS, but it does not disclose error behavior, data assumptions, or limitations beyond that.
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?
The description is three compact sentences and front-loads the core purpose and result categories. The final sentence about passing target is slightly redundant with the schema but still useful as a usage cue, so it is mostly efficient.
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?
For a complex 17-parameter calculator with nested objects and no output schema, the description gives a strong summary of what results include and how melee differs. It does not cover alternative-tool routing, but the schema handles parameter details thoroughly and the description supplies enough output context for correct invocation.
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?
Schema description coverage is 100%, so the schema already documents all 17 parameters in detail, including nested shapes and defaults. The description’s only parameter-related addition is the target hint, which largely restates the schema’s own target description; baseline 3 is appropriate.
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?
The description uses a specific verb (Calculate) and resource (weapon, Zaw or Kitgun build) and enumerates the computed outputs, so an agent can tell what the tool produces. It does not explicitly distinguish itself from the sibling suggest_weapon_build, which could be a source of selection ambiguity.
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?
Usage guidance is implied rather than explicit: the description says to pass target for enemy damage calculations, but it does not state when to choose this tool over suggest_weapon_build or other siblings. There are no when-not-to-use conditions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0data_infolist_modular_partslist_warframeslist_weaponssearch_arcanessearch_modssuggest_warframe_buildsuggest_weapon_buildwarframe_buildweapon_buildScored across 10 tools
Tools separate cleanly into lookup (list_*/search_*), calculation (_build), and recommendation (suggest_*_build) roles. The closest pair, warframe_build vs suggest_warframe_build, is distinguished by their descriptions (evaluating supplied mods vs. proposing mods), and weapon_build/suggest_weapon_build mirror that split. Only list_modular_parts sits slightly apart as a sub-lookup for weapon_build, but its description ties it back.
The set mixes verb_noun forms (list_warframes, search_mods) with noun-first forms (warframe_build, weapon_build) and a suggest_ prefix. The pairing is at least internally symmetric (warframe_build/suggest_warframe_build, weapon_build/suggest_weapon_build), so it stays readable. However, a uniform pattern like calculate_warframe_build or list_modular_parts vs weapon_parts would be cleaner.
Ten tools is well within the sweet spot. Each one maps to a distinct step in the build-planning workflow: enumerate entities, search mods/arcanes, compute stats, and get suggestions. Nothing feels padded or redundant.
The surface covers the full loop of finding frames/weapons/mods/arcanes, calculating stats, and recommending builds, including modular weapons and target-aware damage. Minor gaps remain: no enemy/target lookup tool despite 'target' parameters, and no way to enumerate mods by slot, polarity, or compatibility beyond free-text search, which may force guesswork.
Connect any AI to your Foundry VTT world: actors, combat, dice, journals, tokens, compendiums.
Image and video AI tools and your own pipelines, run from any AI assistant.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Savecraft serves real save game data and expert game knowledge to AI assistants.
