Skip to main content
Glama
Sign In
Infection Free Zone MCP

Infection Free Zone MCP

by tianq021
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_map_buildings

Reads a paginated page of map buildings for the full map, a nearby radius, or a route corridor; supports scavenge-only filtering and offset-based paging.

Instructions

Read one page of buildings. Choose full for the whole map, nearby for a circle, or route for a corridor. Follow next_offset for another page.

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": {
      "session_id": "<session_id>"
    },
    "name": "get_map_buildings"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
scopeNo
offsetNo
pointsNoOne X/Z point for nearby, 2–32 waypoints for route. Omit for full.
radiusNoRequired for nearby and route. Omit for full.
excludeNo
session_idYesCurrent session_id from get_state
scavenge_onlyNoReturn only eligible scavenge targets as ID and position.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full load, and it does disclose one important behavior beyond the schema: results are paged and the caller should follow next_offset for more. It says nothing about cost, caps on total results, which session context is required, or what the payload looks like, so a mutation-free but potentially large read is only partially characterized.

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

Conciseness5/5

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

Three short sentences, front-loaded with the resource and immediately followed by the scope decision and the pagination follow-up. No filler, and the ordering matches the order an agent actually needs the information.

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 an 8-parameter read with no annotations and no output schema, the description covers scope and pagination but leaves the exclusion zones, page size, and the scavenge_only mode entirely to the schema. It is adequate to invoke the common case and thin for the advanced ones.

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?

The description explains the scope enum values in geometry terms (whole map / circle / corridor), which the schema only lists as bare strings, and it adds the next_offset continuation concept that has no schema field at all. However, limit, offset, exclude, and scavenge_only are undocumented in both places, matching the 50% schema coverage gap.

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?

"Read one page of buildings" gives a specific verb (read) plus resource (buildings) and signals pagination, so the agent knows exactly what data comes back. It never contrasts itself with the other building-lookup siblings, so an agent choosing between this and a name/search-based building tool still has to guess.

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

Usage Guidelines3/5

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

The description gives real guidance on *how* to call it (pick full/nearby/route depending on geometry) but no guidance on *when* to prefer it over sibling tools. Usage is implied by the resource name rather than stated as a rule or an exclusion.

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