Skip to main content
Glama

bolt_audit_seams

Audit vendor imports, cross-slot coupling, unfinished boundaries, provenance, and banned literals to surface integration risks and record actionable seam tickets and security notices.

Instructions

Check vendor imports, cross-slot coupling, unfinished boundaries, provenance, and banned literal patterns. Record actionable seam tickets and vendor security_notices.

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": {
      "slotId": "<slotId>"
    },
    "name": "bolt_audit_seams"
  }
}

Input Schema

NameRequiredDescriptionDefault
slotIdYes
projectPathNoProject directory; defaults to the server project

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already establish a non-read-only, non-idempotent, open-world operation; the description adds that it records seam tickets and vendor security_notices. It still does not disclose permissions, whether repeated runs create duplicates, or what recording actually changes, so it adds some but not rich behavioral context.

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 compact sentences, front-loaded with the audit scope and then the side effect. The list is dense but each item contributes to the scope; no filler.

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 multi-check audit that writes records and has no output schema, the definition omits usage context, the meaning of slotId, and what the recorded tickets or notices contain. It is directionally useful but incomplete for correct invocation.

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?

The schema documents projectPath but not slotId, and the description mentions neither parameter. With only 50% schema coverage, the description should clarify the required slotId and its role but does not, leaving the required parameter's meaning to be inferred.

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 names a concrete audit scope: vendor imports, cross-slot coupling, unfinished boundaries, provenance, and banned literal patterns, and it says it records seam tickets and security notices. That is more than a restatement of the name, though it does not differentiate the tool from bolt_verify_slot or explain what a 'seam' is.

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

Usage Guidelines2/5

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

No when-to-use guidance or alternatives are given. It does not say whether this should run before bolt_verify_slot, after changes, or only in certain project states.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.