Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Import Functional Tests

import_functional_tests

Import existing tests from your codebase to count toward functional conformance. Optionally map each test to functional objective IDs; unmapped tests are still imported and can be associated later.

Instructions

Register tests that already exist in your codebase against a model's functional objectives, so tests you already have count toward functional conformance — not only Mipiti-specified tests. Mutating (bulk).

Scan the repo's test suite and pass the tests here. Optionally associate each with the objective ids it covers (from get_functional_objectives); the platform verifies each association is applicable before accepting it and returns any it rejected under rejected_mappings. A test with no (or a rejected) association is still imported, unmapped, so it can be associated later (see suggest_functional_test_mappings / associate_functional_test). For a single hand-authored test, use add_functional_test instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesID of the threat model.
tests_jsonYesA JSON array of test objects. Each object supports ``test_name``, ``file_path``, ``framework``, ``description``, ``status`` (not_implemented | implemented | verified — an operator claim; an independent CI run is what verifies it), and ``functional_objective_ids`` (list of objective ids the test covers). At least ``test_name`` or ``description`` is required per test; the rest are optional.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.66.0
    • changedInput schema / properties / tests_json / description
      Previous value: -"A JSON array of test objects. Each object supports\n``test_name``, ``file_path``, ``framework``, ``description``,\n``status`` (not_implemented | implemented | verified — an operator\nclaim; an independent CI run is what verifies it), and\n``functional_objective_ids`` (list of objective ids the test covers).\nAt least ``test_name`` or ``description`` is required per test; the\nrest are optional."New value: +"A JSON array of test objects. Each object supports ``test_name``, ``file_path``, ``framework``, ``description``, ``status`` (not_implemented | implemented | verified — an operator claim; an independent CI run is what verifies it), and ``functional_objective_ids`` (list of objective ids the test covers). At least ``test_name`` or ``description`` is required per test; the rest are optional."
  2. Addedv0.62.2
  3. Removedv0.62.0
  4. First observedv0.57.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden and largely succeeds: it explicitly flags 'Mutating (bulk),' explains that associations are verified by the platform, and describes that rejected or missing associations still result in the test being imported unmapped. It does not detail side effects like idempotency or whether existing tests are overwritten, but the disclosed workflow behavior is substantial.

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?

Every sentence earns its place: purpose, mutation warning, workflow, fallback behavior, and the alternative tool. The description is dense but well-structured, front-loading the core purpose and bulk-mutation nature before explaining details.

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?

The description is thorough for a bulk-import tool with an output schema: it covers the use case, parameters' semantics for the main payload, mutation behavior, rejection handling, and routing to related tools. The unresolved server_version parameter and the lack of clarity around 'Mipiti-specified tests' prevent a perfect score, but overall it is highly usable.

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 adds rich meaning to tests_json, explaining the optional fields, the status enum meanings, and association behavior beyond the schema. model_id is adequately described in the schema. However, server_version is a required parameter with no schema description and no mention in the tool description, leaving a significant semantic gap for a required input.

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 clearly states the tool's purpose: 'Register tests that already exist in your codebase against a model's functional objectives' so existing tests 'count toward functional conformance.' It names the specific resource (tests/functional objectives) and distinguishes itself from add_functional_test by noting bulk import of existing tests vs. a single hand-authored test.

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?

The description gives explicit guidance on when to use this tool: when importing existing tests from the codebase in bulk. It provides a clear exclusion: 'For a single hand-authored test, use add_functional_test instead.' It also explains follow-up workflows via suggest_functional_test_mappings / associate_functional_test for unmapped tests.

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