Skip to main content
Glama
Sign In
statica-mcp

statica-mcp

Official
by SuresoftTechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check the build was captured

statica_bootstrap_verify
Read-only

Verifies that STATIC has analyzable code after a C/C++ build or Java/Kotlin descriptor setup, confirms whether the wrapper was used, and returns the workspace when resuming.

Instructions

After substituting the compiler and building (C/C++), or preparing the build descriptor (Java/Kotlin), check that STATIC has something to analyze. A successful build is not proof it went through the wrapper; ok=false means it did not. What to do next depends on the substitution type - see the guide (do not abort a GUI substitution). Also returns the workspace when resuming. Can be called any number of times.

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

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

A3.6/5.0
Behavior3/5

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

Annotations already mark this as a safe read (readOnlyHint true, openWorldHint false). The description adds real value beyond those annotations by warning that a successful build is not proof it went through the wrapper, that ok=false signals that the build wasn't captured, and that the tool is idempotent (callable any number of times). However, it doesn't say which fields the response contains beyond ok and workspace, leaving a moderate gap for a verification tool.

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?

Three tightly packed sentences, front-loaded with the precondition (build already done) and then the key failure semantics (ok=false). The phrase 'see the guide' slightly defers guidance elsewhere, but there's no wasted 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 return-value burden and does explain the critical semantics of ok and the workspace returned when resuming. Since there is a single fully documented parameter and the tool is a read-only check, the definition is nearly complete, missing only the full shape of the returned 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?

There is only one parameter, and the schema already documents it at 100% coverage, including that it is usually the session's working directory. The description adds nothing about projectDir, so the baseline of 3 applies.

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 states a specific verb and resource: verify that STATIC captured the build so it has something to analyze. It is clear what the tool checks against, though it doesn't sharply name which sibling (finish vs verify) handles the next step, so it falls short of the top score.

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?

It spells out the timing: after substituting the compiler and building for C/C++, or after preparing the build descriptor for Java/Kotlin. It also gives a conditional warning not to abort a GUI substitution, and points to the guide for the branch-dependent next step. It does not name a sibling alternative outright, but the context is clear.

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