Loading ToolBench
MCP server providing an interface to PostgreSQL with PostGIS
Server has 4 well-defined tools with clear names, mostly complete parameter schemas, and descriptions that are above-average in length (179-267 chars). All tools use action verbs (query, list, describe, fieldmeaning). Parameter schemas are explicit with types and descriptions. However, output schemas are not documented in the tool definitions, and there is no error handling guidance for LLMs. The server lacks security-sensitive details (no permission declarations, no audit logging hints). Overall: solid definition quality with documentation gaps typical of domain-specific data tools.
Describe the columns of a database table. Returns column names, data types, nullability, defaults, and spatial metadata for geometry columns. Args: table_name: Name of the table to describe.
Get field meanings (column comments) for a database table. Returns each column's name, data type, ordinal position, and description (from schema comments). Only bare table names are accepted (no schema qualifier). Args: table_name: Bare table name (no schema qualifier like 'public.tablename').
List all available tables in the database. Returns table names, schemas, and estimated row counts. Only tables in the allowed list are returned.
Execute a SQL SELECT query against the database. Only SELECT queries are permitted. Results are truncated at row_limit. Args: sql: SQL SELECT statement to execute. row_limit: Maximum number of rows to return (default 1000). output_format: Response format. "text" (default) returns tabular data with columns, rows, and row_count — best for textual answers. "geojson" returns a GeoJSON FeatureCollection (RFC 7946) where each row becomes a Feature with geometry from the 'geom' column and all other columns as properties. GeoJSON is recommended for drawing vector objects graphically in UI (e.g. Leaflet maps). The query must include a column named 'geom' for GeoJSON output.
Output schemas are not documented. Tools return dict[str, object] or list[dict[str, object]] with no specification of field names, types, or structure. LLMs cannot reason about downstream tool usage or data extraction.
Error handling guidance is completely absent. No descriptions tell the LLM what to do if a query fails, a table is not found, or a geometry column is missing. Recovery paths are implicit.
query tool accepts sql parameter as unconstrained string. No description warns about SQL injection risk, sanitization expectations, or that only SELECT is allowed (though the description mentions this). No validation hints for LLM awareness of constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
query tool output_format parameter uses string enum but does not declare enum constraint in schema. Schema shows only type:string with description. JSON Schema should include enum: ['text', 'geojson'] for machine-parseability.
list_tables and describe_table descriptions lack specifics about what fields are returned. 'Returns table names, schemas, and estimated row counts' is vague on structure. What is 'schemas'? Is it a string, object, array?
fieldmeaning description states 'Only bare table names are accepted' but does not explain what happens if a schema-qualified name is passed (e.g., 'public.tablename'). Error guidance missing.
No permission declarations (e.g., 'read:database', 'execute:select'). Agents cannot reason about least-privilege scoping or audit what permissions these tools require.