Skip to main content
Glama
Sign In
QGIS MCP

QGIS MCP

by lefcgis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Plugin Info

get_plugin_info
Read-only

Retrieve detailed information about a QGIS plugin, including its name, version, author, description, enabled status, and file path.

Instructions

Get detailed info for a specific plugin: name, enabled, version, description, author, path.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plugin_name": "<plugin_name>"
    },
    "name": "get_plugin_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
plugin_nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations provide readOnlyHint=true, so the agent knows it's read-only. The description adds the list of returned fields but does not disclose error behavior or any side effects. This is adequate given the annotations cover the safety profile.

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 sentence that efficiently states the purpose and lists output fields. No redundant information, but it could be slightly more structured (e.g., list fields in a bullet).

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 (one param, output schema exists), the description is mostly complete. It misses input format details but covers output fields. For a straightforward info tool, this is minimally viable but could include error handling notes.

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 unresourced parameter. However, the description only mentions 'for a specific plugin' without clarifying how to specify plugin_name (e.g., exact name vs. display name) or its format. This is insufficient for precise tool invocation.

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 tool returns detailed info for a specific plugin, listing specific fields (name, enabled, version, etc.). This differentiates it from sibling tools like list_plugins (which returns a list) and reload_plugin (which reloads).

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 when you need details of one plugin, but it does not explicitly state when to use it versus alternatives (e.g., list_plugins for all plugins). No when-not or prerequisite guidance is provided.

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

Deploy Server

Other Tools