Skip to main content
Glama
Mipiti
by Mipiti

submit_assertions

Prove security controls and system property claims by submitting typed, machine-verifiable assertions about source code, configuration, infrastructure, or external services.

Instructions

Submit assertions for a security control or an assumption.

Each assertion is a typed, machine-verifiable claim about a system property (source code, configuration, infrastructure, or external service settings).

Provide exactly one of control_id or assumption_id:

  • control_id: proves a control is implemented (e.g., "CTRL-01")

  • assumption_id: proves a system property claim (e.g., "AS5" — asset non-applicability, attacker non-applicability, scope decisions)

For assumption assertions against the feature description (greenfield), use target instead of file in params: {"type": "pattern_matches", "params": {"target": "feature_description", "pattern": "password.*TOTP"}, "description": "..."}

Args: model_id: ID of the threat model. control_id: ID of the control (omit if using assumption_id). assumption_id: ID of the assumption (omit if using control_id). assertions_json: JSON array of assertion objects. Each object has: - type (required): one of the assertion types below - params (required): type-specific parameters (file or target + pattern/name/etc.) - description (required): human-readable explanation of what this proves - repo (optional): "org/repo-name" for multi-repo setups

Assertion types:

  • function_exists: Check that a function or method exists in a file. Supports Python, JavaScript, TypeScript, Go, Rust, Swift, Java, C#. Params: file (File path relative to project root), name (Function or method name)

  • class_exists: Check that a class, struct, or interface exists in a file. Params: file (File path relative to project root), name (Class, struct, or interface name)

  • decorator_present: Check that a decorator is applied to a function (Python). Params: file (File path relative to project root), function (Function name), decorator (Decorator name (without @))

  • function_calls: Check that a function calls another function. Params: file (File path relative to project root), caller (Calling function name), callee (Called function name)

  • import_present: Check that a module is imported in a file. Supports Python, JavaScript, Go, Rust. Params: file (File path relative to project root), module (Module or package name)

  • file_exists: Check that a file exists at the given path. Params: file (File path relative to project root)

  • file_hash: Check that a file's hash matches an expected value. Use scope_file/scope_start/scope_end to reference the code that pins this hash (e.g., a deploy script that verifies the file's integrity). Params: file (File path relative to project root), algorithm (Hash algorithm: sha256, sha384, sha512, md5), expected_hash (Expected hex-encoded hash), scope_file (File containing code that references/checks this hash. Tier 2 reviews this code to verify the hash check is meaningful.); optional: scope_start (Regex marking start of the relevant code section in scope_file.), scope_end (Regex marking end of the relevant code section in scope_file.)

  • pattern_matches: Check that a regex pattern exists in a file. Uses RE2 syntax (no backreferences, lookahead, or lookbehind). Params: file (File path relative to project root), pattern (RE2 regex pattern to search for); optional: scope_start (Regex pattern marking the start of the search scope within the file. Only content between scope_start and scope_end is searched.), scope_end (Regex pattern marking the end of the search scope. Defaults to end of file if omitted.), multiline (If true, ^ and $ match line boundaries instead of string boundaries. Default: false.), dotall (If true, . matches newlines, enabling patterns that span multiple lines. Default: false.)

  • pattern_absent: Check that a regex pattern does NOT exist in a file. Uses RE2 syntax (no backreferences, lookahead, or lookbehind). Params: file (File path relative to project root), pattern (RE2 regex pattern that must be absent); optional: scope_start (Regex pattern marking the start of the search scope within the file. Only content between scope_start and scope_end is checked for absence.), scope_end (Regex pattern marking the end of the search scope. Defaults to end of file if omitted.), multiline (If true, ^ and $ match line boundaries instead of string boundaries. Default: false.), dotall (If true, . matches newlines, enabling patterns that span multiple lines. Default: false.)

  • no_plaintext_secret: Check that no plaintext secrets matching given patterns exist in a file. Patterns use RE2 syntax (no backreferences, lookahead, or lookbehind). Params: file (File path relative to project root), patterns (JSON array of regex patterns to check for secrets)

  • config_key_exists: Check that a config key exists. Supports JSON, YAML, TOML, INI, .env files. Use dot notation for nested keys. Params: file (File path relative to project root), key (Config key (dot notation for nested))

  • config_value_matches: Check that a config value matches a regex pattern. Uses RE2 syntax (no backreferences, lookahead, or lookbehind). Params: file (File path relative to project root), key (Config key (dot notation for nested)), pattern (RE2 regex pattern the value must match)

  • env_var_referenced: Check that an environment variable is referenced in a file. Detects os.environ, process.env, ${VAR}, $VAR, etc. Params: file (File path relative to project root), variable (Environment variable name)

  • dependency_exists: Check that a package exists in a dependency manifest. Supports requirements.txt, package.json, Cargo.toml, go.mod, pyproject.toml, pom.xml. Params: manifest (Path to dependency manifest file), package (Package name)

  • dependency_version: Check that a package version satisfies a constraint. Uses PEP 440 syntax for Python, semver for JS. Params: manifest (Path to dependency manifest file), package (Package name), constraint (Version constraint (PEP 440 or semver))

  • parameter_validated: Check that a function validates a specific parameter. Tier 1 checks existence, tier 2 uses AI to verify validation logic. Params: file (File path relative to project root), function (Function name), parameter (Parameter name that should be validated)

  • error_handled: Check that a function has error handling (try/catch/except, Go error checks, Rust Result). Params: file (File path relative to project root), function (Function name)

  • middleware_registered: Check that middleware is registered in a file. Detects .use(), .add_middleware(), @decorator patterns. Params: file (File path relative to project root), middleware (Middleware name or class)

  • http_header_set: Check that an HTTP header is set or referenced in a file. Params: file (File path relative to project root), header (HTTP header name)

  • test_exists: Check that test files matching a glob pattern exist. Params: pattern (Glob pattern for test files)

  • test_passes: Run tests matching a pattern and verify they pass. Auto-detects pytest, npm test, cargo test. Params: pattern (Test name or pattern to match)

  • module_exists: Check that a Verilog/SystemVerilog module (or primitive/program) is declared in a file. Params: file (File path relative to project root), name (Module name)

  • module_instantiated: Check that a module directly instantiates another module inside its module...endmodule body. Params: file (File path relative to project root), parent (Enclosing module name), child (Instantiated module name)

  • port_exists: Check that a module declares a port, optionally with a specific direction. Detects ANSI header and non-ANSI body declarations. Params: file (File path relative to project root), module (Module name), port (Port name); optional: direction (Port direction: input, output, or inout)

  • parameter_defined: Check that a parameter or localparam is declared, optionally that its assigned value matches a regex (RE2 syntax). Params: file (File path relative to project root), parameter (Parameter or localparam name); optional: module (Module to scope the search to (whole file if omitted)), pattern (RE2 regex the assigned value must match)

  • signal_exists: Check that a net or variable (wire, reg, logic, bit) is declared. Params: file (File path relative to project root), name (Signal name); optional: module (Module to scope the search to (whole file if omitted)), kind (Declaration kind: wire, reg, logic, or bit)

  • sva_assertion_present: Check that a named SystemVerilog assertion is present: a property declaration, or a labelled assert/assume/cover statement. Params: file (File path relative to project root), name (Property name or assertion label)

  • register_reset: Check that a register is assigned on a reset path. Tier 1 finds an always block that references the reset and assigns the signal; tier 2 uses AI to verify the register resets to a safe, known value. Params: file (File path relative to project root), signal (Register/signal name that must be reset); optional: reset (Reset signal name (common rst/reset names detected if omitted))

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYes
control_idNo
assumption_idNo
server_versionYes
assertions_jsonYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It is remarkably transparent, detailing the JSON structure, all 20+ assertion types with their parameters, optional fields, scoping mechanisms, regex syntax, language support, and tier-level verification behavior (e.g., 'Tier 1 checks existence, tier 2 uses AI to verify logic'). No contradictions or omissions are present.

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 description is front-loaded with purpose and usage, then systematically lists all assertion types in a structured bullet format with code examples. While verbose (over 100 lines), the level of detail is justified by the complexity of the tool. Some redundancy could be trimmed (e.g., repeated 'Params:' lines), but overall it is well-organized and essential information is easy to find.

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?

Given the tool's complexity (5 parameters, 20+ assertion types, nested JSON structure) and the presence of an output schema, the description is fully complete. It covers all scenarios: security controls vs assumptions, file vs target, optional scope parameters, regex limitations, and language-specific behavior. No gaps are apparent.

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

Parameters5/5

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

Schema coverage is 0%, yet the description compensates fully. It explains the top-level parameters (model_id, control_id, assumption_id, assertions_json) and thoroughly describes the nested structure of assertions_json, including type-specific params. Only server_version is not explicitly described, but all other parameters receive comprehensive, meaningful documentation. The description adds immense value beyond the raw schema.

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 'Submit assertions for a security control or an assumption' and explains the tool's role in providing typed, machine-verifiable claims. It distinguishes between control_id and assumption_id usage, and the extensive detail on assertion types leaves no ambiguity. Among siblings, it is the only tool for submitting assertions, so purpose is unequivocal.

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 provides explicit guidance on using exactly one of control_id or assumption_id, and includes an example for assumption assertions with target instead of file. It thoroughly explains each assertion type and their parameters. However, it does not explicitly state when not to use this tool or mention alternatives for modifying existing assertions (e.g., delete_assertion), which would strengthen usage clarity.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mipiti/mipiti-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server