Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Scan Prompt

get_scan_prompt

Retrieve guidance prompts for scanning a codebase: security control gap discovery or functional test implementation briefs. Use the briefs to drive gap discovery and test implementation.

Instructions

Get guidance prompts for scanning a codebase. Read-only; no side effects.

kind selects which scan brief to return:

  • "security" (default) — prompts telling the agent what evidence to look for per security control; only NOT_IMPLEMENTED controls are included (implemented ones need no scan). Use this to drive a gap-discovery pass, then record what is missing with submit_findings and what is present with submit_assertions. Pass control_id to scope the prompt to one control; empty (default) returns prompts for all not-yet-implemented controls.

  • "functional" — the agent brief for implementing functional-conformance tests. Generation specifies the functional tests, so for each test not yet verified this returns its implementation brief and the objectives it proves; it also reports objectives_without_tests (regenerate or add a test) and missing_objectives (applicable conditions with no objective yet). Drive test implementation from it, then call submit_assertions (functional_test_id) with TEST_EXISTS + TEST_ATTESTED assertions so CI verifies each test; read the resulting pass/fail state via get_functional_coverage. control_id does not apply to this kind and is ignored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo"security" (default) or "functional" — which scan brief.security
model_idYesID of the threat model.
control_idNoSecurity kind only — optional single control to scope the prompt to. Empty (default) returns prompts for all not-yet-implemented controls. Ignored when kind="functional".
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.68.2
    • changedInput schema / properties / control_id / description
      Previous value: -"Optional single control to scope the prompt to. Empty (default) returns prompts for all not-yet-implemented controls."New value: +"Security kind only — optional single control to scope\nthe prompt to. Empty (default) returns prompts for all\nnot-yet-implemented controls. Ignored when kind=\"functional\"."
    • addedInput schema / properties / kind
      Added value: +{
+  "default": "security",
+  "description": "\"security\" (default) or \"functional\" — which scan brief.",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.66.0
    • changedInput schema / properties / control_id / description
      Previous value: -"Optional specific control ID."New value: +"Optional single control to scope the prompt to. Empty (default) returns prompts for all not-yet-implemented controls."
  3. Addedv0.62.2
  4. Removedv0.62.0
  5. First observedv0.57.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so reasonably: it declares "Read-only; no side effects" and discloses filtering behavior (only NOT_IMPLEMENTED controls included) and that control_id is ignored for functional. It omits auth/permission requirements and pagination/size characteristics, but for a read-only prompt getter these are minor.

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 purpose followed by clearly delineated bullets per kind. It is on the longer side, but each clause carries mode-specific workflow information rather than restating the name, so the length is largely earned.

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

Completeness5/5

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

For a 4-parameter tool with an output schema, the description supplies the missing context an agent needs: what each kind returns, how control_id interacts with each kind, and which downstream tools consume the result. Nothing needed to invoke it correctly is absent.

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

Parameters4/5

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

Schema coverage is 75% and the schema already documents kind and control_id, but the description adds meaningful semantics: default resolution of empty control_id ("returns prompts for all not-yet-implemented controls"), the mode-scoped applicability of control_id, and the effect of each kind on returned content. This goes beyond the schema text.

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?

Starts with a specific verb+resource ("Get guidance prompts for scanning a codebase") and then precisely distinguishes the two modes it serves: security briefs vs functional briefs. An agent can tell exactly what the tool returns and how the two kinds differ without opening the schema.

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

Usage Guidelines5/5

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

Explicit when/when-to-use for each mode: security to "drive a gap-discovery pass", functional to "drive test implementation", each with the follow-up calls (submit_findings, submit_assertions, get_functional_coverage). It also states control_id does not apply to the functional kind, closing off a misuse path.

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