Skip to main content
Glama
Sign In
SapperMCP

SapperMCP

by MasterX1582
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sapper Done

sapper_done

Conclude a security-assessment intent by recording the fact it produced, linking the outcome to the intent ID for traceable findings and reporting.

Instructions

Conclude an intent with the fact it produced (atomic, like sapper done <id> --fact "...").

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": {
      "id": "<id>",
      "fact": "<fact>"
    },
    "name": "sapper_done"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
docNo
dataNo
factYes
kindNo
storeNo.sapper
titleNo
workerNomcp
doc_fileNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose one real trait - 'atomic', meaning the conclusion and the fact recording happen as a single transaction - but it is silent on intent state transitions, irreversibility, side effects on the knowledge base, idempotency, and error behavior when the id is unknown.

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?

A single front-loaded sentence with no filler, and the parenthetical CLI mapping adds a useful anchor for id and fact. It is efficient, though minimal to the point that its brevity reflects under-specification elsewhere rather than tight writing.

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

Completeness2/5

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

For a 9-parameter mutating tool with zero annotations, the definition is far too thin - it doesn't explain the relationship between the intent and the fact store, the semantics of the optional doc/data envelope, or what the transition does. The output schema covers return values, but input and behavioral completeness are not met.

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% across 9 parameters, and the description only clarifies the two required ones (id and fact) via the CLI analogy. The remaining seven (doc, doc_file, data, kind, title, store, worker) are undocumented in both schema and description, leaving an agent to guess at their meaning and defaults.

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?

States a specific verb and resource: 'Conclude an intent with the fact it produced', which tells an agent this closes an intent while recording the resulting fact. It does not distinguish itself from likely siblings such as sapper_complete or sapper_fact, so the scope boundary is left implicit.

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 phrasing 'conclude an intent with the fact it produced' implies the moment of use (finishing work that yielded a fact), reinforced by the CLI example. There is no explicit when-not guidance and no named alternative for cases where an intent is abandoned or closed without a fact (e.g., sapper_complete).

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