Skip to main content
Glama

faction_submit_intel

Submit system intel to your faction's shared map (Submit intel in the same JSON format as game responses. Systems support description and enriched connections (objects with system_id, name, distance — or bare string IDs for backward compatibility). POIs support description, class, position, base_name, and deep_core (true for a hidden deep core POI, where the mining too-sparse cutoff never applies — the auto-sync sets it for you). Resources accept the optional max_remaining capacity (as shown by get_poi); query responses echo it back along with a remaining_display ("depleted" or "N units") and depletion_percent so a deposit at remaining 0 reads as depleted, not unknown. The server stores exactly what you submit — no accuracy validation, only schema validation. Every entry is tagged with your name and the game tick so faction members know who to trust. Does not require docking. Requires a faction_intel facility at any base.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
systemsYesArray of system intel reports. Each entry: system_id (required), name (required), description, empire, police_level, connections (array of {system_id, name, distance} objects or bare ID strings), pois (array of {id, type, name, description, class, position:{x,y}, base_id, base_name, deep_core, resources:[{resource_id, richness, remaining, max_remaining}]}). deep_core marks a hidden deep core POI, where the mining too-sparse cutoff never applies
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • changedInput schema / properties / systems / description
      Previous value: -"Array of system intel reports. Each entry: system_id (required), name (required), description, empire, police_level, connections (array of {system_id, name, distance} objects or bare ID strings), pois (array of {id, type, name, description, class, position:{x,y}, base_id, base_name, resources:[{resource_id, richness, remaining, max_remaining}]})"New value: +"Array of system intel reports. Each entry: system_id (required), name (required), description, empire, police_level, connections (array of {system_id, name, distance} objects or bare ID strings), pois (array of {id, type, name, description, class, position:{x,y}, base_id, base_name, deep_core, resources:[{resource_id, richness, remaining, max_remaining}]}). deep_core marks a hidden deep core POI, where the mining too-sparse cutoff never applies"
  4. Changed1 schema field changed
    • changedInput schema / properties / systems / description
      Previous value: -"Array of system intel reports. Each entry: system_id (required), name (required), description, empire, police_level, connections (array of {system_id, name, distance} objects or bare ID strings), pois (array of {id, type, name, description, class, position:{x,y}, base_id, base_name, resources:[{resource_id, richness, remaining}]})"New value: +"Array of system intel reports. Each entry: system_id (required), name (required), description, empire, police_level, connections (array of {system_id, name, distance} objects or bare ID strings), pois (array of {id, type, name, description, class, position:{x,y}, base_id, base_name, resources:[{resource_id, richness, remaining, max_remaining}]})"
  5. Changed1 schema field changed
    • changedInput schema / properties / systems / description
      Previous value: -"Array of system intel reports in the same format as game responses"New value: +"Array of system intel reports. Each entry: system_id (required), name (required), description, empire, police_level, connections (array of {system_id, name, distance} objects or bare ID strings), pois (array of {id, type, name, description, class, position:{x,y}, base_id, base_name, resources:[{resource_id, richness, remaining}]})"
  6. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With only readOnlyHint=false in annotations, the description carries the behavioral burden and does so thoroughly. It discloses that the server stores exactly what is submitted with no accuracy validation, tags entries with the player name and tick, auto-sets deep_core, and clarifies the facility requirement.

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?

The description is long but front-loaded with the purpose and then organized by payload component: systems, POIs, resources, then server behavior and requirements. Nearly every sentence adds necessary information for a complex payload, though the first parenthetical is grammatically awkward and the overall text is dense.

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 complex submission tool with no output schema, the description covers the input format, required facility, lack of validation, tagging behavior, and special resource semantics well. It is missing an explicit statement of the submit response or merge/overwrite behavior, but an agent has enough to construct a valid call.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: the payload must match game-response JSON, connections accept enriched objects or bare IDs, deep_core has special mining-cutoff behavior, and resources support max_remaining with echo fields like remaining_display and depletion_percent. This goes well beyond a bare schema but doesn't exhaustively restate every schema field.

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-resource-destination pairing: 'Submit system intel to your faction's shared map.' It clearly differentiates this from trade-intel tools by scoping the payload to system intel, systems, POIs, and resources, so an agent can distinguish it from sibling tools like faction_submit_trade_intel.

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 gives clear context for when to use the tool: submitting intel to the faction map, with explicit preconditions that docking is not required but a faction_intel facility is required. It does not explicitly call out the alternative faction_submit_trade_intel or state 'when not to use,' 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources