GeoServer MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. The tools cover different operations like creation (create_layer, create_style, create_workspace), deletion (delete_resource), retrieval (get_layer_info, list_layers, list_workspaces), querying (query_features), and visualization (generate_map). There is no overlap in functionality.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, using snake_case. All tools start with a clear action verb (create, delete, generate, get, list, query) followed by a specific noun, making them predictable and readable.
Tool Count5/5
With 9 tools, this server is well-scoped for managing a GeoServer instance. It covers essential operations for workspaces, layers, styles, and maps without being overly complex or too sparse, making it efficient for agents to handle geospatial data tasks.
Completeness4/5
The tool set provides comprehensive coverage for core GeoServer operations, including CRUD for layers, styles, and workspaces, along with querying and map generation. A minor gap exists in updating resources (e.g., update_layer or update_style), but agents can work around this by deleting and recreating.
Average 3.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on December 13, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

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. While 'Create' implies a write operation, it doesn't address permission requirements, whether the operation is idempotent, what happens if a layer already exists, rate limits, or error conditions. The return format is mentioned but lacks detail about what 'status and layer information' includes.
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 well-structured with clear sections (Args, Returns) and uses minimal sentences. Each sentence serves a purpose, though the parameter explanations could be more informative. The front-loaded purpose statement is effective.
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 write operation with 4 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes valid inputs, error handling, or the structure of returned information. The context signals indicate this is a complex tool that needs more comprehensive documentation.
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 lists all four parameters with brief explanations, but the schema has 0% description coverage. The parameter explanations ('The workspace for the new layer', 'The name of the layer to create', etc.) add basic semantic context beyond just parameter names, though they don't provide format requirements, examples, or constraints.
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 ('Create') and resource ('new layer in GeoServer'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling alternatives like 'create_workspace' or 'create_style' beyond the resource type.
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_workspace' or 'list_layers'. There's no mention of prerequisites, dependencies, or typical scenarios where layer 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 the full burden of behavioral disclosure. It states this is a creation operation, implying mutation, but doesn't address critical aspects like required permissions, whether the workspace name must be unique, what happens if it already exists, rate limits, or the format of the return dict. This leaves significant gaps for an 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured clearly, though the return description ('Dict with status and result information') is somewhat vague. No sentences are wasted, but 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 tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It doesn't explain the return value in detail, error conditions, or behavioral nuances like idempotency. For a tool that creates resources, this leaves the agent with insufficient context to use it effectively.
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 minimal semantics beyond the input schema. It names the single parameter ('workspace') and states it's the 'Name of the workspace to create', which slightly clarifies the schema's 'Workspace' title. However, with 0% schema description coverage, this doesn't fully compensate—it lacks details like naming constraints, character limits, or examples. The baseline is 3 since the schema covers the parameter structure, but the description provides only basic clarification.
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 ('Create a new workspace') and resource ('in GeoServer'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_workspaces' or 'delete_resource' beyond the obvious verb difference.
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. The description doesn't mention prerequisites (e.g., authentication needs), when not to use it, or how it relates to sibling tools like 'list_workspaces' for checking existing workspaces before 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?
No annotations are provided, so the description carries full burden. It discloses the destructive nature ('Delete'), but lacks critical behavioral details: it doesn't specify if deletion is permanent, what permissions are required, potential side effects (e.g., cascading deletions), rate limits, or error handling. For a destructive 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured breakdown of args and returns. Every sentence earns its place by adding necessary information, though the 'Returns' section could be more detailed given no output schema.
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 (destructive operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It covers basic purpose and parameters but misses critical context: behavioral traits (e.g., irreversibility), usage guidelines, and detailed return values. For a deletion tool, this leaves the agent under-informed.
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 0%, so the description must compensate. It adds value by explaining each parameter's purpose (e.g., 'resource_type: Type of resource to delete (workspace, layer, style, etc.)'), which clarifies beyond the schema's bare titles. However, it doesn't provide examples, constraints (e.g., valid resource_type values), or format details, leaving some ambiguity.
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 ('Delete') and target ('a resource from GeoServer'), providing a specific verb+resource combination. It distinguishes from siblings like create_layer, create_style, etc., which are creation operations rather than deletions. However, it doesn't explicitly differentiate from potential other deletion tools (none listed in 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., resource must exist), exclusions (e.g., cannot delete if in use), or comparisons to other tools like list_layers for verification. It only states what it does, not when to apply it.
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. While 'Get detailed information' implies a read-only operation, the description doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what specific metadata is returned beyond 'Dict with layer metadata'.
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 well-structured with clear sections for Args and Returns, and the core purpose is stated upfront. It's appropriately sized for a simple lookup tool, though the 'Returns' section could be more informative given the lack of output schema.
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?
For a simple read operation with 2 parameters and no annotations, the description is adequate but has clear gaps. It explains what the tool does and documents parameters, but doesn't provide enough behavioral context or output details. With no output schema, the vague 'Dict with layer metadata' return description is insufficient for understanding what information will be available.
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 explicitly lists both parameters ('workspace' and 'layer') with brief explanations, which adds value beyond the schema's 0% description coverage. However, it doesn't provide format details, examples, or constraints for these parameters, so it only partially compensates for the schema's lack of descriptions.
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 ('Get detailed information') and resource ('about a layer'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_layers' or 'query_features' which might also provide layer information, so it doesn't reach the highest 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?
No guidance is provided about when to use this tool versus alternatives. With siblings like 'list_layers' and 'query_features' that might overlap in functionality, the description offers no context about when this specific tool is appropriate versus those other options.
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 mentions that the tool returns 'Dict with map information and URL', which hints at output format, but lacks details on authentication needs, rate limits, error conditions, or whether it's a read-only operation. For a tool that generates images (potentially resource-intensive), 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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bullet-point list of parameters with brief explanations, and ends with return information. Every sentence earns its place, with no redundant or verbose content.
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 complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers parameter semantics effectively but lacks behavioral context (e.g., performance implications, error handling). Without an output schema, the return statement ('Dict with map information and URL') is vague, leaving the agent uncertain about the exact response structure.
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 description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose (e.g., 'layers: List of layers to include (format: workspace:layer)', 'bbox: Bounding box [minx, miny, maxx, maxy]'), including format hints and optionality. This compensates well for the schema's lack of descriptions, though it doesn't cover all nuances like default values or null handling.
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: 'Generate a map image using WMS GetMap.' It specifies the verb ('generate') and resource ('map image'), and mentions the underlying protocol (WMS GetMap). However, it doesn't explicitly differentiate from sibling tools like 'query_features' or 'get_layer_info', which might also involve map-related 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. It doesn't mention sibling tools like 'query_features' (which might retrieve specific data) or 'get_layer_info' (which might provide metadata), leaving the agent to infer usage context. There are no explicit when/when-not instructions or named alternatives.
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 states the action but doesn't describe what 'available' means (e.g., filtered by permissions), the return format, pagination, or error conditions. This is inadequate for a tool with zero 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, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core purpose, making it easy for an agent to parse quickly.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks completeness. It doesn't explain what 'available' entails or provide behavioral context, which could help the agent use it correctly despite the low complexity.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly doesn't mention any, earning a baseline 4 for 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 verb ('List') and resource ('available workspaces in GeoServer'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'list_layers' or 'create_workspace', which would require a 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. It doesn't mention prerequisites, context (e.g., before creating layers), or exclusions, leaving the agent to infer usage from the tool name alone.
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 mentions the return format (GeoJSON FeatureCollection) and that parameters are optional, but lacks details on permissions, rate limits, error handling, or whether this is a read-only operation. For a query 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 well-structured and concise, with a clear purpose statement followed by bullet-pointed Args and Returns sections. Every sentence adds value, and there's no redundant information. It's appropriately sized for the tool's complexity.
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 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers the purpose, parameters, and return format, but lacks behavioral context (e.g., read/write nature, error cases) and usage guidelines. For a query tool with moderate complexity, this is adequate but has clear gaps.
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 description lists all 5 parameters with brief explanations (e.g., 'Optional CQL filter expression'), adding meaning beyond the schema, which has 0% description coverage. It clarifies optionality and purposes, though it doesn't provide examples or detailed constraints. Since schema coverage is low, the description compensates well, but not fully.
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: 'Query features from a vector layer using CQL filter.' It specifies the action (query), resource (features from a vector layer), and method (CQL filter). However, it doesn't explicitly differentiate from sibling tools like 'list_layers' or 'get_layer_info', which reduces it from 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. It doesn't mention sibling tools like 'list_layers' (for listing layers) or 'get_layer_info' (for layer metadata), nor does it specify use cases or prerequisites. This leaves the agent without contextual usage 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 the full burden. It mentions the tool lists layers and returns information dictionaries, but lacks details on permissions required, pagination behavior, rate limits, error conditions, or what fields the dictionaries contain. 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 front-loaded with the core purpose, followed by clear Arg and Returns sections in a structured format. Every sentence earns its place with no redundant information, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema description coverage, and no output schema, the description is moderately complete. It covers the purpose and parameter semantics adequately but lacks behavioral details like permissions or error handling. For a simple read operation, this is acceptable but not thorough.
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 0%, so the description must compensate. It documents the single parameter 'workspace' as optional for filtering, adding meaning beyond the schema's basic type and title. However, it doesn't explain the format of workspace names or provide examples, leaving some ambiguity.
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 'List' and resource 'layers in GeoServer', with optional workspace filtering. It distinguishes the tool from siblings like 'get_layer_info' (detailed info) and 'list_workspaces' (different resource). However, it doesn't explicitly contrast with 'query_features' (data querying vs metadata listing).
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?
The description implies usage for listing layers, optionally filtered by workspace, but doesn't explicitly state when to use this versus alternatives like 'get_layer_info' (for detailed info on a specific layer) or 'query_features' (for querying layer data). No guidance on prerequisites or exclusions is provided.
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. While it states this is a creation operation, it doesn't mention permissions required, whether the style becomes immediately available, what happens on duplicate names, or any rate limits. The return format is mentioned but lacks detail about what 'status and style information' includes.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value, though the Returns section could be more specific about what information is included. The structure helps with quick scanning.
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?
For a creation tool with 3 parameters, no annotations, and no output schema, the description provides adequate basics but lacks important context. It covers the purpose and parameters reasonably well but misses behavioral details like error conditions, authentication requirements, and specific return format that would be needed for reliable tool invocation.
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?
With 0% schema description coverage, the description compensates well by explaining all three parameters: 'name' for the style name, 'sld' for XML content, and 'workspace' as optional. It clarifies that workspace is optional and provides context about what each parameter represents, though it doesn't specify format constraints for the SLD XML.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new SLD style'), resource ('in GeoServer'), and technology context ('SLD style'). It distinguishes from siblings like create_layer or create_workspace by specifying it creates a style rather than other GeoServer resources.
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. While it's clear this creates styles, there's no mention of when to create a style versus using existing ones, or how this relates to sibling tools like create_layer or generate_map that might involve styling.
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:

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

Score Badge

Copy to your README.md:

[![geoserver-mcp MCP server](https://glama.ai/mcp/servers/mahdin75/geoserver-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mahdin75/geoserver-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/mahdin75/geoserver-mcp'

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