QGISMCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as add_raster_layer vs add_vector_layer, but some overlap exists: get_layers retrieves all layers, while get_layer_features retrieves features from a specific vector layer, which could cause confusion if an agent needs general layer info. However, descriptions clarify their differences, preventing major misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as add_raster_layer, execute_code, and get_project_info. There are no deviations in naming conventions, making the set predictable and easy to parse for agents.
Tool Count5/5
With 15 tools, this server is well-scoped for QGIS operations, covering project management, layer handling, rendering, and code execution. Each tool serves a clear purpose without redundancy, fitting the typical range of 3-15 tools for a focused domain.
Completeness4/5
The tool set provides comprehensive coverage for core QGIS workflows, including project CRUD (create, load, save), layer management (add, remove, zoom), and information retrieval. A minor gap is the lack of tools for editing layer attributes or geometries, but agents can work around this using execute_code or execute_processing for advanced operations.
Average 2.8/5 across 15 of 15 tools scored. Lowest: 2.1/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
This repository is licensed under Creative Commons Zero v1.0 Universal.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new project a save it,' which implies a write operation but lacks details on permissions, whether it overwrites existing files, error handling, or output format. For a mutation tool with zero annotation coverage, this is insufficient to inform safe and effective use.
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 brief ('Create a new project a save it'), which is concise but suffers from a grammatical error ('a save it' likely intended as 'and save it'). It front-loads the core action but lacks structure, such as separating creation and saving aspects. While not verbose, the error reduces 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 tool's complexity (a mutation operation with 1 parameter), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral traits, parameter details, or output expectations, making it inadequate for effective tool selection and invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('path') with 0% description coverage, and the tool description provides no information about parameters. It doesn't explain what 'path' represents (e.g., file path, directory), expected format, or constraints. With low schema coverage, the description fails to compensate, leaving the parameter's meaning unclear.
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 'Create a new project a save it' restates the tool name ('create_new_project') with minor elaboration, making it tautological. It specifies the action ('create') and resource ('project') but lacks clarity on what 'a save it' means—likely a typo for 'and save it'—which doesn't differentiate it from sibling tools like 'save_project' or 'load_project'.
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. It doesn't mention prerequisites, such as needing a valid path, or differentiate from sibling tools like 'save_project' (which might update existing projects) or 'load_project' (which opens existing ones). The description implies creation and saving, but without explicit usage context.
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 but offers minimal insight. 'Get QGIS information' implies a read-only operation, but it doesn't specify what information is returned (e.g., structured data, status messages), whether it requires specific permissions, or if there are any side effects like caching or logging. The description is too vague to adequately inform agent behavior beyond a basic read intent.
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 extremely concise ('Get QGIS information'), which could be efficient if it were more informative. However, it's under-specified rather than appropriately concise—it lacks the specificity needed to be truly helpful. While it's front-loaded (the entire description is in three words), it fails to earn its place by adding sufficient value beyond the tool name.
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 QGIS (a geographic information system with multiple components), the description is incomplete. With no annotations, no output schema, and a vague purpose, it doesn't provide enough context for an agent to understand what information is retrieved or how to interpret results. Sibling tools suggest this might return system-level info, but the description doesn't confirm this or explain the return format.
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, and the input schema has 100% description coverage (though empty). The description doesn't need to compensate for any parameter documentation gaps. A baseline score of 4 is appropriate since there are no parameters to explain, and the description doesn't introduce unnecessary complexity about inputs.
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 'Get QGIS information' is a tautology that essentially restates the tool name without adding meaningful specificity. It doesn't clarify what type of QGIS information is retrieved (e.g., version, configuration, available plugins, system status) or distinguish this from sibling tools like 'get_project_info' or 'get_layers' that also retrieve information about QGIS components.
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. Given sibling tools like 'get_project_info' (for project details) and 'get_layers' (for layer information), there's no indication whether this tool is for general system information, configuration details, or something else, nor any prerequisites or context for its use.
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 executes a processing algorithm but doesn't reveal if this is read-only, destructive, requires specific permissions, has rate limits, or what the output might be. For a tool with zero annotation coverage and potential side effects, 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 with no wasted words, making it appropriately sized. However, it's under-specified rather than concise, as it lacks necessary details for clarity, slightly reducing its effectiveness.
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 (2 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't cover behavioral traits, parameter details, or output expectations, leaving the agent with insufficient information to use the tool effectively in context with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'algorithm' and 'parameters' but adds minimal meaning beyond the input schema, which has 0% description coverage. It doesn't explain what an 'algorithm' refers to (e.g., QGIS processing tool), the structure of 'parameters,' or provide examples, failing to compensate for the schema's lack of documentation.
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 'Execute[s] a processing algorithm with the given parameters,' which provides a basic verb+resource (execute + processing algorithm). However, it's vague about what 'processing algorithm' entails and doesn't distinguish it from siblings like 'execute_code' or 'render_map,' which might involve similar processing concepts.
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. It doesn't mention prerequisites, context (e.g., after loading a project), or exclusions, leaving the agent to guess based on sibling names like 'execute_code' or 'render_map' 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Add') but doesn't explain what happens during addition (e.g., whether it modifies the project state, requires specific permissions, or has side effects like overwriting existing layers). This leaves critical behavioral traits unaddressed.
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 and front-loaded, clearly stating the tool's purpose without unnecessary elaboration, earning its place as concise and well-structured.
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 adding a layer (a mutation operation), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or usage context, making it inadequate for informed tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, failing to explain the meaning of 'path', 'provider', or 'name' beyond what the schema titles imply. This adds no value over the schema, leaving parameters semantically unclear.
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 'Add a vector layer to the project' clearly states the verb ('Add') and resource ('vector layer'), but it's vague about what a 'vector layer' entails and doesn't distinguish it from sibling tools like 'add_raster_layer' or 'load_project'. It provides a basic purpose 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?
No guidance is provided on when to use this tool versus alternatives such as 'add_raster_layer' for raster data or 'load_project' for loading existing layers. The description implies usage for adding vector layers but offers no context on prerequisites, timing, 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 mentions 'retrieve' and an 'optional limit', but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, error conditions, or what 'features' entail (e.g., geometry, attributes). For a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('retrieve features') and includes the key constraint ('optional limit'). There is no wasted verbiage, making it appropriately sized and easy to parse.
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 (retrieving features from a vector layer), lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain what 'features' include, potential side effects, or return format, leaving significant gaps for the agent to understand the tool's full 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 description adds minimal meaning beyond the input schema: it implies 'layer_id' identifies the vector layer and 'limit' controls the number of features retrieved. However, with 0% schema description coverage, the schema provides no details on parameter semantics. The description compensates slightly but doesn't fully address the gap, such as explaining what 'layer_id' format is expected or how 'limit' interacts with pagination.
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 verb 'retrieve' and resource 'features from a vector layer', which clarifies the basic action. However, it doesn't distinguish this from sibling tools like 'get_layers' or 'get_project_info', leaving ambiguity about what specifically makes this tool unique. The purpose is clear but lacks sibling differentiation.
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 'get_layers' (which might list layers) and 'zoom_to_layer' (which might focus on a layer), there's no indication of context, prerequisites, or exclusions for 'get_layer_features'. This leaves the agent without 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Add' implies a mutation operation but doesn't disclose any behavioral traits: no information on permissions required, whether the addition is reversible, side effects on the project, error conditions, or response format. For a mutation tool with zero 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, direct sentence with zero waste: 'Add a raster layer to the project.' It's front-loaded and efficiently conveys the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action and target, making it maximally concise and well-structured.
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 (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what a raster layer is, how parameters interact, what happens upon addition, or potential errors. For a tool that modifies project state, this minimal description leaves critical gaps in understanding for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning beyond the schema: no explanation of what 'path', 'provider', or 'name' represent, their formats, or typical values. With 3 parameters (1 required) and no parameter information in the description, it fails to provide necessary context, scoring low due to inadequate compensation.
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 ('Add') and resource ('a raster layer to the project'), making the purpose immediately understandable. It distinguishes from sibling 'add_vector_layer' by specifying 'raster' rather than 'vector', providing basic differentiation. However, it doesn't specify what a raster layer is or how it differs functionally from vector layers, keeping 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 like 'add_vector_layer' or 'load_project'. It doesn't mention prerequisites (e.g., needing an open project) or typical use cases, leaving the agent to infer usage from context alone. This lack of explicit when-to-use or alternative references results in minimal guidance.
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 tool executes code but doesn't mention critical traits like safety risks (e.g., potential for destructive operations), execution environment (e.g., sandboxed or full access), error handling, or output behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function. It is front-loaded with no unnecessary words, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
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 executing arbitrary code (a high-risk operation), lack of annotations, no output schema, and low parameter coverage, the description is insufficient. It doesn't address safety, execution context, error handling, or return values, making it incomplete for an agent to use the tool effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only mentions that the code is 'provided as a string', which adds minimal semantics beyond the schema's type. It doesn't explain what constitutes valid PyQGIS code, any constraints (e.g., length, imports), or examples, failing to adequately cover the single parameter.
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 ('execute') and the resource ('arbitrary PyQGIS code provided as a string'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'execute_processing', but the specificity of 'PyQGIS code' versus 'processing' provides some implicit 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?
The description provides no guidance on when to use this tool versus alternatives like 'execute_processing' or other code-related operations. It lacks context about prerequisites, such as needing an active project or specific permissions, and doesn't mention any exclusions or recommended scenarios for its use.
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 tool loads a project but doesn't describe what happens after loading (e.g., whether it opens the project in QGIS, replaces current project, requires specific permissions, or has side effects like memory usage). This leaves significant gaps for a mutation tool.
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 no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior (e.g., what 'load' entails operationally), parameter specifics, and expected outcomes, which are critical for a tool that likely modifies state in QGIS.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'from the specified path', which adds minimal context about the 'path' parameter but doesn't explain format (e.g., file path syntax, supported extensions like .qgs), constraints, or examples. This is inadequate for a tool with one undocumented parameter.
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 ('Load') and resource ('a QGIS project'), specifying it's from a path. It distinguishes from siblings like 'create_new_project' (creates rather than loads) and 'save_project' (saves rather than loads), but doesn't explicitly contrast with all 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., needing an existing project file), when not to use it (e.g., for creating new projects), or refer to sibling tools like 'create_new_project' for different 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?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention permissions needed, whether removal is permanent/reversible, effects on the project, error conditions, or rate limits, leaving significant gaps for a destructive operation.
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, front-loading the core action. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.
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 destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, return values, and integration with siblings, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal value. It mentions 'by its ID' which clarifies the parameter's role, but doesn't explain ID format, sourcing (e.g., from 'get_layers'), or validation, failing to adequately address the coverage gap.
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 ('Remove') and target resource ('a layer from the project'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'get_layers' or 'zoom_to_layer' beyond the obvious destructive nature, missing explicit 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 lacks context about prerequisites (e.g., needing an existing layer ID), exclusions, or comparisons to siblings like 'save_project' or 'create_new_project' for project modifications.
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 'zoom to the extent' implies a view change, it doesn't specify whether this affects the project state permanently, requires specific layer types, has side effects on other layers, or what happens if the layer doesn't exist. For a tool with zero annotation coverage, this leaves significant 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 that directly states the tool's function with zero wasted words. It's appropriately sized for a simple operation and front-loads the core action, making it easy to parse quickly.
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, output schema, and low schema description coverage, the description is incomplete. It doesn't address behavioral aspects like error handling, return values, or dependencies on other tools (e.g., needing a layer from 'add_raster_layer'). For a tool with one parameter but no structured documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameter 'layer_id'. The description only vaguely references 'a specified layer' without explaining what constitutes a valid layer ID, how to obtain one (e.g., from 'get_layers'), or format requirements. This adds minimal value beyond the schema's basic type information.
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 ('zoom to the extent') and the target resource ('specified layer'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools that might also manipulate layer views or extents, 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 sibling tools like 'get_layers', 'render_map', and 'remove_layer', there's no indication of whether zooming is for visualization, analysis, or other contexts, 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 the full burden of behavioral disclosure. It states the tool renders to an image file but doesn't disclose critical traits: whether it overwrites existing files, requires specific permissions, has performance implications (e.g., large dimensions slowing down), or what happens on failure. For a tool with 3 parameters and no annotations, 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 that front-loads the core action ('Render the current map view') and key details ('to an image file with the specified dimensions'). There is no wasted text, and it directly communicates the tool's function without redundancy.
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 rendering tool with file output), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't address what the output looks like (e.g., image format, success/failure indicators), error conditions, or dependencies on other tools (e.g., 'load_project'). For a tool that modifies files, 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 0%, so the description must compensate. It mentions 'specified dimensions,' which hints at the 'width' and 'height' parameters, and 'image file' implies the 'path' parameter for output location. However, it doesn't explain parameter meanings beyond this (e.g., path format, dimension constraints, defaults). The description adds some value but doesn't fully cover the 3 undocumented parameters.
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 with a specific verb ('Render') and resource ('current map view'), specifying the output format ('image file') and mentioning key parameters ('specified dimensions'). It distinguishes itself from siblings like 'save_project' or 'get_project_info' by focusing on visual rendering rather than project management or data retrieval.
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., needing a loaded project or active map), exclusions, or comparisons to sibling tools like 'execute_processing' for other rendering tasks. Usage is implied only by the action described, with no explicit context.
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 a read operation ('retrieve'), implying it is likely non-destructive, but does not specify aspects like authentication needs, rate limits, error handling, or what 'all layers' entails (e.g., pagination, format). This leaves significant gaps 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, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it efficient and easy to parse. Every part of the sentence contributes directly to understanding the tool's 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?
Given the complexity of retrieving 'all layers' (which could involve data formatting, scope, or limitations), no annotations, and no output schema, the description is incomplete. It does not address what is returned (e.g., list of layer names, full metadata), potential constraints, or how it integrates with sibling tools, leaving 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable here as there are no parameters to explain. A baseline of 4 is appropriate since no compensation is needed for missing param details.
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 'retrieve' and the resource 'all layers in the current project', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_layer_features' or 'get_project_info', which also retrieve project-related data, so it misses full 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?
The description provides no guidance on when to use this tool versus alternatives such as 'get_layer_features' (which might retrieve specific layer details) or 'get_project_info' (which retrieves project metadata). There is no mention of prerequisites, exclusions, or context for usage, leaving the agent to infer based on tool names 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, it doesn't specify what 'current project information' includes (e.g., metadata, settings, paths), whether it requires authentication, or how errors are handled. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying essential 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned (e.g., project name, file path, layers) or behavioral aspects like error conditions. For a tool in a complex QGIS context with siblings, more detail 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it meets the baseline of 4 for zero-parameter tools. No additional semantic context is required or provided.
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 'Get current project information' clearly states the verb ('Get') and resource ('current project information'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_qgis_info' or 'get_layers', which also retrieve information but about different 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. It doesn't mention prerequisites (e.g., whether a project must be loaded first), nor does it contrast with siblings like 'get_qgis_info' (for general QGIS info) or 'get_layers' (for layer-specific info).
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 implies a write operation ('save'), but lacks details on permissions, whether it overwrites existing files, error handling, or response format. This is inadequate for a mutation 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 that front-loads the core action and parameter behavior. There is no wasted wording, making it highly concise and well-structured for quick understanding.
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 (a mutation operation with no annotations or output schema), the description is incomplete. It lacks details on behavioral traits like overwrite behavior, error conditions, or what happens if no project is open, leaving 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'path', explaining it's optional and defaults to the current project path. With 0% schema description coverage and only one parameter, this compensates well, providing clear semantics beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('save') and resource ('current project'), specifying it saves to a given path or defaults to the current project path. It distinguishes from sibling tools like 'create_new_project' (creation) and 'load_project' (loading), but doesn't explicitly contrast with them, keeping it at a 4.
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_new_project' for new projects or 'load_project' for loading existing ones. It mentions the optional path parameter but offers no context on prerequisites, such as needing an open project, which is a significant gap.
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 is a 'simple ping command,' implying it's a read-only, non-destructive operation, but doesn't specify what 'ping' entails (e.g., network latency test, response time, success/failure output). For a 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 that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, 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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or usage context. With no annotations or output schema, the description should do more to compensate, but it only provides a basic purpose statement.
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, and the schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any gaps.
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 a connectivity check ('ping command to check server connectivity'), using specific verbs ('check') and identifying the resource ('server connectivity'). However, it doesn't differentiate from sibling tools like 'get_qgis_info' which might also provide connectivity 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for use, or compare it to sibling tools like 'get_qgis_info' that might serve similar diagnostic purposes. The agent must infer usage from the purpose alone.
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:

[![qgis_mcp_modify1 MCP server](https://glama.ai/mcp/servers/syauqi-uqi/qgis_mcp_modify1/badges/card.svg)](https://glama.ai/mcp/servers/syauqi-uqi/qgis_mcp_modify1)

Score Badge

Copy to your README.md:

[![qgis_mcp_modify1 MCP server](https://glama.ai/mcp/servers/syauqi-uqi/qgis_mcp_modify1/badges/score.svg)](https://glama.ai/mcp/servers/syauqi-uqi/qgis_mcp_modify1)

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/syauqi-uqi/qgis_mcp_modify1'

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