Skip to main content
Glama
Sign In
pyside-iconify-mcp

pyside-iconify-mcp

by LingChen-tsjmdlc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check Code

check_code
Read-onlyIdempotent

Statically validate pyside-iconify Python code before running to catch unknown imports, invalid/misplaced parameters, bad icon names, invalid property values, and conflicting options.

Instructions

Check the pyside-iconify usage in a piece of Python code without running it. Finds unknown imports, unknown or misplaced parameters (for example hover_color on get_icon), invalid values (size, color, opacity, rotate, animation), conflicting options, malformed or non-existent icon names, and multi-color or animated icons used in ways that do not work. 'ok' is true when there are no errors. Only values written literally in the code are checked; anything else is listed under 'skipped' instead of being guessed. Run it on finished code and fix every error.

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": {
      "code": "<code>"
    },
    "name": "check_code"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesPython source code to check (up to 200000 characters).
verify_icon_namesNoLook up icon names online to confirm they exist and to check color and animation use. Set false to check offline.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, but the description adds behavior those hints cannot convey: analysis is static ('without running it'), only literal values are verified rather than guessed, and non-literal cases surface under 'skipped' instead of being silently ignored. It also flags the success indicator ('ok' is true when there are no errors), which is meaningful because a partial static analysis could otherwise be mistaken for a full pass.

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?

Purpose is front-loaded in the first sentence and the remaining sentences cover detection scope, limits, and the recommended workflow, so nothing is buried. The long inline enumeration of error categories is dense but each item is a distinct failure mode an agent would otherwise not anticipate. Minor tightening is possible but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a static analyzer with an output schema, so the description need not explain return values, and it correctly spends its words on detection scope, static-analysis limits, and the 'skipped' bucket. Combined with annotations and 100% schema coverage, an agent has everything needed to invoke it correctly and interpret a partial result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both 'code' (including the 200000 character bound) and 'verify_icon_names' (online lookup vs offline) fully documented in the schema. The description adds only indirectly, via the statement that literal values are checked, which clarifies the depth of the analysis but not either parameter's syntax. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Check the pyside-iconify usage in a piece of Python code without running it', followed by an enumerated taxonomy of what it detects (unknown imports, misplaced parameters, invalid values, malformed icon names). That is far more concrete than a restated name. It never names or contrasts its siblings, though, so an agent choosing between check_code and check_icons gets no explicit disambiguation from the description itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Run it on finished code and fix every error' gives a clear usage context and implies it should not be run on work-in-progress. The limitation that only literal values are checked, with everything else listed under 'skipped', further tells the agent what to expect. No alternative tool is named for the cases this one does not cover, which keeps it below a 5.

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