Skip to main content
Glama
Sign In
Diogenes Microservice Gateway

Diogenes Microservice Gateway

by stand-out-of-my-sun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

EVE Frontier Lagrange Node Siege Capacitor Depletion Simulator

simulate_eve_capacitor_siege
Read-onlyIdempotent

Simulates Lagrange Network Node gigajoule capacitor drain during a hostile fleet siege and computes the optimal assembly load-shedding order for base defense power scheduling.

Instructions

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 (30 sats), and returns HTTP 400 if invalid.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "node_id": "<node_id>"
    },
    "name": "simulate_eve_capacitor_siege"
  }
}

Input Schema

NameRequiredDescriptionDefault
node_idYesTarget Lagrange Network Node identifier under siege simulation.
siege_intensityNoHostile fleet DPS and electronic-warfare drain tier; defaults to 'heavy_cruiser_wing' when omitted.

Output Schema

NameRequiredDescriptionDefault
node_idYesSimulated Lagrange Network Node identifier.
defense_verdictYesSiege readiness assessment ('HOLDS_UNTIL_REINFORCEMENT' or 'SHED_SSU_LOAD_IMMEDIATELY').
load_shedding_sequenceYesOrdered list of non-essential assemblies to power down first.
capacitor_survival_minutesYesMinutes before capacitor reserves drop below turret firing threshold.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.6.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: statelessness, a 32 KB payload ceiling, a 60 RPM rate limit, a ?demo=true preview path, an L402 payment of 30 sats, and an HTTP 400 failure mode for invalid input. These are exactly the operational facts an agent needs before calling a metered edge endpoint.

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

Conciseness4/5

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

Front-loaded with purpose, then alternatives, then operational constraints; no filler sentences. The third sentence is dense to the point of being a comma-spliced list of transport details, but every clause carries 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?

An output schema exists, so return values need not be described, and the description covers payment, rate limits, demo mode, and error signaling. The one completeness defect is the default-value error, which leaves the agent less certain about the schema than if the description had said nothing at all.

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

Parameters2/5

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

Schema coverage is 100%, so the baseline would be 3, but the description actively conflicts with the schema: it says siege_intensity 'defaults to skirmish_frigate_squad' while the schema property description states the default is 'heavy_cruiser_wing'. An agent that trusts the prose will omit the parameter expecting the wrong tier and get a materially wrong simulation. The node_id mention merely restates the schema.

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

Purpose5/5

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

States a specific verb (simulates/computes), a specific resource (Lagrange Network Node GJ capacitor drain), and the derived output (optimal assembly load-shedding order). It also explicitly distinguishes itself from the nearest sibling, optimize_eve_node_power, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives both sides of the routing decision: use this when preparing base defense power-shedding schedules against an incoming hostile fleet, and use optimize_eve_node_power for routine peacetime fuel burn and reserve headroom. The trigger condition (hostile siege) and the exclusion (peacetime) are both explicit.

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

Deploy Server

Other Tools