PostGIS MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific PostGIS operations like geometry creation, analysis, spatial queries, and database management. There is no overlap; for example, 'create-point' and 'create-puffer' serve different functions, and descriptions help differentiate even similar-sounding tools like 'geometry-info' and 'get-table-info'.
Naming Consistency5/5
Tool names follow a consistent verb-noun pattern with hyphens throughout, such as 'create-point', 'calculate-distance', and 'validate-geometry'. This predictable naming scheme makes it easy for agents to understand and select tools without confusion or mixed conventions.
Tool Count4/5
With 22 tools, the count is slightly high but reasonable for a comprehensive PostGIS server covering geometry operations, spatial analysis, raster data, and database utilities. It might feel heavy, but each tool appears to earn its place in the domain without being excessive.
Completeness5/5
The tool set provides complete coverage for PostGIS operations, including CRUD-like functions (e.g., create, analyze, validate), spatial calculations (e.g., distance, intersection), database management (e.g., test-connection, get-table-info), and advanced features like natural language querying. No obvious gaps are present for the domain.
Average 2.7/5 across 22 of 22 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('create spatial index') without any information about side effects (e.g., whether it modifies database schema, requires write permissions, or affects performance), error conditions, or what happens on success/failure. For a tool that likely performs a database mutation, this lack of transparency is critical and inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that is under-specified rather than concise. While it's brief, it fails to convey essential information that would help an agent use the tool effectively. Conciseness should not come at the cost of clarity, and this description lacks the necessary detail to be considered well-structured or helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a spatial index (likely a database mutation), the absence of annotations, and no output schema, the description is severely incomplete. It doesn't explain what a spatial index is, why one would create it, what the tool returns, or any behavioral traits. For a tool with 2 parameters and no structured safety hints, this minimal description leaves too many gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. However, schema description coverage is 100%, with clear descriptions for both parameters ('geometry_column' and 'table_name'), including a default value for 'geometry_column'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't need to compensate but also doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mekansal indeks oluştur' (Turkish for 'Create spatial index') is a tautology that essentially restates the tool name without adding meaningful context. It doesn't specify what resource it acts upon (e.g., database table), what a spatial index is, or how it differs from sibling tools like 'analyze-database' or 'get-table-info'. The purpose is minimally stated but lacks differentiation and specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing tables with geometry columns), use cases (e.g., performance optimization for spatial queries), or exclusions. Given sibling tools like 'analyze-database' and 'get-table-info', there's no indication of how this tool fits into the workflow, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does at a high level ('transform coordinate system') without revealing any behavioral traits: it doesn't mention whether this is a read-only operation, what happens to invalid inputs, whether it requires specific permissions, what the output format is, or any performance considerations. For a tool with 3 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words in Turkish), but this is under-specification rather than effective brevity. It doesn't front-load critical information or provide any structured explanation. While technically short, it fails to convey necessary context, making it inefficient rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (coordinate transformation with 3 required parameters), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how errors are handled, or any behavioral nuances. The description should provide more context about the transformation process and expected outcomes to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters clearly documented in the input schema (geometry_wkt, source_srid, target_srid). The description adds no additional parameter information beyond what the schema provides. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Koordinat sistemini dönüştür' (Transform coordinate system) is a tautology that essentially restates the tool name 'transform-coordinates' in Turkish. It doesn't specify what exactly gets transformed (geometries), how the transformation occurs, or what distinguishes it from sibling tools like 'calculate-distance' or 'geometry-intersection' that also work with spatial data. The purpose is stated but lacks specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for spatial operations (e.g., 'create-point', 'geometry-intersection', 'calculate-distance'), but the description doesn't indicate this is specifically for coordinate system transformations rather than other geometric manipulations. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('create buffer') but doesn't disclose behavioral traits such as whether this is a read-only or mutating operation, what the output looks like (e.g., a new geometry object), error conditions, or performance considerations. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 a single, efficient sentence in Turkish ('Geometri etrafında buffer oluştur'), which is appropriately sized and front-loaded with the core action. It wastes no words, though it could benefit from slightly more detail to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (geometric operation with 2 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'buffer' is, the output type (e.g., a polygon), or how it integrates with other tools. For a creation tool in a spatial context, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('distance_meters' and 'geometry_wkt'). The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions, units beyond meters, or WKT format specifics. Baseline score of 3 is appropriate since the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Geometri etrafında buffer oluştur' (Create buffer around geometry) states a clear verb ('oluştur' - create) and resource ('buffer'), but it's vague about what a 'buffer' is in this context and doesn't differentiate from siblings like 'create-polygon' or 'geometry-convex-hull' that might create similar geometric outputs. The purpose is understandable but lacks specificity about the output type or geometric operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain if this is for creating protective zones, proximity analysis, or how it differs from 'create-polygon' or other geometry-creation tools in the sibling list. The description implies usage for buffers around geometries but offers no context about appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions finding features around a point but doesn't disclose what types of features, how results are returned (e.g., list, count, geometry), whether there are rate limits, authentication needs, or error conditions. This leaves significant gaps for a tool with 5 parameters.
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 a single, efficient sentence in Turkish that directly states the tool's function. It's appropriately concise without unnecessary words, though it could be more informative given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a spatial query tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'features' are, how results are structured, or provide context about the spatial database environment. This leaves too many unknowns for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for all 5 parameters. The description adds no additional parameter semantics beyond implying a spatial search around coordinates. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate with any extra context like valid table_name examples or distance unit clarifications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Belirli bir noktanın çevresindeki özellikleri bul' (Find features around a specific point) states a clear verb+resource action but is vague about what 'features' means. It doesn't specify whether these are geographic features, database records, or spatial objects, nor does it differentiate from siblings like 'spatial-join' or 'smart-query' which might perform similar spatial operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'spatial-join', 'calculate-distance', and 'smart-query' that might handle proximity or spatial queries, there's no indication of this tool's specific use case, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does (calculates convex hull) but doesn't disclose behavioral traits like computational complexity, what happens with invalid input, whether it modifies the original geometry, or what the output format is. For a computational geometry tool with no annotation coverage, this is insufficient.
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 a single, efficient sentence that directly states the tool's purpose. However, it's in Turkish rather than English, which could be problematic for English-trained agents, slightly reducing its effectiveness despite the concise form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a computational geometry tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a convex hull is, what the output looks like, edge cases, or performance characteristics. Given the complexity of geometric operations and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'geometry_wkt' well-described as 'WKT formatında geometri' (geometry in WKT format). The description doesn't add any parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Geometrinin konveks zarfını hesapla' (Calculate the convex hull of geometry) states a clear verb ('hesapla' - calculate) and resource ('geometrinin konveks zarfı' - convex hull of geometry), but it's in Turkish which may reduce clarity for English-speaking agents. It doesn't distinguish from siblings like 'geometry-centroid' or 'geometry-union' beyond the specific operation name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is provided. The description doesn't mention prerequisites, when this operation is appropriate, or what distinguishes it from other geometry operations in the sibling list like 'geometry-union' or 'geometry-intersection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it indicates this is a read operation (getting information), it doesn't specify what 'detailed information' includes beyond the examples in parentheses, whether there are any limitations or constraints, what format the information returns in, or any error conditions. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.
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 a single, efficient sentence that states the core purpose. The parenthetical examples (area, length, dimensions, etc.) add useful context without verbosity. While it could be more specific, every element serves a purpose and there's no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' actually includes beyond a few examples, doesn't specify the return format, and provides no context about limitations or error conditions. Given the complexity of geometric operations and the lack of structured documentation elsewhere, the description should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'geometry_wkt' clearly documented as 'WKT formatında geometri' (geometry in WKT format). The description doesn't add any meaningful parameter information beyond what's already in the schema - it mentions geometry generally but doesn't clarify WKT format requirements or constraints. With high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'get detailed information about geometry (area, length, dimensions, etc.)', which is clear but vague. It specifies the resource (geometry) and general type of information returned, but doesn't distinguish it from sibling tools like 'geometry-centroid' or 'raster-info' that also provide geometric information. The description is functional but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that also work with geometry (geometry-centroid, geometry-convex-hull, geometry-intersection, etc.), there's no indication of when this general 'info' tool is appropriate versus more specific geometric operations. The description only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action (merge) but doesn't disclose behavioral traits like whether it modifies inputs, handles errors, requires specific geometry types, or returns a new geometry. For a mutation tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence in Turkish. However, the language mismatch with the English tool name might reduce clarity, and it could be more front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a geometry processing tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the union operation entails, what happens with invalid inputs, or the format of the result. Given the complexity and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'geometries_wkt' well-documented as an array of WKT-formatted geometries. The description doesn't add meaning beyond the schema, but the baseline is 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Birden fazla geometriyi birleştir' (Merge multiple geometries) clearly states the action (merge/unify) and resource (geometries), but it's in Turkish while the tool name is in English, which may cause confusion. It doesn't distinguish from siblings like 'geometry-intersection' or 'geometry-convex-hull' that also operate on multiple geometries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'geometry-intersection' (which finds overlaps) or 'geometry-convex-hull' (which creates an envelope). The description implies usage for merging geometries but doesn't specify contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it 'gets detailed information' without specifying what that includes (e.g., schema, row count, permissions), whether it's a read-only operation, potential errors (e.g., if the table doesn't exist), or response format. For a tool with no annotation coverage, this leaves critical behavioral traits undocumented.
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 a single, efficient sentence in Turkish that directly states the tool's function. It's appropriately sized for a simple tool with one parameter, with no wasted words. However, it could be slightly more front-loaded by specifying the type of information (e.g., metadata) to improve clarity immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'detailed information' includes, which is crucial since there's no output schema to define the return values. For a tool that likely returns structured data (e.g., table schema, statistics), this gap makes it inadequate for an agent to understand the full context of use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'table_name' documented as 'Tablo adı' (Table name). The description adds no additional meaning beyond this, such as format constraints or examples. Since the schema fully describes the parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Belirli bir tablo hakkında detaylı bilgi al' (Get detailed information about a specific table) states a clear verb ('al' - get) and resource ('tablo' - table), but it's vague about what 'detailed information' entails. It doesn't distinguish this tool from potential siblings like 'geometry-info' or 'raster-info' that might provide similar metadata for other resource types. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., connection to a database), exclusions, or how it differs from sibling tools like 'analyze-database' or 'smart-query'. The agent must infer usage from the tool name and context alone, which is insufficient for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('get information') without describing what the output includes (e.g., metadata, statistics, format), whether it's a read-only operation, or any limitations (e.g., performance, data size). This leaves significant gaps for a tool with no annotation coverage.
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 a single, efficient sentence in Turkish that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'information' is returned (e.g., raster dimensions, metadata, statistics), which is critical for understanding the tool's utility. For a data retrieval tool with no structured output documentation, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('raster_column' and 'table_name'). The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between these parameters or usage examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Raster verisinin bilgilerini al' (Get raster data information) states a clear verb ('get') and resource ('raster data information'), but it's vague about what specific information is retrieved. It doesn't differentiate from sibling tools like 'geometry-info' or 'get-table-info', which also retrieve information about different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for raster data analysis, or how it differs from other info-retrieval tools in the sibling list (e.g., 'geometry-info' for geometry data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action ('check validity') without detailing what 'validity' entails (e.g., topological correctness, coordinate constraints), potential side effects, error handling, or output format. This leaves significant gaps in understanding the tool's behavior beyond the basic purpose.
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 a single, efficient sentence in Turkish that directly states the purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details if expanded for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a validation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what constitutes validity, how results are returned, or error cases, making it inadequate for an agent to fully understand the tool's context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'geometry_wkt' clearly documented as 'WKT formatında geometri' (geometry in WKT format). The description adds no additional meaning beyond this, such as examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Geometrinin geçerliliğini kontrol et' (Check the validity of geometry) states a clear verb ('check validity') and resource ('geometry'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'geometry-info' or 'simplify-geometry' that might also involve geometry validation aspects, making it somewhat vague in distinguishing its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., before other operations), or exclusions, leaving the agent to infer usage based on the name alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions a 'spatial join operation' but doesn't disclose behavioral traits like whether it modifies data, requires specific permissions, has rate limits, returns geometry columns, or handles large datasets. For a tool with 6 parameters and no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence in Turkish ('İki tablo arasında mekansal join işlemi yap'), which is appropriately concise. However, it lacks front-loading of critical details (e.g., purpose in English, key constraints) and could be more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 6 parameters, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral context. For a spatial operation tool with complexity, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning about parameters beyond implying two tables are involved. Baseline 3 is appropriate when the schema does the heavy lifting.
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 description clearly states the tool performs a 'spatial join operation between two tables' (verb+resource), which is specific and understandable. However, it doesn't differentiate from sibling tools like 'geometry-intersection' or 'find-nearby' that might have overlapping spatial functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many spatial siblings (e.g., 'geometry-intersection', 'find-nearby'), there's no indication of when this spatial join is preferred or what specific problems it solves compared to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing and collecting information, which implies a read-only operation, but fails to detail aspects like performance impact, caching behavior (hinted by the 'force_refresh' parameter), error conditions, or output format. For a tool with no annotation coverage, this is a significant gap in transparency.
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 description is a single, efficient sentence in Turkish that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database analysis and the lack of annotations and output schema, the description is incomplete. It does not explain what 'analyze' entails, what information is collected, the format of the results, or how it differs from similar tools like 'get-table-info.' This leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'force_refresh' documented as 'Önbelleği yenileyip yeniden analiz et' (refresh cache and re-analyze). The description does not add any meaning beyond this, as it doesn't mention parameters at all. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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 description clearly states the tool's purpose: 'Veritabanı şemasını analiz et ve tablo bilgilerini topla' translates to 'Analyze the database schema and collect table information.' This specifies the verb (analyze/collect) and resource (database schema/table information). However, it doesn't explicitly distinguish this tool from its sibling 'get-table-info,' which appears to serve a similar purpose, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or comparisons to sibling tools like 'get-table-info' or 'smart-query,' which might overlap in functionality. This lack of usage direction leaves the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does (calculates distance) without mentioning any behavioral traits: e.g., what units the distance is returned in (e.g., meters, kilometers), whether it's a straight-line or geodesic calculation, performance characteristics, error handling, or how the 'use_geography' parameter affects results. This leaves significant gaps for an AI agent to understand the tool's behavior.
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 description is a single, clear sentence in Turkish: 'İki nokta arasındaki mesafeyi hesapla' (Calculate the distance between two points). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward tool. Every part of the sentence earns its place by directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a spatial calculation tool with 5 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover critical context: what the output looks like (e.g., numeric distance, units), how 'use_geography' influences results, error cases (e.g., invalid coordinates), or relationships to sibling tools. For a tool with no structured behavioral data, this minimal description leaves too many unknowns for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter names and descriptions (e.g., 'Birinci nokta enlem' for point1_lat). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain coordinate formats (e.g., decimal degrees), range constraints, or the practical effect of 'use_geography'. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 description clearly states the tool's purpose: 'calculate the distance between two points' (İki nokta arasındaki mesafeyi hesapla). It specifies the verb (calculate) and resource (distance between two points), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'find-nearby' or 'geometry-info', which might also involve distance calculations in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'find-nearby' (which might find points within a distance) or 'transform-coordinates' (which might be needed before distance calculation). There's no context about prerequisites, such as coordinate systems, or when to use the optional 'use_geography' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates geometry but doesn't mention whether this is a read-only operation, if it modifies data, what permissions are required, or what happens to the created geometry. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 description is a single, efficient sentence in Turkish that directly states the tool's purpose. There's no wasted words or unnecessary elaboration - it's appropriately concise for what it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a geometry creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens to the created point geometry, whether it's stored or returned, or how it integrates with other spatial operations. Given the complexity of spatial tools and the lack of structured metadata, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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 description clearly states the action ('oluştur' - create) and resource ('nokta geometrisi' - point geometry) from coordinates. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'create-linestring' or 'create-polygon' which create other geometry types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'create-linestring' or 'create-polygon' for creating other geometry types, nor does it provide context about when point geometry creation is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose whether this is a read or write operation, what permissions might be required, whether the polygon persists somewhere, what happens with invalid coordinates, or any error conditions. For a geometry creation tool with zero annotation coverage, this is insufficient.
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 description is a single, efficient sentence in Turkish that directly states the tool's purpose without any wasted words. It's appropriately sized for a straightforward geometry creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a geometry creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after polygon creation, whether the result is stored or returned, what format the output takes, or any behavioral aspects. Given the complexity of spatial operations and the lack of structured metadata, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description could have explained coordinate format expectations or SRID implications.
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 description clearly states the action ('oluştur' - create) and the resource ('poligon geometrisi' - polygon geometry) from a coordinate array. It distinguishes from siblings like 'create-point' or 'create-linestring' by specifying polygon creation, though it doesn't explicitly contrast with other geometry creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'create-buffer' or 'create-linestring'. The description only states what the tool does, not when it's appropriate or what prerequisites might be needed for polygon creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'extract' implies a read operation, it doesn't specify whether this requires specific permissions, what happens with invalid coordinates, whether there are rate limits, or what format the extracted value returns. For a tool with 4 parameters and no annotation coverage, this is insufficient behavioral context.
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 description is a single, efficient sentence in Turkish that directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward extraction tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what type of value gets returned (numeric, categorical, error handling), coordinate system assumptions, or how it relates to the sibling raster-info tool. The minimal description leaves too many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'specific coordinates' which aligns with latitude/longitude parameters, but doesn't add meaningful context beyond what the 100% schema coverage already provides. The schema descriptions clearly document each parameter's purpose, so the description doesn't compensate with additional semantic value about coordinate systems, raster formats, or table relationships.
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 description clearly states the action ('extract') and target ('raster value at specific coordinates'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'raster-info' or explain what makes this extraction tool unique versus other raster or spatial analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'raster-info' and various geometry analysis tools available, there's no indication of whether this is for point sampling, what types of raster data it works with, or when to choose it over other spatial query methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds a centroid but does not describe the return format (e.g., coordinates, WKT), error handling (e.g., for invalid geometries), or performance considerations. This is a significant gap for a tool with no annotation coverage.
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 description is a single, clear sentence in Turkish: 'Geometrinin merkez noktasını bul' (Find the center point of geometry). It is front-loaded with the core purpose, with no unnecessary words or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of geometric operations and the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., a point geometry, coordinates), how it handles edge cases (e.g., multi-geometries), or any limitations. This leaves gaps for an AI agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'geometry_wkt' documented as 'WKT formatında geometri' (geometry in WKT format). The description does not add any additional meaning beyond this, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
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 description clearly states the tool's purpose: 'Geometrinin merkez noktasını bul' (Find the center point of geometry). It specifies both the verb ('find') and the resource ('center point of geometry'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'geometry-info' or 'geometry-convex-hull', which might also provide geometric properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'geometry-info' (which might include centroid information) or 'create-point' (for creating points manually), nor does it specify prerequisites or exclusions. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the operation but doesn't disclose behavioral traits like whether it returns a geometry or boolean, error conditions for invalid inputs, performance characteristics, or what coordinate system is assumed. The description is minimal and lacks operational context.
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 description is a single, efficient sentence in Turkish that directly states the tool's function. There's zero waste or unnecessary elaboration, making it perfectly concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a geometry operation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the intersection returns (geometry, boolean, error), coordinate system handling, or edge cases. Given the complexity of spatial operations and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented as WKT geometries. The description doesn't add any parameter semantics beyond what the schema already provides (e.g., doesn't explain WKT format requirements or valid geometry types). Baseline 3 is appropriate when schema does the heavy lifting.
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 description clearly states the tool's purpose as 'finding the intersection of two geometries' (specific verb+resource). It doesn't explicitly differentiate from sibling tools like 'geometry-union' or 'spatial-join', but the core function is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'geometry-union' or 'spatial-join'. The description only states what it does, not when it's appropriate or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the algorithm but does not disclose behavioral traits such as performance implications, error handling, or output format. For a geometry processing tool with no annotations, this is a significant gap in transparency.
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 a single, efficient sentence in Turkish that directly states the action and algorithm. It is appropriately sized and front-loaded with the core purpose, though it could be more structured with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that performs geometry simplification (a non-trivial operation), the description is incomplete. It lacks information on what the tool returns, error conditions, or typical use cases, making it inadequate for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, such as explaining how tolerance affects simplification or what 'preserve_collapsed' entails. Baseline 3 is appropriate when schema does the heavy lifting.
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 description clearly states the verb ('simplify') and resource ('geometry'), and specifies the algorithm used (Douglas-Peucker). However, it does not differentiate from sibling tools like 'validate-geometry' or 'geometry-convex-hull' that also process geometries. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention use cases, prerequisites, or exclusions. Without annotations or context, it's unclear if this is for preprocessing, visualization, or other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the core function (understanding and translating natural language to queries) but lacks details on how it handles ambiguous questions, error conditions, performance characteristics (e.g., response time), or output format. For a tool with no annotations, this is a significant gap in transparency.
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 description is a single, clear sentence in Turkish that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core functionality, making it easy to understand quickly. Every part of the sentence earns its place by defining the action and input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of natural language processing and database query translation, the description is incomplete. It lacks details on output (no output schema provided), error handling, or behavioral traits, and with no annotations, it fails to provide sufficient context for effective use. This is inadequate for a tool that likely involves nuanced processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('language' and 'question') with descriptions and enum values. The description adds minimal value beyond the schema by implying the 'question' parameter is in natural language, but does not provide additional context such as supported question types or limitations. Baseline 3 is appropriate as the schema does the heavy lifting.
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 description clearly states the tool's purpose: 'Doğal dilde sorulan soruyu anla ve uygun veritabanı sorgusuna çevir' (Understand a question asked in natural language and translate it to an appropriate database query). This specifies the verb (understand and translate) and resource (natural language question to database query), but does not distinguish it from sibling tools like 'analyze-database' or 'get-table-info', which might involve database interactions but are not explicitly about natural language translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts for usage, such as when to prefer this over direct query tools or other analysis tools in the sibling list. This leaves the agent without clear direction on application scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates geometry but doesn't disclose behavioral traits like whether this is a read-only or mutating operation, what happens on invalid inputs, error handling, or performance characteristics. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 description is a single, efficient sentence in Turkish that directly states the tool's purpose without any fluff. It is appropriately sized and front-loaded, with every word contributing to understanding the tool's function. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (creating geometry from coordinates), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output. For a creation tool in a spatial context, more information would be helpful, but it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (coordinates and srid). The description adds no additional meaning beyond what the schema provides—it mentions 'Koordinat dizisinden' (from coordinate array) which is already covered by the schema's description. Baseline 3 is appropriate when the schema does the heavy lifting.
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 description clearly states the action ('oluştur' - create) and resource ('çizgi geometrisi' - line geometry) from a coordinate array. It distinguishes from siblings like create-point and create-polygon by specifying line geometry, though it doesn't explicitly contrast with them. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create-point or create-polygon. It mentions the input (coordinate array) but gives no context about appropriate use cases, prerequisites, or exclusions. Usage is implied only through the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('test et') but doesn't describe what the test entails (e.g., connectivity check, authentication, version verification), what happens on success/failure, or any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 description is a single, efficient sentence in Turkish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and lack of annotations, the description is minimally complete. It states what the tool does but lacks details about behavior, output format, or error conditions. For a diagnostic tool, more context about what constitutes a successful test would be helpful, but the core purpose is clear.
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?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate for a parameterless tool where the schema fully documents the input structure.
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 description clearly states the tool's purpose as testing a PostGIS database connection with a specific verb ('test et') and resource ('PostGIS veritabanı bağlantısı'). It distinguishes from siblings by focusing on connection validation rather than spatial operations or data manipulation. However, it doesn't explicitly differentiate from potential alternative connection-testing tools (though none are listed among siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., before performing spatial operations), exclusions, or contextual triggers. The agent must infer usage from the purpose alone without explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![postgis-mcp MCP server](https://glama.ai/mcp/servers/receptopalak/postgis-mcp/badges/card.svg)](https://glama.ai/mcp/servers/receptopalak/postgis-mcp)

Score Badge

Copy to your README.md:

[![postgis-mcp MCP server](https://glama.ai/mcp/servers/receptopalak/postgis-mcp/badges/score.svg)](https://glama.ai/mcp/servers/receptopalak/postgis-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/receptopalak/postgis-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server