Mipiti MCP Server

Overview Schema Source Related Servers Discussions Admin

Import Compliance Framework

import_compliance_framework

Import custom compliance frameworks when built-in options don't cover a customer's regulatory, contractual, or internal program; after import, select it on threat models like built-in frameworks.

Instructions

Import a custom compliance framework. Requires PRO tier.

Use this when your customer's program (regulatory, contractual, or internal) is not covered by Mipiti's built-in frameworks. After import, the framework is selectable on threat models exactly like a built-in.

Fields: name (required), version, description, requirements (required, non-empty), level_definitions.

Each requirement takes id and description (required), level (integer, default 1), the optional grouping chapter_id / chapter_name / section_id / section_name / title, scope (component, the default, or system: covered if ANY model satisfies it) and level_specific_text (per-level text).

level_definitions and level_specific_text are keyed by the level as a string integer ("1", "2"): the key is the ordinal the level <= target_level filter compares, so a non-integer key is refused (400). Labels ("Baseline", "SL3") go in each value's name. A level value is {"name", "description", "source"}, where source is authoritative (paraphrased from the published standard) or mipiti_convention (tiers you defined).

Example::

{
  "name": "ACME Tiered",
  "level_definitions": {
    "1": {"name": "Baseline", "description": "Minimum.",
          "source": "mipiti_convention"}
  },
  "requirements": [
    {"id": "ACME-PWD", "description": "Passwords meet policy",
     "level": 1, "level_specific_text": {"1": "Min 8 characters."}}
  ]
}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`framework_json`	Yes	The framework body as a JSON string.
`server_version`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.84.0Oct 4, 2026

changedInput schema / properties / framework_json / description

Previous value: -"A JSON string containing the framework body.\n(String not dict so the JSON shape stays explicit on the wire.)"New value: +"The framework body as a JSON string."

Addedv0.62.2Jul 22, 2026
Removedv0.62.1Jul 17, 2026
First observedv0.57.0Jul 8, 2026

TDQS

A4.3/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 well: it discloses the PRO-tier entitlement requirement, the post-import state ('selectable exactly like a built-in'), and explicit error behavior (non-integer level keys are refused with 400). It omits what happens on duplicate framework names or whether import is idempotent, which is a meaningful gap for an import mutation.

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?

The definition is long but front-loads purpose, then entitlement, then usage condition, then field semantics, closing with a concrete example. Nearly every sentence conveys non-obvious payload structure, so the length is largely justified, though the field-by-field density could be tightened.

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?

An output schema exists, so return values needn't be explained, and the description covers the important non-schema behavior (entitlement, post-import availability, error codes) plus a full example of the payload. The main residual gap is documentation of server_version and duplicate-name handling, but overall it is sufficient to invoke the tool correctly.

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 low (50%) and the schema only says framework_json is 'the framework body as a JSON string', so the description must compensate. It does so thoroughly, documenting required vs optional fields, nested requirement semantics (scope 'any model' vs 'all'), level key ordinality, and the level value shape. The second parameter, server_version, remains entirely undocumented by both schema and description.

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?

States a specific verb and resource ('import a custom compliance framework') and scopes it against the alternative path ('not covered by Mipiti's built-in frameworks'). It also clarifies the post-import behavior ('selectable on threat models exactly like a built-in'), which lets an agent distinguish it from siblings like list_compliance_frameworks or select_compliance_frameworks.

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?

'Use this when your customer's program (regulatory, contractual, or internal) is not covered by Mipiti's built-in frameworks' gives a clear triggering condition for the tool. It stops short of explicitly naming list_compliance_frameworks as the prerequisite check or naming an exclusion, but the context is unambiguous.

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

Deploy Server