SkyFi MCP Server

check_capture_feasibility

Assess satellite capture feasibility for your area and sensor, including availability, timing, cloud cover, and a clear summary, to validate before ordering.

Instructions

Analyze feasibility for a tasking order: satellite availability, revisit window, cloud cover forecast, and a plain-language summary. You MUST call this and present its output to the user before placing any tasking order. Precondition: call this before quote_tasking_order.

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": {
      "aoi": "<aoi>",
      "sensor_type": "<sensor_type>"
    },
    "name": "check_capture_feasibility"
  }
}

Input Schema

Name	Required	Description
`aoi`	Yes	GeoJSON Polygon for the tasking area
`sensor_type`	Yes	Sensor type for tasking
`desired_date_range`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool must be called before tasking orders and that its output must be presented to the user. It also establishes sequencing with quote_tasking_order. While it doesn't explicitly state read-only status, the tool's name and role imply a non-mutating analysis, and the mandatory-call behavior is a significant disclosure.

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 two sentences, each earning its place. The first sentence delivers the core function and output summary; the second imposes the mandatory usage and precondition. There is no filler or redundancy.

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?

The description covers the tool's role, output contents, and mandatory usage, which is sufficient for a 3-parameter tool. It lacks explicit read-only disclosure and error behavior, but the sibling context and the tool's name make the non-mutating nature clear. Overall, it gives a complete operational picture for an agent.

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 schema already describes aoi and sensor_type, and the nested desired_date_range has property-level descriptions. The description adds no parameter-specific guidance beyond listing high-level analysis outputs. With moderate schema coverage (67%) and no compensating detail, the parameter semantics are adequate but not enriched.

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 states the tool's function with a specific verb ('Analyze') and resource ('feasibility for a tasking order'), and enumerates the components (satellite availability, revisit window, cloud cover forecast, plain-language summary). This distinguishes it from sibling order-related tools like quote_tasking_order and execute_tasking_order.

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?

The description provides explicit usage guidance: 'You MUST call this and present its output to the user before placing any tasking order' and identifies a specific precondition: 'call this before quote_tasking_order.' This clearly indicates when to use the tool relative to alternatives.

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