Skip to main content
Glama
Sign In
statica-mcp

statica-mcp

Official
by SuresoftTechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Gather bootstrap evidence

statica_bootstrap_detect
Read-only

Collects build-system and toolchain clues from a project directory to guide STATIC bootstrap configuration without modifying files.

Instructions

Step 1 of connecting a project to STATIC: collect build-system clues (artifacts: C/C++; languageArtifacts: Java, Kotlin, Python, C#) and the existing toolchain detector's view. Changes nothing. Choosing the language, environment and compiler from it is your judgement; follow statica_get_guide topic=bootstrap, and ask the user when clues point to more than one environment.

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_bootstrap_detect"
  }
}

Input Schema

NameRequiredDescriptionDefault
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=false; the description reinforces this with 'Changes nothing' and tells the agent this is the safe first pass before any configuration is written. It also discloses what comes back (artifacts grouped by ecosystem, languageArtifacts, detector view) and explicitly assigns the interpretation decision to the agent, which is useful behavioral context beyond the annotations.

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?

Two sentences, front-loaded with the step and purpose, then the follow-up instructions. The inline artifact list ('C/C++; Java, Kotlin, Python, C#') is dense but pays for itself by telling the agent what evidence will come back; minor clutter only.

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 return-value burden and does so by naming the artifact categories the caller will receive. It also covers the follow-up path and the human-escalation rule. Slightly short on what happens when no build system is detected, but complete enough for a one-parameter read-only probe.

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?

Only one parameter (projectDir) at 100% schema coverage, and the schema already documents it as the absolute path, usually the working directory. The description adds no extra meaning about path expectations, error conditions, or symlink/remote-path behavior, so the baseline 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?

Uses a specific verb (collect) plus the exact resource (build-system clues / artifacts and languageArtifacts, plus the toolchain detector's view). It also positions itself as 'Step 1 of connecting a project to STATIC', which distinguishes it from the begin/finish/verify/guard siblings without needing their 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?

Gives clear ordering (step 1), points to statica_get_guide topic=bootstrap as the follow-up, and says to ask the user when clues are ambiguous. It does not state any case where the tool should be skipped, but the sequencing and escalation rules are explicit enough to act on.

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