Skip to main content
Glama
Sign In
statica-mcp

statica-mcp

Official
by SuresoftTechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Show project STATIC status

statica_status
Read-only

Reports a project's STATIC link and analysis configuration—including bootstrap, auto-analysis, exclusions, ruleset, metrics, reports, and last analysis—without making changes.

Instructions

Show how this project relates to STATIC in one call: link state, bootstrap status, automatic-analysis switch (per project and global), scope exclusions, and the server's ruleset, metric, report-generator and last-analysis state. Changes nothing. project.linked=false is a valid answer (not connected), not a failure. Server sections carry their own 'error'; one failing does not invalidate the rest.

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": {
      "projectDir": "<projectDir>"
    },
    "name": "statica_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
localNoSkip the server queries and report local state only (faster).
projectDirYesAbsolute path of the project directory being analyzed (usually the session's working directory).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description reinforces this with 'Changes nothing' while adding genuinely non-obvious behavior: partial failures are isolated per server section and do not invalidate the rest of the response. It does not describe output format or cost/latency beyond the `local` speed hint.

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?

Front-loaded with the outcome and packed with substantive detail; the caveats about unlinked projects and per-section errors each carry real signal. The first sentence is a long comma-delimited list that is dense but still scannable, with no filler wording.

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

Completeness4/5

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

With no output schema, the description carries the burden of explaining the return shape, and it does so by enumerating the sections and defining how per-section errors behave. Minor gaps remain around response structure and whether server data is cached or fetched live, but the essential calling information is present.

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

Parameters3/5

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

Schema description coverage is 100%, so both `projectDir` and `local` are already fully documented in the schema, including the speed tradeoff of skipping server queries. The description adds no syntax, defaults, or edge cases beyond what the schema states, so the baseline of 3 applies.

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?

States a specific verb (Show) and resource (project's STATIC relationship), then enumerates the exact facets returned: link state, bootstrap status, auto-analysis switch, scope exclusions, and server ruleset/metric/report-generator/last-analysis state. The phrase 'in one call' signals it is the aggregate counterpart to the many statica_*_show siblings, so an agent can pick it apart from them without opening schemas.

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?

'in one call' implies this is the consolidated alternative to the individual show tools, and the description clarifies that unlinked projects are a normal outcome rather than an error. It gives interpretation guidance but stops short of explicitly naming the sibling tools it replaces or stating when to prefer them individually.

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