Skip to main content
Glama

gisgp

by io.github.uponex

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 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}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenNo
whereNo1=1
formatYes
weekdayNo
monthdayNo
run_hourNo
frequencyNodaily
service_urlYes
webhook_urlYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: 30 credits per delivery, silent skip if wallet lacks credits, webhook_url validated at creation and delivery, and JSON return body structure. It also states the auth requirement (Authorization: Bearer <api_key>) and the scheduler's ~5 min firing window.

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 description is long but densely informative, using clear line breaks and bullet-like semicolons. Every sentence adds value, but it could be trimmed slightly by moving some billing details to an annotation if available. Overall, well-structured and front-loaded with the most critical pricing/usage caveat.

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 tool with 9 parameters, no annotations, and no enum schemas, the description covers all critical aspects: billing, scheduling behavior, webhook validation, authentication, return value, and failure modes. It also gives a direct link for topping up credits. This is complete for an agent to invoke correctly.

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 key parameters: format lists allowed values, frequency explains hourly/daily/weekly/monthly with run_hour/weekday/monthday semantics, and webhook_url describes the POSTed JSON body. However, token, where, and service_url are not explicitly described, relying on common sense from the tool context.

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 creates a schedule that re-exports a FeatureServer layer and POSTs the file to a webhook_url. It distinguishes itself from siblings like bundle_export_fixed (one-time) and cancel_export_schedule (deletion), and explicitly claims to be the only MCP tool exposing this recurring-export product.

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 explains when to use this tool (recurring exports) and names related tools: use estimate_cost or check_wallet_balance to plan ahead, and cancel_export_schedule to delete. It also notes the tool is free to create/cancel and paid per delivery, setting clear expectations for usage.

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

All gisgp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0
Disambiguation2/5

Many assess_* composite tools (datacenter, ev_charging, renewable, telecom, due_diligence) share the same building blocks of grid proximity, land cover, and terrain, making their boundaries fuzzy. assess_property_hazard_x402 also duplicates assess_property_hazard with only a payment-method difference, and bundle_* tools intentionally overlap with the free primitives they replace.

Naming Consistency3/5

There is a mix of verb_noun tools (query_features, geocode_address), noun-first geometry tools (centroids_geojson, envelope_geojson), and inconsistent _geojson suffix usage (buffer_geojson, fix_geometry, geometry_stats). The assess_* and bundle_* prefixes offer some grouping, but no single naming pattern is followed across the set.

Tool Count1/5

With 85 tools, the surface is extreme for an MCP server and far exceeds the typical well-scoped 3-15 range. Many tools are convenience bundles or variants that could be consolidated, making the count a significant usability burden.

Completeness4/5

The toolkit covers a broad range of GIS tasks: format conversions, GeoJSON analysis, FeatureServer query/inspection, geocoding, site assessment, and sharing. Minor gaps exist (e.g., no Excel-to-GeoJSON, no FeatureServer update/delete), but most missing functionality can be worked around by chaining existing tools.

Resources