gisgp

assess_airspace_obstruction_proximity

PAID (100 credits) — nearby FAA-registered vertical obstructions (towers, stacks, wind turbines) at a US point, for telecom/tower-siting due diligence (e.g. "is there anything tall already near this proposed tower site", "does a 250ft tower here need FAA notification"). Source: official FAA Digital Obstacle File (652k+ records nationwide). If proposed_height_agl_ft is given, flags the general 14 CFR Part 77 200ft AGL notification threshold — a single well-documented rule, not a full aeronautical study (lower heights near airports can also trigger notification, not checked here). Requires Authorization: Bearer <api_key> and sufficient credits balance. Returns JSON: {ok, obstacle_count, obstacles, tallest_nearby_agl_ft, likely_requires_faa_notification, note}.

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": {
      "lon": "<lon>",
      "lat": "<lat>"
    },
    "name": "assess_airspace_obstruction_proximity"
  }
}

Input Schema

Name	Required	Description	Default
`lat`	Yes
`lon`	Yes
`proposed_height_agl_ft`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavior: it costs 100 credits, requires Authorization and sufficient balance, uses a specific data source, and clearly states limitations (only the Part 77 200ft threshold, not airport-specific lower heights). It also describes the return JSON structure, making the tool's behavior highly transparent.

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?

The description is compact and information-dense, delivering cost, use case, source, threshold, limitations, auth requirements, and return format in a few sentences. Every sentence earns its place; there is no fluff or repetition.

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?

Given the tool's moderate complexity (3 params, no annotations, output schema present), the description is remarkably complete. It covers inputs (implicitly), outputs (explicitly), cost, authentication, data source, and limitations, leaving little for the agent to guess.

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 description coverage is 0%, so the description must compensate for parameter meanings. It explains proposed_height_agl_ft and its role in triggering FAA notification, but it never explicitly describes the required 'lat' and 'lon' parameters, leaving the agent to infer that 'US point' maps to these. This is a significant gap for the two required parameters.

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 clearly identifies the tool's purpose: to assess nearby FAA-registered vertical obstructions at a US point for telecom/tower-siting due diligence. It uses specific verbs and examples ('is there anything tall already near this proposed tower site'), and it distinguishes itself from sibling tools by focusing on airspace obstruction proximity with a specific source (FAA Digital Obstacle File).

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 provides clear context for when to use the tool (telecom/tower-siting due diligence) and includes a concrete example. It also states an exclusion: it only flags the 200ft AGL notification threshold and is not a full aeronautical study, nor does it check lower heights near airports. It does not explicitly name alternative tools, but the guidance is sufficient.

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

All gisgp tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.