GISGP GIS Tools
Server Details
GIS tools for AI agents: 24 tools — EPSG conversion, GeoJSON ops, ArcGIS inspection.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.8/5.
Each tool has a clearly distinct purpose: service health, schema inspection, format conversions (between GeoJSON, CSV, KML, Shapefile, GPX, WKT), coordinate transformation, geometry operations, and statistics. No two tools overlap meaningfully.
Tool names follow consistent patterns: verb_noun (check_field_types, convert_coordinates) and source_to_target (csv_to_geojson, kml_to_shapefile). All lowercase with underscores, no mixed conventions.
With 25 tools, the server is slightly over the ideal 3–15 range, but the count is justified by the breadth of GIS tasks covered (format conversions, ArcGIS interactions, geometry ops). Could be split but remains manageable.
The tool set covers core GIS operations: service health, schema inspection, data querying, and conversions among major formats. Minor gaps exist (e.g., no direct GeoPackage support), but for a general-purpose GIS toolkit it is largely complete.
Available Tools
25 toolscheck_field_typesAInspect
Inspect the field schema of an ArcGIS FeatureServer layer.
Returns JSON: {layer_name, geometry_type, fields:[{name, alias, type,
length, nullable, has_domain}]} — useful before importing/mapping data.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It describes the return JSON format and implies a read-only operation ('inspect'). However, it does not mention authentication requirements beyond the token parameter or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The return format is included inline, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple inspection tool, the description covers purpose, return structure, and usage context. It lacks parameter descriptions and error handling, but the output schema described compensates partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no information about the two parameters (service_url and token). The service_url is self-explanatory from context, but the token remains undocumented in meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects the field schema of an ArcGIS FeatureServer layer, with a specific verb and resource. It does not explicitly differentiate from siblings, but the tool name and description are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint ('useful before importing/mapping data') but does not specify when not to use this tool or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_service_healthBInspect
Check whether an ArcGIS FeatureServer layer is reachable and responsive.
Returns JSON: {ok, ms (latency), name, geometry_type, field_count,
record_count, capabilities, max_record_count}.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the transparency burden. It discloses the return JSON structure but does not address whether the tool modifies data, requires authentication, or has rate limits. The verb 'Check' hints at read-only behavior, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, followed by a compact list of returned fields. Every element is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context indicates true), the description adequately documents the return value. However, it lacks details on error handling, the meaning of 'responsive', and authentication nuances. Some gaps remain for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain the parameters (service_url and token) beyond their names and types. No additional context is provided about token usage or URL format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Check whether...') and the resource ('ArcGIS FeatureServer layer'). It distinguishes from sibling tools, which are mostly data conversion and query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. Usage context is implied by the tool's name and purpose, but no when-not-to-use or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_schemasAInspect
Compare the field schemas of two ArcGIS FeatureServer layers.
Returns JSON diff: {added, removed, changed:[{field, diffs}], same,
geometry_match, identical} — useful for QA before an import or migration.
| Name | Required | Description | Default |
|---|---|---|---|
| token_a | No | ||
| token_b | No | ||
| service_url_a | Yes | ||
| service_url_b | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output format (JSON diff) and use case but lacks details on error handling, authentication needs (tokens are optional), and side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences: the first states the purpose, and the second describes the output and use case. It is front-loaded with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to cover important aspects given the tool's complexity: no parameter explanations, no authentication guidance, no error conditions, and no details about the return schema despite having an output schema. Significant gaps for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 4 parameters (token_a, token_b, service_url_a, service_url_b). It only references 'two ArcGIS FeatureServer layers' without detailing which parameters map to what.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares field schemas of two ArcGIS FeatureServer layers, with a specific verb 'compare' and resource 'field schemas'. It also explains the output format and use case, distinguishing it from sibling tools like check_field_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting it is 'useful for QA before an import or migration', indicating when to use it. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_coordinatesAInspect
Convert coordinate pairs between EPSG coordinate systems (max 1000 points).
points: [[x, y], ...] in from_epsg axis order (lon/lat for EPSG:4326).
Returns JSON: {"points": [[x, y], ...], "from_epsg": ..., "to_epsg": ...}.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | ||
| to_epsg | Yes | ||
| from_epsg | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: conversion between EPSG systems, input axis order, output JSON structure, and a point limit. It does not cover error handling or non-destructiveness, which is acceptable for a conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver the core action, input format, and output format without waste. Front-loaded with the key purpose, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and many sibling conversion tools, the description covers input, output, and limits. It could mention behavior when exceeding the 1000-point limit, but overall it is sufficiently complete for an agent to decide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for 0% schema coverage by explaining the 'points' format and axis order. It does not elaborate on valid EPSG codes or error cases for invalid inputs, but the added context is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts coordinate pairs between EPSG systems, with a max of 1000 points. This distinguishes it from sibling tools that handle larger datasets or different formats like GeoJSON or KML.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for raw coordinate pairs but does not explicitly state when not to use it (e.g., for GeoJSON use reproject_geojson). No alternative tools are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_featuresAInspect
Count features in an ArcGIS FeatureServer layer, optionally filtered by a WHERE clause.
service_url: full layer URL ending in /FeatureServer/<n>. token: only for private layers.
Returns JSON: {"ok": true, "count": ..., "name": ..., "geometry": ...}.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| where | No | 1=1 | |
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full weight. It discloses the return JSON structure (ok, count, name, geometry) and implies read-only behavior. However, it does not explicitly state no side effects or authentication details beyond token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences plus return format. Front-loaded with purpose, minimal waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema, the description covers service URL, token, filter, and return structure completely. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains service_url format, token applicability, and the where clause default (1=1). This provides complete parameter understanding beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts features in an ArcGIS FeatureServer layer with optional WHERE filtering. It distinguishes from sibling tools like query_features and query_statistics by focusing solely on count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific URL format requirements and token usage for private layers, but lacks explicit guidance on when to use this tool over alternatives or when not to use it. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
csv_to_geojsonBInspect
Convert CSV with coordinate columns (auto-detected) to a GeoJSON FeatureCollection.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It mentions 'auto-detected' coordinate columns but lacks crucial traits like error handling for missing coordinates, supported column naming conventions, or property preservation, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and key differentiator (auto-detection), with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of conversion with auto-detection, no annotations, and only partial output schema visibility, the description omits critical details about property mapping, coordinate detection behavior, and supported CSV formats, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It adds that the CSV should have coordinate columns (auto-detected), but does not specify delimiter, header requirements, or expected column names, leaving the parameter's format ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert', the resource 'CSV', and the output 'GeoJSON FeatureCollection', with the added detail of auto-detected coordinate columns, distinguishing it from sibling tools like geojson_to_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when converting a CSV with coordinate columns to GeoJSON, but it does not provide explicit guidance on when not to use it or contrast with alternatives like gpx_to_geojson or kml_to_geojson.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_domainsBInspect
Extract coded value domains from an ArcGIS FeatureServer layer.
Returns JSON: {"layer_name": ..., "domains": {field: {name, field_alias, codes}}}.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output format but does not disclose behavioral traits such as whether it requires authentication (token used), if it is read-only, or any potential errors. As a read operation, it should state that it does not modify data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no wasted words. It front-loads the purpose and immediately provides the return format. Could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema in the description, it covers core functionality. However, it lacks details on prerequisites (e.g., valid service URL), error conditions, and token usage. The description is adequate but not fully complete for robust agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description explains 'service_url' as an ArcGIS FeatureServer layer URL but does not mention 'token'. The output format is described partially, adding value beyond the schema. However, the 'token' parameter remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts coded value domains from an ArcGIS FeatureServer layer. It specifies the verb 'extract' and resource 'domains', and the output format. It distinguishes from sibling tools like 'check_field_types' or 'query_features' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With many sibling tools covering different GIS operations, such guidance would help an agent select the correct tool. The description does not mention prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geojson_to_csvAInspect
Convert a GeoJSON FeatureCollection to CSV (feature properties + geometry column).
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions output details (geometry column) but does not disclose potential limitations, error handling, or side effects. Adds some value beyond the basic conversion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is highly concise, front-loaded, and efficiently conveys the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no annotations, and an output schema present, the description adequately covers the tool's function and output format. Could mention constraints like input size but sufficient for a simple conversion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'geojson' has no schema description (0% coverage). Description does not elaborate on the parameter beyond stating it is a GeoJSON FeatureCollection, which is already implied by the tool name. No added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the conversion from GeoJSON FeatureCollection to CSV, and specifies output includes feature properties and a geometry column. This differentiates it from sibling tools like csv_to_geojson (reverse) and geojson_to_kml (different format).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting GeoJSON to CSV, but does not explicitly state when to use this tool versus alternatives or exclude scenarios. Context for decision-making is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geojson_to_kmlBInspect
Convert a GeoJSON FeatureCollection to KML.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose error handling, output specifics, coordinate system handling, or size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. Efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Very minimal description; lacks details on output schema, error handling, and conversion nuances (e.g., style, coordinate system). Insufficient for a tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter; description adds 'FeatureCollection' context to the string schema, but no format or validation details beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts GeoJSON FeatureCollection to KML, which is specific and distinguishes it from sibling tools like kml_to_geojson or geojson_to_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no constraints on input format (e.g., must be FeatureCollection vs any GeoJSON).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geojson_to_shapefileAInspect
Convert a GeoJSON FeatureCollection to a Shapefile ZIP (base64-encoded).
Returns JSON: {shapefile_zip_base64, warnings}.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behaviors. It mentions the output format (base64 ZIP) and return fields (shapefile_zip_base64, warnings) but omits potential issues like coordinate system handling, geometry type support, or file size limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of the primary action. No wasted words, though more structured detail (e.g., parameter explanation) could fit without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with an output schema, the description covers the basic intent and output format. However, it lacks details on error handling, coordinate reference systems, or performance considerations. Not fully complete for a production environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'geojson' is described only implicitly as the input GeoJSON FeatureCollection. With 0% schema coverage, the description should explicitly state expected format, validity requirements, or constraints. It adds minimal value beyond the schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert' and the specific resource 'GeoJSON FeatureCollection' to a 'Shapefile ZIP (base64-encoded)'. This effectively distinguishes it from sibling conversion tools like geojson_to_csv or geojson_to_kml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool over alternatives. The description only states the conversion action, leaving the agent to infer usage from the tool name and context. For a tool with many siblings, this is a missed opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geojson_to_wktAInspect
Convert a GeoJSON geometry (or a Feature's geometry) to a WKT string.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only states the conversion without disclosing behavior on invalid input, accepted GeoJSON types (e.g., FeatureCollection), coordinate dimension preservation, or size limits. This lack of detail diminishes transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, directly stating the purpose. It is front-loaded with the verb and resource, leaving no room for extraneous information. Every word is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter conversion tool with an output schema, the description is largely complete. It covers the core functionality. Minor gaps exist in edge cases and limitations, but overall it provides sufficient context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying that the input is a GeoJSON geometry or a Feature's geometry, which clarifies the expected format. The schema only defines 'geojson' as a string, so the description provides valuable context, though it could be more precise about exact JSON structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert', the resource 'GeoJSON geometry (or a Feature's geometry)', and the output 'WKT string'. It distinguishes from sibling tools like wkt_to_geojson (reverse) and other geojson_to_* conversions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The context is implied (when WKT output is needed), but no alternatives or exclusions are mentioned. While sibling tools exist, the description does not help the agent decide when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geometry_statsAInspect
Compute area (m²/km²), length (m/km), vertex count, centroid and bbox of GeoJSON.
Metric measurements use an equal-area projection so area/length are real metres.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses projection method (equal-area) and that measurements are real metres. However, it lacks details on error handling, limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, multiple stats) and existence of output schema, description is mostly complete. Could specify input format expectations, but overall covers core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'geojson'. Description only says 'GeoJSON' but does not elaborate on expected format, string type, or constraints, providing minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'compute' and the resource (area, length, vertex count, centroid, bbox of GeoJSON). It distinguishes from siblings like query_statistics (attribute stats) and other geometry tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives mentioned. The purpose is implied but there is no guidance on when not to use or comparison with siblings like query_statistics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gpx_to_geojsonBInspect
Convert GPX (waypoints, tracks, routes) to a GeoJSON FeatureCollection.
Returns the GeoJSON FeatureCollection as a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| gpx | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the conversion and output format, omitting details about input validation, error handling, or side effects. There is no indication of whether the tool modifies data or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines the purpose, second describes the return value. No redundant information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required param, no nested objects) and presence of an output schema, the description is mostly adequate. However, it lacks an explanation of input format expectations and error handling. It provides the core conversion intent but leaves operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'gpx' has no description in the schema (0% coverage). The tool description does not elaborate on the parameter, such as expected format (XML string, file path?) or constraints. The overall description mentions GPX content but fails to specify how to provide it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Convert), the input format (GPX), and the output (GeoJSON FeatureCollection). It explicitly mentions supported GPX elements (waypoints, tracks, routes), making it distinct from sibling tools like kml_to_geojson or csv_to_geojson.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings or when not to use it. There is no mention of prerequisites, such as needing valid GPX data, or alternatives. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gpx_to_kmlBInspect
Convert GPX (waypoints, tracks, routes) to KML.
| Name | Required | Description | Default |
|---|---|---|---|
| gpx | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the conversion purpose without any details about behavior, such as handling of unsupported elements, file size limits, or performance characteristics. The existence of an output schema does not excuse the lack of behavioral context in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose. There is no unnecessary information. While additional structure (e.g., mentioning parameter handling) could improve it, the brevity is appropriate for a simple conversion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, conversion task) and the presence of an output schema, the description provides the basic context needed for a conversion operation: input format and output format. However, it lacks details on parameter format (string representation of GPX) and does not explain how the tool handles edge cases (e.g., invalid GPX). This is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'gpx' with no description (schema coverage 0%). The description adds only that the input is GPX (which is already obvious from the tool name) and mentions the elements it contains (waypoints, tracks, routes). It does not clarify the expected format (e.g., raw XML string, file path, or URL) or any constraints on the input, which is insufficient given zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Convert), the input (GPX), and the output (KML), and specifies that it handles waypoints, tracks, and routes. This differentiates it from sibling tools like gpx_to_geojson and geojson_to_kml, which have different input/output format pairs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., gpx_to_geojson, geojson_to_kml). However, given the tool name and description, the purpose is self-evident: use it when you have GPX data and need KML output. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kml_to_geojsonAInspect
Convert KML (2.0–2.2) to a GeoJSON FeatureCollection.
Returns the GeoJSON FeatureCollection as a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| kml | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states output format but does not disclose potential limitations, error handling, or performance characteristics. Adequate for a simple conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted text, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and presence of an output schema, the description covers the essential input and output. Could mention input validation but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds the version range requirement for the 'kml' parameter, which goes beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts KML (with version range specified) to a GeoJSON FeatureCollection, which distinguishes it from sibling conversion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like geojson_to_kml. Missing context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kml_to_shapefileAInspect
Convert KML to a Shapefile ZIP (base64-encoded). Returns JSON: {shapefile_zip_base64}.
| Name | Required | Description | Default |
|---|---|---|---|
| kml | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral info: output is base64-encoded ZIP, returns JSON with a specific key. However, it lacks details on attribute preservation, coordinate system handling, file size limits, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no unnecessary words. It front-loads the key action and output format efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple conversion tool with one required parameter and a clear return format, the description covers the main functionality. However, it lacks details on the KML input format and any constraints, slightly detracting from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'kml' has no description in the schema (0% coverage). The description only says 'Convert KML', not specifying whether it expects a file path, URL, or raw KML string. This leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts KML to a Shapefile ZIP, base64-encoded. The verb 'Convert' with explicit resources (KML, Shapefile) and the output format (base64-encoded ZIP) distinguishes it from sibling tools like geojson_to_shapefile and kml_to_geojson.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use this tool vs alternatives like kml_to_geojson or shapefile_to_geojson. The usage is implied by the conversion direction, but without exclusions or context, the agent might not know when this is the best choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_featuresAInspect
Fetch actual feature records (attributes + geometry) from a FeatureServer layer.
Free preview capped at 50 records (WHERE filter + chosen fields). Returns JSON:
{returned, total, truncated, geojson, note}. Full unlimited export is a paid operation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| token | No | ||
| where | No | 1=1 | |
| out_fields | No | * | |
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses free preview cap and paid unlimited export, and specifies return JSON structure. But lacks details on read-only nature, authentication requirements for token parameter, error handling, or side effects. With no annotations, more transparency needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff, front-loaded with purpose, then constraints and return format. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (5 params, output schema exists), description covers purpose, constraints, and return structure. Missing details on error conditions or authentication, but overall adequate for a data-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Explains limit (50 free), where (filter), out_fields (chosen fields), and service_url (from FeatureServer). However, token parameter is vaguely linked to paid operation, leaving its exact role unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches actual feature records (attributes + geometry) from a FeatureServer layer, distinguishes from siblings like count_features and query_statistics by focusing on data retrieval rather than counts or statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes free preview limit (50 records) and full paid export, implying usage for preview vs. paid. However, does not explicitly guide when to use alternative tools like count_features or query_statistics instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_statisticsAInspect
Server-side aggregate stats on a numeric field of a FeatureServer layer.
No records fetched — AGOL computes sum/avg/min/max/count (also stddev/var).
Optional WHERE filter and group_by field. Returns JSON: {field, results:[...]}.
Cheap way to answer "what's the average/total of field X" without an export.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| stats | No | sum,avg,min,max,count | |
| token | No | ||
| where | No | 1=1 | |
| group_by | No | ||
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions no records fetched, AGOL computes, returns JSON, and optional filters. It does not cover authentication (token), error cases, or potential costs. The behavior is adequately but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three information-dense sentences with no fluff. Purpose, method, and cost are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, output schema exists), the description covers the essential behavior, return format, and distinguishes from siblings. Missing details on 'stats' and 'token' parameters, but overall complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It mentions field and service_url as required, and where and group_by as optional. However, it does not describe the 'stats' parameter (default list), 'token', or the format of where/group_by values. This is insufficient for all 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: server-side aggregate statistics on a numeric field of a FeatureServer layer. It lists the specific statistics computed (sum/avg/min/max/count, also stddev/var) and distinguishes from sibling tools like query_features by emphasizing no record fetching and cheap computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: for aggregate stats without exporting or fetching records. It implies cheap and fast, but does not explicitly mention when not to use or alternatives. Given the sibling tools, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reduce_precisionCInspect
Round every coordinate to N decimal places — shrinks GeoJSON payload size.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes | ||
| decimals | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose that this operation is lossy (reduces precision), whether it modifies input or returns new GeoJSON, or any behavioral traits beyond rounding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveying the core action and benefit, no unnecessary words. Could be restructured for clarity but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, it covers the main function but misses details like return format, edge cases (negative decimals), and interaction with output schema (not shown).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description hints at 'N decimal places' for the decimals parameter but doesn't explain the geojson string format or the semantics of decimals (e.g., default 6 meaning 6 decimal places).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it rounds coordinates to N decimal places and notes payload reduction, which is a specific and distinct function among siblings like simplify_geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like simplify_geometry, nor any mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reproject_geojsonAInspect
Reproject an entire GeoJSON between EPSG coordinate systems (all geometry types).
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes | ||
| to_epsg | Yes | ||
| from_epsg | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions reprojecting entire GeoJSON and all geometry types but does not disclose error handling, performance, authentication needs, or what happens with invalid EPSG codes. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence of 10 words that front-loads the main action. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required params, no schema descriptions, and no annotations, the description is too minimal. It covers the core purpose but omits details like output format (though output schema exists) and parameter semantics. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only says 'between EPSG coordinate systems,' neglecting to clarify that from_epsg and to_epsg are EPSG code integers or that geojson is a JSON string. Users lack parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reproject), the resource (entire GeoJSON), and the domain (EPSG coordinate systems). It also notes it handles all geometry types, distinguishing it from sibling tools like convert_coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternatives or when not to use it. Sibling tools like convert_coordinates exist, but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rest_exploreAInspect
List the layers and tables of an ArcGIS FeatureServer/MapServer root.
Point at a service root to enumerate its layers/tables, or at a single
layer URL to describe it. Returns JSON: {is_server, layers:[{id, name, type}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| service_url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. It mentions return JSON structure and two usage modes, but does not disclose authentication needs (token), error behavior, or network requirements. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence states core function, second gives usage variants and return format. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema provided, description covers key functionality: enumating layers/tables and describing a single layer. Lacks error handling and authentication hints, but sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description only explains service_url in context (point at root or layer), but does not describe the token parameter (default empty). Leaves agent guessing about token purpose and when to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists layers and tables of ArcGIS FeatureServer/MapServer root or describes a single layer. Verb and resource are specific, and it distinguishes from sibling tools like query_features or convert_coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use cases: point at service root to enumerate layers/tables, or at single layer URL to describe it. Does not mention when not to use or alternatives, but context signals show distinct sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shapefile_to_geojsonAInspect
Convert a Shapefile ZIP (base64-encoded .zip with .shp/.dbf/.shx[/.prj]) to a GeoJSON FeatureCollection. Reprojects to WGS84 if a .prj says otherwise.
Returns JSON: {geojson: {...}, reprojection_notice: str|null}.
| Name | Required | Description | Default |
|---|---|---|---|
| shapefile_zip_base64 | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic reprojection to WGS84 based on .prj file and specifies return format with fields. No contradictory annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loads the core purpose and follows with essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
One parameter tool with output schema explained. Covers input format, output format, special behavior (reprojection), and return structure. Complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No schema description for the parameter, but description explains it must be a base64-encoded ZIP containing .shp, .dbf, .shx, optionally .prj – adds significant meaning beyond 'string'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the conversion from Shapefile ZIP to GeoJSON FeatureCollection, specifies required file extensions, and mentions reprojection. Clearly distinguishes from sibling tools like csv_to_geojson or geojson_to_shapefile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when to use: when a base64-encoded shapefile ZIP needs conversion to GeoJSON. Does not explicitly mention when not to use, but sibling list allows inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simplify_geometryAInspect
Simplify GeoJSON geometry (Douglas–Peucker, tolerance in degrees). Lower = more detail.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes | ||
| tolerance | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the algorithm (Douglas-Peucker) and that tolerance is in degrees with 'Lower = more detail', but does not mention whether the operation is destructive, required coordinate system, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words with no superfluous text. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is mostly complete. It covers the main purpose, algorithm, and parameter semantics, though it could mention input constraints (e.g., valid GeoJSON).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It adds meaning to the tolerance parameter (unit and effect) but provides no additional semantics for the geojson parameter beyond the schema. The default value is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simplifies GeoJSON geometry using the Douglas-Peucker algorithm with tolerance in degrees. The verb 'simplify' and resource 'GeoJSON geometry' are specific, and it distinguishes from sibling tools like reduce_precision which reduces coordinate precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for geometry simplification but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_geojsonAInspect
Validate GeoJSON (RFC 7946 structure, topology, WGS84 coordinate ranges).
Returns a JSON report: {valid, errors, warnings, stats}.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the tool's behavior well: it validates structure, topology, and coordinates, and returns a JSON report with specific fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with purpose and output format. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema (indicated), the description covers the validation types and return structure adequately. Minor gap: could detail topology checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for its single parameter 'geojson'. The description does not describe the parameter beyond stating the tool validates GeoJSON, leaving the agent to infer the input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates GeoJSON against RFC 7946, topology, and WGS84 coordinate ranges. It distinguishes itself from sibling tools like convert_coordinates or reproject_geojson by focusing on validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when validation is needed but does not explicitly provide guidance on when to use versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wkt_to_geojsonAInspect
Convert a WKT geometry string to a GeoJSON geometry (e.g. from PostGIS).
| Name | Required | Description | Default |
|---|---|---|---|
| wkt | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the conversion action but omits any details about side effects, error conditions, permissions, or output format specifics. This is insufficient for a complete understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence (12 words) that conveys the core purpose without extraneous information. Every phrase is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required parameter, no nested objects, output schema exists), the description provides adequate context. It explains the input and output domains and includes a real-world example. Minor improvement would be to explicitly state that the output is a GeoJSON geometry object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'wkt' parameter. The description compensates by mentioning the input as a 'WKT geometry string', but does not elaborate on valid WKT types or format expectations. It adds partial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Convert') and resource ('WKT geometry string to GeoJSON geometry'), including a practical example ('e.g. from PostGIS'). It distinguishes itself from sibling conversion tools by specifying the exact transformation direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage context ('e.g. from PostGIS') but does not explicitly advise when to use this tool versus alternatives, such as the reverse conversion or other geometry formats. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!