Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Import Compliance Framework

import_compliance_framework

Import a custom compliance framework when built-in ones don't cover your program, making it selectable on threat models.

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 11 built-in frameworks. After import, the framework is selectable on threat models exactly like a built-in.

Schema (top-level fields): - name (required): framework display name - version (optional): e.g. "1.0" - description (optional): one-paragraph description - level_definitions (optional, level-aware frameworks only): map keyed by stringified integer level ("1", "2", …) because the key IS the cumulative-filter ordinal (level <= target_level) and the level: int field on every requirement. Non-integer keys are rejected with HTTP 400. Human labels are decoupled — "Baseline" / "Hardened" / "SL3" / "CAL Critical" live in the name field, not the key. Each value is {"name", "description", "source"}. Ships the per-level legend to the LLM prompt and the framework-target UI. source is "authoritative" when paraphrased from the published standard, "mipiti_convention" when you defined the tiers yourself. - requirements (required, non-empty list): each entry takes id (required), description (required), level (optional integer, default 1), chapter_id / chapter_name / section_id / section_name / title (optional grouping), scope (optional, "component" default or "system" for requirements covered if ANY model satisfies them), level_specific_text (optional map of per-tier text; same stringified-integer-key rule as level_definitions).

Example minimal body::

{
  "name": "ACME Internal Baseline",
  "version": "2026.1",
  "requirements": [
    {"id": "ACME-1", "description": "All endpoints authenticate", "level": 1},
    {"id": "ACME-2", "description": "TLS 1.3 in transit", "level": 1}
  ]
}

Example with per-level legend + per-requirement parameters::

{
  "name": "ACME Tiered",
  "level_definitions": {
    "1": {"name": "Baseline", "description": "Minimum.",
          "source": "authoritative"},
    "2": {"name": "Hardened", "description": "Sensitive data.",
          "source": "mipiti_convention"}
  },
  "requirements": [
    {"id": "ACME-PWD",
     "description": "Passwords meet policy",
     "level": 1,
     "level_specific_text": {
       "1": "Min 8 characters.",
       "2": "Min 14 + MFA required."
     }}
  ]
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
framework_jsonYesA JSON string containing the framework body. (String not dict so the JSON shape stays explicit on the wire.)
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.2
  2. Removedv0.62.1
  3. First observedv0.57.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it does so well: it discloses the PRO-tier requirement, the post-import availability on threat models, and the HTTP 400 rejection for non-integer level keys. It does not cover idempotency or whether an existing framework with the same name is overwritten, but the disclosed behaviors are substantial and directly relevant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but appropriately sized for the complex payload it documents. It is front-loaded with purpose and usage, then structured into clear top-level fields and examples. Every section earns its place, especially because the input schema does not carry the nested framework schema.

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

Completeness3/5

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

The framework_json side is exceptionally well covered, including validation, field semantics, and examples. However, the required server_version parameter is never explained, which is a concrete blocker for correct invocation. The output schema exists, so return-value detail is not required, but the missing parameter documentation prevents the description from being fully complete.

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?

The description richly documents the framework_json body, including every top-level field, validation rules, and examples. However, server_version is a required parameter with no description in either the schema or the description, leaving a significant gap. With only 50% schema coverage, the description compensates heavily for framework_json but still leaves server_version unexplained.

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?

The description opens with a specific verb and resource: 'Import a custom compliance framework.' It further distinguishes itself from built-in frameworks by stating the import is for programs not covered by Mipiti's 11 built-ins and that after import it behaves like a built-in, which separates it from sibling tools 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?

The description gives clear when-to-use guidance: 'Use this when your customer's program (regulatory, contractual, or internal) is not covered by Mipiti's 11 built-in frameworks.' It does not explicitly name alternatives or state when not to use it, but the context is specific enough to route an agent correctly.

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