Skip to main content
Glama
Sign In
mapsql-mcp

mapsql-mcp

by mveyseldelibas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

sample_features

Preview a spatial layer by returning a few sample features and optional geometry, so you can inspect real data before writing queries or rendering maps.

Instructions

Return a few example features of a layer (random for small tables) to see real data.

Input Schema

NameRequiredDescriptionDefault
nNoHow many features (1-50).
layerYes
geometryNo'auto' (default): full geometry if small, else representative points; 'full'; 'centroid'; 'none' (attributes only). The complete geometry is always kept server-side under result_id for render_map.auto

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior4/5

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

Since there are no annotations, the description carries a heavy burden and performs well by disclosing behavioral traits beyond simple CRUD operations. Specifically, it explains that the sampling is random and that the results are intended for data inspection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is extremely concise and efficient, using a single sentence to convey the tool's function, its scope (a few features), and a key behavioral constraint (random for small tables).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The definition provides sufficient context for a sampling tool, clearly defining its role as a data preview. While it lacks information on the response format or specific error handling, this is forgivable given the tool's function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is quite descriptive, covering the meaning of parameters like 'n' and 'geometry.' The description itself adds almost no semantic meaning to the parameters, failing to add value beyond what is already structured in the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The tool clearly states its purpose is to return 'example features of a layer to see real data,' which identifies it as a preview or sampling tool. While not explicitly comparing it to every sibling (like describe_layer), its focus on a small subset makes its function distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers a brief usage guideline by noting that sampling is 'random for small tables.' However, it fails to provide clear guidance on when to use this tool versus a full retrieval tool like find_features, leaving the boundaries of its scope to inference.

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

Deploy Server

Other Tools