warframe-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct aspect of Warframe: lookups are split by entity type (warframe, weapon, mod, item), and other tools have clear boundaries (market prices vs. drops vs. relic contents vs. crafting). No two tools appear to do the same thing.
Naming Consistency3/5
Names use a mix of verb-noun (lookup_warframe, search_drops, find_enemy_spawn) and noun-only styles (world_state, crafting_requirements, color_palette_finder). All are lowercase with underscores, but the lack of a uniform verb-noun pattern makes the set feel somewhat inconsistent.
Tool Count3/5
19 tools is on the heavier side, fitting the 'borderline' range (16-25). The server covers a wide breadth of Warframe functionality, but each tool is distinct and could justify its existence; still, the number feels a bit overwhelming for a single server.
Completeness4/5
The tool surface covers most core Warframe needs: item/weapon/frame lookups, crafting both directions, drop tables, relic contents, world state, fissures, market prices, builds, farm routes, and task synergy. Minor gaps exist (e.g., no dedicated syndicate or clan tool), but agents can work around them.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that multiple items can be looked up and that the output is dynamically formatted, which is a behavioral trait. However, it does not explain the return structure, error handling, or whether lookups are exact or partial matches, leaving significant ambiguity for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Look up one or more items'), uses a parenthetical to list examples, and ends with a concise clause about dynamic formatting. Every word serves a purpose, with no redundancy.
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?
With no output schema, the description should clarify what the agent can expect as a result. It only mentions 'dynamic formatting of available fields' without specifying which fields are available or how the output is structured. It also does not address not-found cases or the relationship to specialized sibling lookups, leaving moderate gaps.
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?
The schema fully documents the only parameter 'names' with type, min/max item counts, and examples, giving 100% coverage. The description adds no additional meaning beyond restating 'by name' and 'one or more', so the baseline score of 3 is appropriate.
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 clearly states that the tool looks up items by name and lists example categories (arcanes, resources, blueprints), giving a specific verb and resource. It also mentions a distinctive behavior ('dynamic formatting'), but it does not explicitly contrast with sibling tools like lookup_warframe or lookup_mod, so it stops 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling lookup tools (e.g., lookup_warframe, lookup_mod, market_price_check). The description simply states what the tool does without exclusions or alternatives, leaving the agent to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful output behavior: refinement chances and optional relic farming locations. However, it does not disclose the data source, read-only nature, match semantics (whether all query parts must appear in one relic or any), or how vaulted relics are handled — meaningful gaps for a lookup tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 18-word sentence, front-loaded with the core purpose ('Find which relics contain...'). Every clause earns its place: prime parts scope, refinement chances, and the optional farming locations. Zero waste or redundancy.
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?
With no output schema and no annotations, the description must explain return values, which it partially does (relics, refinement chances, optional farming locations). However, it lacks clarity on how multiple queries are combined, whether vaulted relics are included, and the response structure. Given the moderate complexity (array input, boolean flag) and many overlapping sibling tools, a bit more context would round it out.
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 100%, so the baseline is 3. Both parameters (queries and show_relic_sources) are well-documented in the schema with examples and defaults. The description adds marginal value by framing the overall output ('with refinement chances and optional relic farming locations'), which helps interpret the show_relic_sources flag, but it does not introduce new parameter-level detail.
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?
The description uses a specific verb+resource pattern: 'Find which relics contain one or more specific prime parts' — unambiguously identifying the tool's function. It distinguishes itself from siblings like search_drops (generic drop search), prime_vault_status (vaulting info), and baro_kiteer (void trader inventory) by focusing specifically on relic contents for prime parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when you need to know which relics drop given prime parts, with refinement chances. However, there is no explicit guidance about when NOT to use it or which alternative to choose (e.g., search_drops for non-relic drops, prime_vault_status for vaulting info). No exclusions or named alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description uses 'List', indicating a read-only operation, and 'active' implies current data, but it does not disclose behavior such as return format, pagination, or what happens with no matching fissures. With no annotations, the description carries the full burden but provides only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words), front-loaded with the verb, and every word contributes meaning. No redundancy or filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's core purpose and lists most filters, but it omits the platform parameter and does not describe return values. Since the schema covers parameters and no output schema exists, the description is mostly complete for a simple listing tool, though it could be slightly more thorough.
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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description repeats some filters (tier, Steel Path, Void Storm, mission type) but omits 'platform' and adds no syntactic or behavioral details beyond what the schema already provides.
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?
The description clearly states it lists active Void Fissure missions, with a specific verb ('List') and resource ('active Void Fissure missions'). It also mentions key filters, distinguishing it from sibling tools that focus on other content like Baro Ki'Teer or mods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing active fissures but provides no explicit when-to-use or alternative guidance. It does not mention when not to use this tool or compare it with siblings like 'world_state', which could also provide mission data, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read-only operation and notes 'current' status, which suggests real-time data. However, it does not disclose potential behavior like latency, errors, or whether any authentication is needed. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core purpose and provides an optional detail. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only lookup tool with 2 optional parameters, the description covers the key behavior: status, inventory, and worth analysis. It does not explain the exact output format, but with no output schema, this is a minor gap. Overall, it is sufficiently complete for the tool's complexity.
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?
Both parameters have schema descriptions covering 100% of the schema. The tool description adds value by mapping 'show_worth_analysis' to 'plat-per-ducat worth analysis', but this is a minor reinforcement beyond the schema's own description.
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?
The description uses a specific verb 'Check' and clearly identifies the resource 'Baro Ki'Teer's current status, inventory' plus the optional 'plat-per-ducat worth analysis'. This distinguishes it clearly from sibling tools like world_state or market_price_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. The purpose is clear enough that an agent would infer usage, but the description does not contrast with other tools that might also provide Baro-related information (e.g., world_state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add value by distinguishing 'confirmed locations' from 'likely faction nodes,' which hints at reliability of results. However, it does not discuss read-only nature, output structure, or any other side effects or limitations, which is a gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose and output types without filler. Every word contributes to understanding, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description does a good job of covering the essential purpose and the nature of results (confirmed vs. likely). It does not elaborate on the exact format of the response, but for a simple lookup tool with three params, this is reasonably complete. A perfect score would require more detail on return structure or edge cases.
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?
The input schema provides full descriptions for all parameters (100% coverage), so the baseline is 3. The description itself does not add parameter-specific meaning beyond reaffirming that the tool works with 'one or more specific enemies.' The steel_path and mission_preference parameters are not elaborated, but they are already well-documented in 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?
The description clearly states a specific action ('Find') and resource ('where one or more specific enemies spawn'), and distinguishes the tool by mentioning two concrete output types: 'confirmed locations from drop tables' and 'likely faction nodes.' This sets it apart from sibling tools like search_drops, which focus on drop tables rather than spawn locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need enemy spawn locations, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. The lack of explicit 'use this instead of X' or comparison with siblings leaves usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It lists what information is returned but does not mention potential quirks such as exact-name matching, behavior for unknown mods, case sensitivity, or the output format. This is an incomplete disclosure for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, followed by a colon and a list of return fields. Every word adds value and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool, the description covers the purpose and lists the returned data fields. However, there is no output schema and the description does not specify whether the return is a single object or an array, nor how errors are handled. This is a minor gap for a tool of this complexity.
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?
The input schema for the single 'names' parameter already provides a description and example. The tool description adds minimal value beyond restating that the lookup is 'by name' and that multiple mods are allowed. With 100% schema description coverage, the description does not add significant new parameter semantics.
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?
The description uses a specific verb ('Look up') and identifies the resource ('mods') and the fields returned ('stats progression, polarity, drain, rarity, and drop locations'). This clearly distinguishes the tool from sibling lookups for warframes, weapons, and items, and from drop-based searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving mod details by name, but it does not explicitly state when not to use it or name any alternative sibling tools. There is no explicit 'use X instead' guidance, so the usage context is clear only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output (drop locations, relics, missions, enemies, drop chances) but does not mention authenication requirements, rate limits, result limits (beyond schema), error handling, or the exact format of drop chances. This is acceptable for a read-only search tool but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core action ('Search drop tables') and then specifies outputs. Every clause adds value, with no meaningless filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a straightforward search operation with high schema coverage and no output schema, the description adequately explains return values: drop locations, relics, missions, enemies, and drop chances. However, it does not explicitly differentiate from the sibling 'relic_drops' tool, and it omits any mention of filtering (min_chance, limit) or per-query behavior, which would be useful for a complete picture.
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 100%, with all three parameters (queries, limit, min_chance) having descriptions. The tool description adds no extra parameter semantics beyond schema; it only mentions 'one or more items' and 'drop chances', which loosely maps to queries and min_chance. Since the schema already documents parameters thoroughly, the baseline of 3 is appropriate.
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?
The description clearly states the verb 'Search' and the resource 'drop tables', and specifies the scope: 'for one or more items' and the outputs: 'where they drop, from which relics, missions, and enemies, with drop chances.' This is specific and distinguishes it from broader lookup tools, though not from sibling 'relic_drops' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the tool does, but there is no explicit guidance on when to use this tool versus alternatives such as 'relic_drops' or 'lookup_item'. No exclusions or conditions are mentioned, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the cross-referencing behavior and the output (single mission suggestion) but omits any mention of the platform parameter, data freshness, error handling, or what happens if no combos exist. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the main purpose and states the benefit clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately covers purpose and output. The only minor gap is not mentioning the platform parameter in the description, but that is fully documented in the schema.
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?
The schema covers the only parameter ('platform') with a clear description and enum, achieving 100% schema coverage. The description adds no extra meaning about the parameter, but the baseline of 3 is appropriate given the schema's completeness.
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?
The description clearly states the tool's function with a specific verb ('find'), a defined resource ('activity combos'), and a concrete outcome ('which single mission can complete multiple objectives'). It references specific data sources (Nightwave, Fissures, Invasions, Sortie), distinguishing it from sibling tools like active_fissures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when seeking efficient multi-objective combos) but does not explicitly state when to use it over alternatives or when not to use it. No mention of sibling tools or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clarifies what data is included, which adds some value, but it does not mention platform-specific differences, data freshness, response format, or any rate limiting. The description is factual but shallow on behavioral traits beyond the content coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary purpose and then lists the included data areas. Every word earns its place, with no filler or repetition of the tool name. It is concise, scannable, and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with two optional parameters and no output schema. The description lists the exact content sections returned, which gives a good understanding of what to expect. However, without annotations or output schema, some behavioral completeness is missing (e.g., how data is returned, platform impact), but given the low complexity, the description is largely adequate. A full 5 would require explicit mention of response structure or caveats.
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?
The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds marginal value by listing section names that align with the enum values (e.g., 'open world cycles' maps to 'cycles'), but it does not introduce new meaning or clarify parameter usage beyond the schema. The schema already provides adequate semantics.
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?
The description uses the specific verb 'Get' and clearly identifies the resource as 'current Warframe world state', followed by an explicit list of content areas (sortie, archon hunt, nightwave, etc.). This distinguishes it from sibling tools like individual lookups or specific event trackers. It is not a tautology and fully explains what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a broad set of current world state data, and the sections parameter suggests selective usage, but it never explicitly states when to use this tool versus alternatives like baro_kiteer or active_fissures. There is no mention of exclusions or prerequisites, only the implied context of wanting current state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return contents and supports batched lookups, but it doesn't describe behavior for invalid items, partial matches, or other limitations. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key action, and every phrase contributes useful information. There is zero padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool with thorough schema coverage, the description includes the essential functional context and output details. It could still mention contrast with sibling tools like crafting_usage, but it is not incomplete.
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?
The input schema already covers the parameter with a clear description and examples, so the description adds no additional semantic value. With 100% schema coverage, baseline 3 is appropriate.
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?
The description uses a specific verb ('look up') and resource ('full crafting recipe'), and itemizes the output (components, credits, build time, sub-recipes). This clearly distinguishes it from sibling tools that focus on stats, prices, or usage.
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?
The phrase 'Answers what do I need to build X?' gives clear context for when to use the tool. However, it does not explicitly name alternatives or state when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full load. It accurately conveys the read-only search behavior and the ability to handle multiple inputs ('one or more given resources'). However, it doesn't disclose any limits, edge cases, or return format, so it offers only basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the main action in the first sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter reverse-lookup tool, the description sufficiently covers what it does and why you'd use it. Given the lack of an output schema, it could mention result presentation (e.g., list of item names) but that's a minor gap, and the context with sibling tools like crafting_requirements implies the inverse nature.
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?
The sole parameter (item_names) already has a 100% schema description with examples, and the tool description only echoes that a single or multiple resources are accepted. Since the schema does the heavy lifting, this is a baseline 3 with no added meaning.
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?
The description uses a specific verb ('Find') with a clear resource scope ('items that use... as crafting ingredients') and explicitly frames the two questions it answers. This distinguishes it from the inverse tool crafting_requirements and provides immediate understanding.
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?
The description provides clear usage context by naming two concrete applications ('what is this used for?' and 'is it safe to sell?'). However, it doesn't explicitly name alternative tools or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does describe what kinds of data are returned, which is useful, but it does not mention whether the operation is read-only, any potential side effects, rate limits, or error conditions. The description is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized sentence that front-loads the core action and resource, then lists the scope of information. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple lookup with one parameter and no output schema. The description lists the categories of information returned, which is sufficient for basic understanding. However, it does not mention any limitations, such as how many names can be looked up at once (although the schema specifies maxItems=10) or what happens if a name is not found. Minor gaps prevent a 5.
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 coverage for the single 'names' parameter is 100%, and the schema already provides a clear description with examples. The tool description adds the phrase 'by name,' which slightly reinforces parameter semantics, but this is already implied in the schema. Thus, the description adds minimal value beyond 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?
Description states a specific verb ('Look up') and resource ('Warframes by name'), and enumerates the exact kind of information returned (stats, abilities, component drop sources, build requirements, vault status). This clearly distinguishes it from sibling lookup tools for weapons, mods, and items.
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?
The usage context is clear: use this tool when you need information about Warframes. However, it does not explicitly mention when not to use it or point to alternatives (e.g., lookup_weapon for weapons), so it falls short of a perfect score but is above the 'no guidance' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently discloses the output categories (damage stats per fire mode, crit/status, components, build info) and the verb 'look up' implies a read-only operation. It does not detail error handling or edge cases, but for a lookup tool, the stated behavior is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with a clear verb, object, and a colon-separated list of result categories. It is concise, front-loaded, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description adequately covers the tool's purpose and return categories. It omits details like exact response format, case sensitivity, or error behavior, but for a simple lookup tool with a straightforward input schema, it provides enough context to select and invoke correctly.
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 100% for the single `names` parameter, which already includes an example and constraints. The description adds no further parameter-level detail beyond the schema, so it meets the baseline but does not go beyond it.
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?
The description uses a specific verb ('look up') and clearly identifies the resource (weapons by name), listing the exact types of data returned (damage stats, crit/status, components, build info). This distinguishes it from sibling lookup tools like lookup_warframe, lookup_mod, and lookup_item by resource and data scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: retrieving detailed weapon information by name. However, it does not explicitly state when to use this tool versus alternatives, especially since it includes 'build info' which might overlap with lookup_builds. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the types of data returned (sell/buy stats, cheapest sellers, trade chat messages) and implies a read-only nature via 'check'. However, it omits any details about response structure, pagination, rate limits, or data refresh behavior, which would be valuable for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, followed by key output details. Every word contributes, no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately simple with 4 well-documented parameters and no output schema. The description covers the core purpose and output categories, which is largely sufficient. Minor gaps exist (e.g., exact format of trade chat messages or order ordering), but overall the description gives an agent enough to understand what the tool returns.
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 100%, so the baseline is 3. The description only restates that multiple item names are accepted ('one or more tradeable items') and does not add meaning beyond the schema. No further elaboration on parameters is needed, but also no added value is provided.
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?
The description specifies 'Check live trading prices' for 'one or more tradeable items on warframe.market' and lists concrete output types (sell/buy stats, cheapest sellers, trade chat messages). This clearly distinguishes it from sibling lookup and state tools.
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?
The description clearly implies when to use this tool (whenever market prices are needed) and the term 'trading prices' sets it apart from item stats/other lookups. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must communicate behavioral traits. The verb 'Check' implies a read-only operation, but there is no explicit statement about side effects, rate limits, or data freshness. It is minimally adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately tells the user what the tool does. No filler, no repetition, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely complete. It covers the main purpose and expected result. The only slight gap is that it doesn't mention platform-specific behavior, but the schema handles that. Overall, sufficient.
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?
The schema covers the only parameter 'platform' with an enum and description. The tool description does not add any extra meaning about the parameter, so it relies on the schema's already-solid coverage. Baseline of 3 is appropriate.
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?
The description clearly states the tool's function: checking today's Cephalon Simaris synthesis target and recommended scanning locations. It uses a specific verb ('Check') and names the distinct resource, which differentiates it from sibling tools like world_state or baro_kiteer.
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?
The description provides clear context for when to use the tool—when you need today's Simaris target and locations. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough for an agent to select this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It clearly states the search behavior (input hex, get closest match coordinates) and implies a read-only operation. It doesn't mention how multiple matches work, but the schema's limit parameter covers that. Overall it gives a fair sense of what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and output. The 'Fashion Frame endgame tool' tagline is brief and adds flavor without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity lookup tool with no output schema, the description adequately covers input and output format. It could mention the return of multiple matches when limit > 1, but this is a minor gap given the schema's documentation.
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 100%, so the baseline is 3. The description adds minor context for hex_color but does not explain the palette filter or limit beyond what the schema already states. It doesn't degrade the score, but adds little value.
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?
The description specifies a clear verb ('Find'), a specific resource ('Warframe's color palettes'), and precise output ('palette, row, and column of the best match'). It is easily distinguished from sibling tools, none of which deal with color matching.
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?
The intended use case is obvious: match a hex color to a palette. While it does not explicitly name alternatives or exclusion criteria, the sibling tools cover distinct domains (market, drops, missions), so the context is clear without needing an explicit 'use this when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the internal mechanism (cross-referencing drop tables and dark sector bonuses), which is valuable. However, it does not disclose limitations such as whether the tool considers current game rotations or returns live data, nor does it mention the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every word contributes meaning. It avoids redundancy and directly conveys the tool's functionality without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, no output schema, no annotations), the description gives enough context about what the tool does and how it works to guide invocation. It does not explicitly describe the return value, but the phrase 'find mission nodes' implies the output. A fully complete description might add an example or clarify the output format.
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?
The input schema already provides full descriptions for both parameters (resources and prefer_mission_type) with 100% coverage. The description adds only minimal context on how parameters relate to the tool's purpose, but does not enrich parameter semantics beyond the schema. Baseline 3 is appropriate.
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?
The description clearly states the tool's purpose with a specific verb ('Find'), a specific resource ('mission nodes'), and a clear objective ('farm multiple resources simultaneously'). It also mentions the method (cross-references drop tables and dark sector bonuses), distinguishing it from sibling tools like search_drops or relic_drops that likely focus on single-resource lookup.
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?
The description implies when to use this tool: when needing to farm multiple resources at once. It clearly orients the agent toward the multi-resource optimization use case, but does not explicitly state when not to use it or mention alternative tools for single-resource needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the data source (Overframe.gg) and the output nature (top-voted builds with mod lists, computed stats, and build guides), giving a solid sense of what the tool does. It does not mention failure modes or rate limits, but for a read-only lookup tool, this is acceptable and above minimal viability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the action ('Find') and immediately specify the resource and source. Every clause contributes: the first sentence states the core function, the second clarifies the output details. There is zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the medium complexity (3 parameters, no output schema), the description covers the essential context: what it finds, for which item types, and what it returns. It lacks explicit error-handling or empty-result expectations, but it sufficiently sets user expectations for a lookup tool. It earns a 4 for being nearly complete, only missing edge-case details.
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?
The input schema already provides comprehensive descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds slight context by indicating 'top-voted builds' and 'one or more' items, but it does not meaningfully enrich parameter understanding beyond what the schema already says. No compensation is needed, but no extra value is given either.
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?
The description opens with a specific verb-action ('Find popular community mod builds') and clearly names the resource class (Warframes, weapons, companions) and source (Overframe.gg). It distinguishes itself from sibling lookup tools by focusing on community builds rather than raw item stats, making the purpose unmistakable.
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?
The description sets clear context: it is for retrieving community mod builds, not generic item data. Though it does not explicitly name alternatives (e.g., lookup_weapon for raw stats), the specificity of 'community mod builds' strongly implies when this tool should be used, and it provides no misleading guidance. This aligns with 'clear context, no exclusions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the three possible statuses checked (vaulted, Varzia, relic-farmable), giving agents a clear behavioral model. It does not describe the response format or limitations, but for a simple query tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's purpose without waste. It is well-structured and front-loaded, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool, the description covers the core functionality adequately. It does not specify return format or edge cases, but given the simple scope and schema, these are not critical gaps.
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 coverage is 100% with a well-documented 'names' parameter including examples. The tool description does not add additional parameter semantics beyond the schema, so the baseline score of 3 applies.
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?
The description uses the specific verb 'check' and identifies the resource (Prime items) and the exact states (vaulted, Varzia, relic-farmable). It clearly distinguishes from sibling tools like market_price_check or lookup_warframe by focusing on vault status.
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?
The description implies when to use it: when needing vault/availability status for Prime items. It provides clear context through the specific focus on Prime Resurgence and farming, but does not explicitly name alternatives or when-not-to-use. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![warframe-mcp MCP server](https://glama.ai/mcp/servers/mpeciakk/warframe-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mpeciakk/warframe-mcp)

Score Badge

Copy to your README.md:

[![warframe-mcp MCP server](https://glama.ai/mcp/servers/mpeciakk/warframe-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mpeciakk/warframe-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mpeciakk/warframe-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server