gisgp

bundle_create_export_schedule

PAID PER DELIVERY (30 credits each time it fires, NOT at creation — free to create/cancel) — the only MCP tool that exposes GISGP's core recurring-export product to agents: creates a schedule that re-exports a FeatureServer layer on its own and POSTs the file straight to your own webhook_url, no email/web UI account needed beyond the API key. Reuses the same scheduler that runs the paid web app's scheduled exports (fires within ~5 min of the due time).

format: "csv", "geojson", "shapefile", "kml", or "excel".
frequency: "hourly" (top of each hour), "daily" (at run_hour UTC), "weekly"
(at run_hour UTC on `weekday`, 0=Monday..6=Sunday), or "monthly" (at run_hour
UTC on `monthday`, 1-28).
webhook_url: must be a public, reachable HTTPS URL (validated at creation AND
at every delivery) — GISGP POSTs a JSON body {schedule_id, format, row_count,
filename, delivered_at, data_base64 (or download_url for files >5MB)}.

If the wallet lacks 30 credits when a delivery is due, that cycle is silently
skipped (schedule stays active, no error surfaced to you) — top up any time at
https://gisgp.com/billing/mcp-credits/topup?utm_source=mcp and the next cycle delivers normally.
Use estimate_cost or check_wallet_balance to plan ahead. Delete via
cancel_export_schedule when no longer needed — an abandoned schedule with an
empty wallet just skips forever, but does not charge or error.

Requires Authorization: Bearer <api_key>. Returns JSON: {ok, schedule_id,
next_run_at}.

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": {
      "service_url": "<service_url>",
      "format": "<format>",
      "webhook_url": "<webhook_url>"
    },
    "name": "bundle_create_export_schedule"
  }
}

Input Schema

Name	Required	Default
`token`	No
`where`	No	1=1
`format`	Yes
`weekday`	No
`monthday`	No
`run_hour`	No
`frequency`	No	daily
`service_url`	Yes
`webhook_url`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: 30-credit-per-delivery billing timing, silent skip on empty wallet (schedule stays active, no error), webhook validated at creation and every delivery, ~5 min firing window, auth header requirement, and response shape. This is exactly the non-obvious behavior an agent needs.

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?

The critical billing warning is front-loaded before any parameter detail, which is the right ordering. It is longer than typical but nearly every sentence carries operational value; the only slack is the billing-topup URL and the redundant restatement of the empty-wallet skip behavior.

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?

For a complex, 9-parameter mutation tool with no annotations, the description covers cost model, scheduling semantics, delivery payload, failure mode, auth, and lifecycle. Output schema exists, yet it still summarizes the return, leaving nothing an agent needs before calling it.

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 0%, so the description must compensate, and it does for the important params: format enum values, frequency enum with top-of-hour/UTC run_hour semantics, weekday 0=Monday..6=Sunday, monthday 1-28, and webhook_url HTTPS validation. It omits meaning for service_url, where, and token, which remain undocumented.

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?

States a specific verb and resource — creates a recurring schedule that re-exports a FeatureServer layer and POSTs the file to a webhook — and explicitly positions it as the only MCP tool for recurring exports, distinguishing it from one-off export and cancel siblings. An agent can tell exactly what it does without opening the schema.

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?

Names the alternative tools (estimate_cost, check_wallet_balance to plan, cancel_export_schedule to tear down) and describes the recurring-export context that selects this tool. It does not explicitly contrast against bundle_export_fixed / bundle_export_multi_format for one-off exports, leaving that inference to the agent.

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.