Skip to main content
Glama

subscribe_observation

Read-onlyIdempotent

Subscribe to live presence updates for the players at your POI, plus ship_counts for the other POIs with a ship scanner (Change-feed alternative to polling get_nearby. Anchors a watch at your current POI: the response is a full baseline snapshot (the uncloaked players at your POI exactly as get_nearby lists them, with offline_collapsed; the pirates/empire_npcs/creatures, intact prizes and arena_npcs at your POI that get_nearby returns; the unknown_signature hint; and, with a working ship scanner, ship_counts: the get_system ship_count of every charted POI in your system), and thereafter you receive observation_update messages only when that presence changes — players arriving, leaving, going online/offline, or changing ship/faction/combat state; offline_collapsed when the count of unlisted offline players changes; the full ship_counts map when a count changes or the scanner resumes, and an empty ship_counts object when the last working scanner is lost (replace cached counts; omission means unchanged); pirates/empire NPCs/creatures arriving, leaving, or changing (hull, status, combat) via pirates_changed/pirates_departed, empire_npcs_changed/empire_npcs_departed, creatures_changed/creatures_departed; intact prizes arriving, leaving, or changing via prizes_changed/prizes_departed; and arena challenge enemies joining or changing (hull, shield, status, flees) via arena_npcs_changed, with arena_npcs_departed carrying enemies removed when their match ends. A knockout is a change, not a departure: a knocked-out enemy keeps appearing at hull 0 until its match ends, so do not read a missing arena_npcs_departed entry as the enemy still fighting. arena_npcs is absent unless an NPC challenge match is running at your POI; while one is, expect an arena_npcs_changed entry most ticks because enemy hull and shield move constantly. Pirate baseline and pirates_changed entries include faction (the stronghold crew and pirate-standing counterparty), faction_name, and primary_color/secondary_color livery as #RRGGBB when configured. Avoids re-fetching the full list every tick. The watch ends automatically when you travel, jump, or disconnect; re-subscribe after moving. Cloaked players are hidden, same visibility rules as get_nearby. Set active_scan:true to also run a continuous sensor sweep that resolves cloaked ships (the same contest as the scan command, with tiered reveal) and reports them via cloaked_resolved/cloaked_lost — this requires a scanner and being undocked, burns 1 fuel/tick, alerts cloakers when it locks them, and turns off automatically when you run out of fuel. It replaces looping the scan command to hunt cloaked traffic. Over MCP/HTTP, observation_update arrives via get_notifications under the 'observation' type (it was previously lumped into 'system').)

Input Schema

NameRequiredDescriptionDefault
session_idYesYour session ID from login/register
active_scanNoAlso run a continuous active sensor sweep that resolves cloaked ships (requires a scanner, must be undocked, burns 1 fuel/tick, alerts cloakers). Omit or false for the passive presence feed only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover readOnlyHint/idempotentHint, but the description adds the full lifecycle: baseline snapshot semantics, change-only delivery, automatic termination on travel/jump/disconnect, active_scan cost (1 fuel/tick), prerequisites (scanner, undocked), side effect (alerts cloakers), auto-shutoff on fuel exhaustion, and the MCP delivery channel (get_notifications, 'observation' type). This is far beyond what annotations provide.

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

Conciseness3/5

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

The purpose is front-loaded well, but the body is a single ~500-word paragraph enumerating every message type (pirates_changed/pirates_departed/empire_npcs_changed/...), which is hard to scan and largely belongs in reference docs. Most sentences are operationally relevant given there is no output schema, which keeps this above a 2, but the lack of structure costs it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 carries the full burden of explaining what arrives and when, and it does so for the baseline snapshot, each update category, the arena knockout edge case, and the notification channel. Nothing an agent needs to call or consume this tool correctly is missing.

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% and both parameters are documented there, so baseline is 3. The description still adds real meaning for active_scan beyond the schema: it is the 'same contest as the scan command, with tiered reveal', reports via cloaked_resolved/cloaked_lost, and requires a scanner and undocked state.

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 opening clause states a specific verb and resource ('Subscribe to live presence updates for the players at your POI'), then immediately names the sibling it replaces by framing itself as the 'Change-feed alternative to polling get_nearby'. An agent can distinguish it from get_nearby, scan, and unsubscribe_observation without opening any 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?

Explicitly gives the alternative patterns it supersedes ('Avoids re-fetching the full list every tick', 'It replaces looping the scan command to hunt cloaked traffic') and the conditions that end the subscription ('The watch ends automatically when you travel, jump, or disconnect; re-subscribe after moving'). It also states activation prerequisites for active_scan, so the agent knows when each mode is viable.

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