Skip to main content
Glama
Infection Free Zone MCP

Infection Free Zone MCP

by tianq021

get_threats

Lists hostile groups with distance and direction to HQ and player squads, flags movement toward the settlement, and includes hidden groups by default.

Instructions

List hostile groups with distance/direction to HQ and to player squads, plus whether they are moving toward the settlement. Hidden groups are included by default.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_threats"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows returned (default 12)
max_distanceNoDistance filter from HQ (default 1200)
include_hiddenNoInclude groups the player has not discovered (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description must carry behavior, and it does disclose the safety-relevant quirk that undiscovered groups are surfaced by default plus the spatial attributes returned. It omits whether this is read-only (implied by 'List'), any permission or rate constraints, units/ordering of results, and how 'moving toward the settlement' is computed.

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?

Two tight sentences, front-loaded with the payload contents before the default-behavior note. The final clause about hidden groups partially duplicates the schema default, which is minor redundancy rather than waste.

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?

For a three-param read tool with no annotations and no output schema, the description usefully enumerates what comes back, but leaves gaps an agent cannot fill elsewhere: distance units, direction encoding, result ordering, and what counts as 'the settlement' or 'HQ'. Adequate but not complete.

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 limit, max_distance, and include_hidden are already documented with ranges and defaults; a 3 baseline applies. The description's only parameter-adjacent claim, that hidden groups are included by default, merely restates the schema default for include_hidden and adds no new format or semantics.

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 opens with a specific verb+resource ('List hostile groups') and enumerates the returned attributes (distance/direction to HQ and squads, movement toward settlement), so an agent knows exactly what the payload contains. It does not name a sibling to differentiate from (e.g., get_enemy_report or get_enemy_density), which keeps it 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?

There is no explicit when-to-use statement, no exclusion, and no alternative named despite many sibling threat tools (get_enemy_report, get_enemy_density, get_enemy_lairs, get_enemy_moves). Usage is only inferable from the word 'threats' and the distance framing.

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