An EVE: Frontier Sui Move & Smart Assembly MCP server offering tools for Move contract generation, route planning, power optimization, turret targeting, threat intel, SSU market making, zkLogin verification, fuel radar, and PTB simulation.
Generate and audit Sui Move smart contract extensions (Witness, HotPotato, Capability guards) for Smart Assemblies.
Plan optimal stargate jump routes across public and Tribe-gated Smart Gates, minimizing fuel burn or tolls.
Calculate Lagrange Network Node fuel burn rates, GJ energy reservations, and offline-threat windows.
Evaluate Smart Turret target priorities using friend-or-foe standings and aggression flags.
Analyze on-chain killmails to map hostile tribe doctrines, gatecamp windows, and system threat scores.
Compute dynamic bid-ask spreads and inventory curves for Smart Storage Unit (SSU) vending machines.
Verify Sui zkLogin proofs, Character ownership, and Tribe membership capabilities.
Track constellation-wide Network Node fuel exhaustion timelines and vulnerability windows.
Simulate Sui Programmable Transaction Block (PTB) command arrays to block coin drains and unconsumed HotPotato traps.
Provides tools for interacting with the Sui blockchain in the context of EVE: Frontier, including Sui Move smart contract synthesis and auditing, Sui Programmable Transaction Block (PTB) simulation, zkLogin proof and Character object ownership verification, and on-chain killmail analysis.
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., "@Diogenes EVE: Frontier Sui Move & Smart Assembly MCP find the fastest Smart Gate route with the lowest fuel burn and tolls"
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.
diogenes-eve-frontier-mcp)
Diogenes EVE: Frontier Sui Move & Smart Assembly MCP is a focused, zero-bloat Model Context Protocol (streamable-http) package powered by the Diogenes Autonomous Microservice Gateway.
Instead of loading all 85 gateway endpoints into your LLM's context window, installing this package exposes only the 14 specialized eve-frontier tools needed for Gaming:
14 TDQS 5.0/5.0 EVE: Frontier Sui Move tools covering the complete Smart Assembly lifecycle: assembly state inspector, Tribe standings auditor, Move contract generator, Smart Gate ACL compiler, PTB drain simulator, zkLogin verifier, route planner, Lagrange GJ & siege simulators, fuel radar, SSU pricer, arbitrage finder, killmail analyzer, and turret target matrix.
mcp.json) for Cursor, Claude Desktop & WindsurfNo API keys, user accounts, or local dependencies required. Add this scoped endpoint to .cursor/mcp.json or claude_desktop_config.json:
{
"mcpServers": {
"diogenes-eve-frontier": {
"transport": "streamable-http",
"url": "https://diogenes-micro-gateway.corinth.workers.dev/mcp/eve-frontier"
}
}
}Related MCP server: @suiware/mcp
eve-frontier (14 Tools)MCP Tool Name | Underlying REST Route | Settlement | Capability |
|
| 80 sats (L402) | Inspects live EVE Frontier Smart Assembly on-chain object metadata, owner capability ID, online power status, and attached Sui Move package digest. Use when verifying whether a Smart Turret, Smart Gate, or Smart Storage Unit is online and checking its bound Move module before interacting; for generating or auditing custom Sui Move assembly source code, use generate_eve_assembly_move instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'assembly_id' ('assembly_class' defaults to 'smart_gate'), supports '?demo=true' or L402 (80 sats), and returns HTTP 400 if invalid. |
|
| 80 sats (L402) | Audits EVE Frontier Tribe diplomatic standings, friendly/hostile reputation scores, and pilot override entries across solar systems. Use when checking diplomatic relations or detecting conflicting friendly-fire rules across tribe registries; for compiling those standings into executable Sui Move Smart Gate ACL bytecode, use compile_eve_gate_acl instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'tribe_id' ('standing_filter' defaults to 'all'), supports '?demo=true' or L402 (80 sats), and returns HTTP 400 if invalid. |
|
| 200 sats (L402) | Generates and statically audits Sui Move smart contract modules for EVE Frontier Smart Assemblies using Witness, Capability, and HotPotato patterns. Use when authoring custom Sui Move extensions for Smart Gates, Smart Turrets, or Smart Storage Units; for simulating pre-signed Programmable Transaction Block command arrays before wallet execution, use simulate_eve_sui_ptb instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'contract_type' ('assembly_id' defaults to 'standard'), supports '?demo=true' or L402 (200 sats), and returns HTTP 400 if invalid. |
|
| 130 sats (L402) | Compiles EVE Frontier Tribe access control lists, diplomatic standings, and surge-pricing toll rules into Sui Move Smart Gate AccessPolicy constraints. Use when configuring on-chain jump permissions and LUX/SUI toll schedules for a player-owned Smart Gate; for calculating optimal multi-system jump routes across existing stargates, use plan_eve_gate_route instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'gate_assembly_id' ('toll_mode' defaults to 'standing_tiered'), supports '?demo=true' or L402 (130 sats), and returns HTTP 400 if invalid. |
|
| 150 sats (L402) | Simulates Sui Programmable Transaction Block (PTB) command sequences to detect unauthorized coin splits, object transfers, and unconsumed HotPotato receipts. Use when auditing an untrusted EVE Frontier transaction bundle before signing with a pilot wallet; for verifying pilot zkLogin JWT proofs and character ownership capabilities, use verify_eve_zklogin_character instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'ptb_commands_json' ('strictness_mode' defaults to 'strict_zero_drain'), supports '?demo=true' or L402 (150 sats), and returns HTTP 400 if invalid. |
|
| 100 sats (L402) | Verifies EVE Frontier Sui zkLogin BN254 zero-knowledge proofs, ephemeral session signatures, and SmartCharacter ownership capabilities. Use when authenticating a pilot's off-chain OAuth/zkLogin session before granting tribe vault or dApp access; for auditing tribe-wide diplomatic standings and reputation registries, use audit_eve_tribe_standings instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'jwt_proof' ('ephemeral_scheme' defaults to 'ED25519'), supports '?demo=true' or L402 (100 sats), and returns HTTP 400 if invalid. |
|
| 100 sats (L402) | Calculates optimal stargate jump routes between EVE Frontier solar systems minimizing gigajoule fuel consumption, LUX gate tolls, or jump count. Use when plotting a ship transit path across public and tribe-restricted Smart Gates; for identifying multi-system commodity arbitrage trade loops across Smart Storage Units, use find_eve_ssu_arbitrage instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'origin_system' ('destination_system' defaults to 'standard'), supports '?demo=true' or L402 (100 sats), and returns HTTP 400 if invalid. |
|
| 100 sats (L402) | Calculates Lagrange Network Node hourly gigajoule (GJ) fuel burn rates, capacity headroom, and offline vulnerability windows for connected Smart Assemblies. Use when balancing steady-state power allocations on a single Lagrange Network Node; for stress-testing node capacitor depletion under active hostile fleet bombardment, use simulate_eve_capacitor_siege instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'node_id' ('operating_profile' defaults to 'balanced'), supports '?demo=true' or L402 (100 sats), and returns HTTP 400 if invalid. |
|
| 135 sats (L402) | Simulates Lagrange Network Node gigajoule (GJ) capacitor drain under sustained hostile fleet siege and computes optimal assembly load-shedding order. Use when preparing base defense power-shedding schedules against an incoming hostile fleet; for calculating routine peacetime fuel burn and reserve headroom, use optimize_eve_node_power instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'node_id' ('siege_intensity' defaults to 'skirmish_frigate_squad'), supports '?demo=true' or L402 (135 sats), and returns HTTP 400 if invalid. |
|
| 140 sats (L402) | Monitors constellation-wide Lagrange Network Node fuel reserves, identifies the weakest sovereignty node, and calculates logistics convoy resupply urgency. Use when auditing multi-system sovereignty fuel health across an entire tribe constellation; for optimizing gigajoule load on a single individual Lagrange Network Node, use optimize_eve_node_power instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'constellation_id' ('alert_threshold_hours' defaults to '24h'), supports '?demo=true' or L402 (140 sats), and returns HTTP 400 if invalid. |
|
| 120 sats (L402) | Computes dynamic bonding-curve bid/ask quotes in LUX and per-transaction anti-drain caps for a player-owned Smart Storage Unit (SSU). Use when setting automated market-maker buy/sell prices for a single SSU vending inventory; for scanning multiple SSUs across star systems to find profitable trade routes, use find_eve_ssu_arbitrage instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'resource_type' ('pricing_regime' defaults to 'inventory_balanced'), supports '?demo=true' or L402 (120 sats), and returns HTTP 400 if invalid. |
|
| 140 sats (L402) | Scans Smart Storage Unit (SSU) bid/ask spreads across star systems against ship cargo capacity and stargate fuel costs to rank net-profitable arbitrage loops. Use when planning multi-system trade runs to maximize net LUX profit per gigajoule of fuel burned; for calculating internal bid/ask market-maker quotes for your own SSU, use quote_eve_ssu_market instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'origin_system' ('hull_cargo_class' defaults to 'light_courier'), supports '?demo=true' or L402 (140 sats), and returns HTTP 400 if invalid. |
|
| 150 sats (L402) | Analyzes on-chain EVE Frontier killmail.move events in a solar system to quantify gatecamp ambush probability and identify dominant hostile hull doctrines. Use when assessing solar system PvP danger before jumping a hauler or fleet into a system; for computing real-time weapon target-lock priorities during active grid combat, use prioritize_eve_turret_targets instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'system_id' ('time_window' defaults to '1h'), supports '?demo=true' or L402 (150 sats), and returns HTTP 400 if invalid. |
|
| 125 sats (L402) | Evaluates radar contacts by range, transversal velocity, and Tribe standing to output deterministic Smart Turret target-lock priorities and fire authorizations. Use when ranking active grid radar contacts for automated Smart Turret engagement; for reviewing historical solar system killmails and ambush probabilities before transit, use analyze_eve_killmail_threats instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'turret_id' ('engagement_doctrine' defaults to 'highest_threat'), supports '?demo=true' or L402 (125 sats), and returns HTTP 400 if invalid. |
Free Account-Less Demo Mode: Append
?demo=trueto any REST endpoint above for an instant HTTP 200 schema preview at zero cost.
Install only the domain packages relevant to your workflow:
Package | Scoped MCP Endpoint | Spoke Repository |
1. Gemini Suite & Agents |
| |
2. Agent Guardrails & Sandbox |
| |
3. Web3, DeFi & 402 Security |
| |
4. EVE: Frontier Sui Move Suite |
| |
5. Context, Code & Solvers (15 Tools) |
| |
6. Dev, Data & Workflow Utilities (14 Tools) |
| |
7. Full Master Gateway (All 85 Services) |
|
Field | Value |
Category |
|
Transport |
|
Endpoint |
|
Manifest |
|
Health Check |
|
Auth |
|
Install Confidence |
|
License |
|
Verification |
|
Maintainer |
|
Docs |
|
Support |
|
Computes optimal stargate jump routes across public and Tribe-gated Smart Gates minimizing fuel burn and toll tariffs.
| Name | Required | Description | Default |
|---|---|---|---|
| optimize_for | No | fewest_jumps, lowest_fuel, or lowest_toll | |
| origin_system | Yes | ||
| destination_system | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that routes span public and Tribe-gated Smart Gates and that optimization minimizes fuel burn and toll tariffs, but it does not state whether the operation is read-only, what permissions are needed for Tribe-gated gates, or what the response contains.
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 tightly written sentence with the core action and scope front-loaded. Every clause contributes to understanding what the tool does, with no filler or repetition.
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?
There is no output schema and no annotations, while schema coverage is low. The description identifies the optimization goal but omits expected system identifier formats and any sense of the returned route structure, leaving meaningful gaps for an agent invoking the tool.
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%, so the description needs to compensate for undocumented parameters. It does not explain the required origin_system or destination_system formats, and while it references fuel burn and toll tariffs, it does not explicitly connect those concepts to the optional optimize_for parameter.
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 gives a specific verb (Computes), resource (optimal stargate jump routes), and scope (public and Tribe-gated Smart Gates). No sibling tool covers stargate route planning, so the purpose is unambiguous and easy to distinguish from the other EVE 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?
It states what the tool computes, but gives no explicit guidance on when to use it, when not to use it, or which alternative to choose. Unlike a strong definition that routes the agent to a sibling for a different filtering need, this does not help an agent decide between this route planner and other EVE tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes on-chain EVE Frontier killmails to map hostile tribe doctrines, gatecamp windows, and system threat scores.
| Name | Required | Description | Default |
|---|---|---|---|
| solar_system_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only analysis but never confirms this, and says nothing about data recency, whether killmail history is bounded, permissions, or rate limits — all material for an intel tool whose value depends on freshness.
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 dense, front-loaded sentence with no filler; the verb and resource lead and the three outputs are enumerated compactly. Slightly jargon-heavy ("tribe doctrines", "gatecamp windows") but no wasted words.
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 one required parameter and no output schema, the description does list the categories of result, which is the main thing an agent needs. However it omits the input format and any temporal/scope caveats, so it is adequate rather than 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 description coverage is 0% for the single parameter solar_system_id. The phrase "system threat scores" weakly implies system scoping but does not name the parameter, state its accepted format (ID string), or clarify whether it is a single system or a set.
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 states a specific verb ("Analyzes") and resource ("on-chain EVE Frontier killmails") plus the three derived outputs. Nothing in the sibling list overlaps with killmail threat analysis, so it is effectively distinguishable, though it never explicitly contrasts itself with any sibling.
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?
There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The use case (assessing threat in a given system) is only inferable from the output nouns, leaving the agent to guess the triggering conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synthesizes and audits Sui Move smart contract extensions (Witness, HotPotato, Capability guards) for EVE Frontier Smart Assemblies.
| Name | Required | Description | Default |
|---|---|---|---|
| assembly_id | No | ||
| contract_type | Yes | turret_guard, gate_lock, storage_vault, or fuel_distributor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: it does not say whether contract code is written to disk, whether it requires permissions or an authenticated session, whether the audit mode is read-only, or whether generated output is destructive or reversible. 'Synthesizes and audits' implies dual modes without explaining their 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?
A single compact sentence that front-loads the main verbs and resource. It is appropriately sized, though the parenthetical jargon list is dense and unelaborated.
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 code-generation/audit tool with no annotations, no output schema, and one undocumented parameter, the description is insufficient: it never explains what the tool returns (code, patches, findings?) or how assembly_id interacts with contract_type. An agent lacks the context needed 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 description coverage is only 50%: contract_type lists its valid values in the schema, but assembly_id has no description anywhere. The description adds no meaning to either parameter, so it fails to compensate for the undocumented assembly_id.
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 gives specific verbs (synthesizes, audits) and a precise resource (Sui Move smart contract extensions for EVE Frontier Smart Assemblies), and names the concrete constructs (Witness, HotPotato, Capability guards). It is distinguishable from most siblings, though it does not explicitly contrast itself with the closest sibling, eve_sui_ptb_simulator.
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?
No guidance is given on when to use this versus alternatives such as eve_sui_ptb_simulator, nor on the distinction between the two advertised modes (synthesize vs audit). The agent must infer the appropriate context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates Lagrange Network Node fuel burn rates, gigajoule (GJ) energy reservations, and offline-threat windows.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | ||
| reserve_gj | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'Calculates' (implying a read), but 'energy reservations' hints at a state-changing reservation that could contradict the compute framing; permission needs, whether state is persisted, and side effects are all undisclosed.
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 efficient sentence with the verb front-loaded and no filler. It loses a point only because stacking three outputs in a comma list slightly dilutes the focus rather than organizing the purpose hierarchically.
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 annotations, no output schema, and 0% parameter coverage, the description should explain the inputs and the computed return values. It does neither, so an agent cannot determine what node_id refers to or what the three computed quantities are returned as.
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 0%, so the description must compensate for both parameters. It loosely ties 'reserve_gj' to 'gigajoule (GJ) energy reservations', giving a unit hint, but leaves node_id entirely undefined (node of what system?) and never explains the relationship between the two inputs.
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 gives a specific verb ('Calculates') and a named resource (Lagrange Network Node fuel burn rates), which is more than a tautology. However, it bundles three distinct outputs (fuel burn rates, GJ reservations, offline-threat windows) without clarifying the primary purpose, and it never distinguishes itself from the fuel-adjacent sibling eve_sovereignty_fuel_radar.
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?
There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The sibling list contains several overlapping energy/fuel tools (eve_sovereignty_fuel_radar, eve_sui_ptb_simulator) yet no routing guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tracks constellation-wide Network Node fuel exhaustion timelines and vulnerability windows.
| Name | Required | Description | Default |
|---|---|---|---|
| constellation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only states what is tracked. It doesn't disclose whether the tool is read-only, how fresh the data is, what permissions are needed, or what the return format looks like. This is a significant gap for a tracking tool.
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 wasted words. It is appropriately concise, though its brevity contributes to gaps in other dimensions.
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 tool likely returns complex data (fuel exhaustion timelines, vulnerability windows) and there is no output schema or annotations, the description is incomplete. It doesn't explain what the output contains or how to interpret it, leaving an agent under-informed.
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 single parameter 'constellation_id' has 0% schema description coverage, and the description only hints at its meaning via 'constellation-wide'. It provides no format, source, or constraints for the ID, so it does little to compensate for the schema gap.
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 states a specific verb ('Tracks') and resource ('constellation-wide Network Node fuel exhaustion timelines and vulnerability windows'), making the tool's purpose clear. However, it doesn't explicitly differentiate itself from siblings like eve_network_node_gj_optimizer or eve_gate_route_planner, 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 gives no guidance on when to use this tool versus alternatives, nor does it state any preconditions or exclusions. Usage is only implied by the tool name and the mention of tracking fuel exhaustion timelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes dynamic bid-ask spreads and inventory curves for Smart Storage Unit (SSU) autonomous vending machines.
| Name | Required | Description | Default |
|---|---|---|---|
| ssu_id | Yes | ||
| item_type | Yes | ||
| current_stock | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and falls short. It does not disclose whether the computation is read-only or mutates SSU state, whether it needs external market feeds, rate limits, or what the result looks like. Only the high-level computation is named.
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 efficient sentence that front-loads the verb and the core outputs, with no filler. It is appropriately sized, though its brevity contributes to the gaps elsewhere.
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 computation tool with no annotations, no output schema, and zero parameter documentation, the description is too thin. It omits return shape, required inputs context, and behavioral constraints, leaving an agent unable to call it confidently.
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 0% across three undocumented parameters, so the description must compensate and does not. 'ssu_id', 'item_type', and notably the optional 'current_stock' are never explained; the phrase 'inventory curves' only loosely gestures at stock without clarifying formats or the role of the optional input.
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 ('Computes') and a specific output resource ('dynamic bid-ask spreads and inventory curves') for a named domain object (SSU vending machines). The purpose is unambiguous, though it does not explicitly differentiate itself from siblings — which is largely unnecessary since the siblings are unrelated EVE 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?
Provides no when-to-use, when-not-to-use, or prerequisite guidance. It never states whether this requires live market data, a configured SSU, or when an agent should prefer this over any alternative, so invocation conditions must be entirely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statically simulates Sui Programmable Transaction Block (PTB) command arrays before signing to block coin drains and unconsumed HotPotato traps.
| Name | Required | Description | Default |
|---|---|---|---|
| ptb_commands | Yes | ||
| expected_max_outflow_mist | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does usefully disclose that simulation is static/read-only ('before signing') and names the failure modes it guards against (coin drains, unconsumed HotPotato traps). It omits whether it performs a dry-run, requires network/RPC access, or produces gas/error output.
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 with zero waste; the verb, resource, timing, and safety rationale are all front-loaded.
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?
No output schema and no annotations, so the description should convey what a simulation returns (pass/fail, gas, detected traps) and how results map to the two undocumented params. It leaves an agent unable to know what the call yields or how to set expected_max_outflow_mist.
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 0% and neither of the two parameters is explained. 'PTB command arrays' loosely maps to ptb_commands, but the constraint parameter expected_max_outflow_mist — central to the 'coin drain' use case — is never mentioned or defined.
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 ('Statically simulates') and resource ('Sui Programmable Transaction Block (PTB) command arrays'), then adds the safety goal (block coin drains and HotPotato traps). An agent can distinguish this immediately from all sibling tools, none of which touch Sui PTBs.
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 'before signing' gives clear timing context for when to invoke it, but there are no explicit when-not conditions and no alternative tools or workflows named. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates Smart Turret friend-or-foe standings, aggression flags, and deterministic target priority queues.
| Name | Required | Description | Default |
|---|---|---|---|
| turret_id | Yes | ||
| grid_entities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Evaluates' implies a read/compute operation, but it never states whether it mutates turret state, what permissions are required, or what the deterministic queue output looks like/its size. Only the semantic content being evaluated is disclosed.
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. It is dense with domain jargon but every clause carries meaning, so it is appropriately sized for the tool's scope.
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 no annotations, no output schema, and 0% parameter coverage, one sentence is not enough for a 2-parameter evaluator. The agent knows the theme but not how to supply inputs or interpret results, leaving significant gaps.
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 0%, so the description must compensate and it does not: turret_id and grid_entities are never explained. It vaguely implies grid_entities feed the evaluation, but there is no detail on the entity object shape or whether grid_entities is optional and what happens when omitted.
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?
It names a specific verb ('Evaluates') and concrete resources (Smart Turret friend-or-foe standings, aggression flags, target priority queues), which tells an agent exactly what domain this covers. It does not distinguish itself from any of the sibling tools, though the siblings operate in unrelated areas so overlap is unlikely.
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?
There is no statement of when to invoke this tool, no prerequisites (e.g. needing a valid turret_id or a populated grid), and no mention of alternatives. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies Sui zkLogin proofs, Character object ownership, and Tribe membership capabilities for Diplomacy & Gate ACLs.
| Name | Required | Description | Default |
|---|---|---|---|
| tribe_id | No | ||
| character_address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It does not disclose what a successful or failed verification returns, whether it is read-only, what happens on missing tribe_id, or any auth/rate-limit constraints.
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 and the checked resources. No waste, though the jargon-heavy packing slightly hurts readability.
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 verifier with no annotations, no output schema, and 0% parameter documentation, the description omits the call contract: parameter meaning, return values, and failure semantics. It is not complete enough to invoke 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 0% for two parameters. The description loosely implies character_address relates to Character ownership and tribe_id to Tribe membership, but gives no formats, validity rules, or whether tribe_id is optional.
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 (Verifies) and names the concrete resources checked: Sui zkLogin proofs, Character object ownership, and Tribe membership capabilities. It is clear what the tool does, though it does not explicitly differentiate itself from any sibling.
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 'for Diplomacy & Gate ACLs' implies the usage context, but there is no explicit when-to-use, when-not-to-use, or alternative tool named. The agent must infer that this is an authorization check.
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.4.0eve_gate_route_plannereve_killmail_threat_inteleve_move_assembly_codereve_network_node_gj_optimizereve_sovereignty_fuel_radareve_ssu_market_makereve_sui_ptb_simulatoreve_turret_target_matrixeve_zklogin_character_verifierScored across 9 tools
Most tools target clearly distinct EVE Frontier subsystems such as routing, intel, contract coding, fuel optimization, market making, transaction simulation, turret targeting, and identity verification. However, eve_network_node_gj_optimizer and eve_sovereignty_fuel_radar both focus on Network Node fuel/exhaustion, and eve_killmail_threat_intel and eve_turret_target_matrix both involve threat assessment, creating minor overlap.
All nine tools follow a highly predictable eve_<descriptive_snake_case> pattern with no casing deviations or mixed verb styles. The prefix and delimiter are used uniformly, making the set easy to scan and infer.
Nine tools is well-scoped for a specialized EVE Frontier blockchain/game MCP covering multiple mechanics. Each tool appears to address a distinct capability, with no obvious filler or redundant operations.
The surface covers planning, intel, smart contract development, energy/sovereignty management, market making, transaction simulation, turret targeting, and identity verification. Minor gaps exist around direct transaction/order execution and broader tribe/diplomacy management beyond verification, but core analytical workflows are well represented.
SUIOracle - 12 Sui tools: objects, modules, validators, gas, Cetus DEX, NFTs.
A Mentat's eye on Sui DeepBook v3: read-only market data plus desk template tools. No keys.
Free tools: x402 endpoint directory + probe, on-chain x402 demand signal, sudoku, API pricing.
AI Agent Utility Layer for agent safety, web monitoring, crypto research and tool discovery.