Skip to main content
Glama

mimic_ai_knowledge_write

Idempotent

Saves design rules, components, patterns, or gaps to Mimic's knowledge store, enabling the system to learn and apply consistent design decisions across future builds.

Instructions

Saves a component recipe, layout pattern, DS gap, or user-defined design rule to the persistent knowledge store — the mechanism that lets Mimic learn across builds. Use "rule" when the user corrects build behavior in a generalizable way (e.g. "cards always have a header + content frame"); other types are usually written automatically by the build pipeline. Params: type ("component"|"pattern"|"gap"|"rule", required), id (unique key, required), data (entry payload, required).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUnique identifier for the entry.
dataYesThe entry data to store.
typeYesType of knowledge entry to save. Use "rule" for user-defined design rules that should be followed on every build (e.g., color semantics, card structure, component usage patterns).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv3.0.0
    • addedInput schema / properties / data
      Added value: +{
      +  "description": "The entry data to store.",
      +  "type": "object"
      +}
    • addedInput schema / properties / id
      Added value: +{
      +  "description": "Unique identifier for the entry.",
      +  "type": "string"
      +}
    • removedInput schema / properties / reset_gap_seen_counts
      Removed value: -{
      -  "description": "Set true when the user signals their design system was updated. Resets seen_count to 0 on ALL gap-type rules, causing Mimic AI to re-run DS search for those patterns on the next run and discover any newly added components.",
      -  "type": "boolean"
      -}
    • removedInput schema / properties / rule_updates
      Removed value: -{
      -  "description": "Array of explicit DS rule updates: gaps (no component exists), substitutions (use this instead), or conventions (DS usage rules).",
      -  "items": {
      -    "properties": {
      -      "dismissed": {
      -        "description": "Set true to permanently suppress this gap from DS recommendations. Use when the user acknowledges the gap and decides not to add the component.",
      -        "type": "boolean"
      -      },
      -      "increment_seen": {
      -        "description": "Set true to increment seen_count by 1. Use for gap/substitution rules — not for conventions.",
      -        "type": "boolean"
      -      },
      -      "notes": {
      -        "description": "Optional context about this rule.",
      -        "type": "string"
      -      },
      -      "reason": {
      -        "description": "Why this rule exists.",
      -        "type": "string"
      -      },
      -      "reset_seen_count": {
      -        "description": "Set true to reset seen_count to 0. Use when a correction is made (paired with increment_correction on the pattern update) or when demoting a stale rule.",
      -        "type": "boolean"
      -      },
      -      "rule_key": {
      -        "description": "Required. Pattern key this rule applies to (e.g. \"label/chip\"). Must match the Pattern Key Taxonomy.",
      -        "type": "string"
      -      },
      -      "state": {
      -        "description": "Set \"resolved\" when a previously missing DS component now exists. Removes the rule from future recommendations and re-enables DS search.",
      -        "enum": [
      -          "active",
      -          "resolved"
      -        ],
      -        "type": "string"
      -      },
      -      "substitution_key": {
      -        "description": "Component key to use as fallback when pattern has no direct DS match.",
      -        "type": "string"
      -      },
      -      "substitution_name": {
      -        "description": "Human-readable name of the substitution component.",
      -        "type": "string"
      -      },
      -      "type": {
      -        "description": "gap = no DS component; substitution = use substitution_key instead; convention = DS usage rule.",
      -        "enum": [
      -          "gap",
      -          "substitution",
      -          "convention"
      -        ],
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "rule_key"
      -    ],
      -    "type": "object"
      -  },
      -  "type": "array"
      -}
    • addedInput schema / properties / type
      Added value: +{
      +  "description": "Type of knowledge entry to save. Use \"rule\" for user-defined design rules that should be followed on every build (e.g., color semantics, card structure, component usage patterns).",
      +  "enum": [
      +    "component",
      +    "pattern",
      +    "gap",
      +    "rule"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / properties / updates
      Removed value: -{
      -  "description": "Array of pattern entry updates to apply.",
      -  "items": {
      -    "properties": {
      -      "component_key": {
      -        "description": "Figma component key hash for the mapped DS component.",
      -        "type": "string"
      -      },
      -      "component_name": {
      -        "description": "Human-readable component name.",
      -        "type": "string"
      -      },
      -      "dismissed_conflicts": {
      -        "description": "Component keys to suppress in future DS evolution conflict scans.",
      -        "items": {
      -          "type": "string"
      -        },
      -        "type": "array"
      -      },
      -      "increment_correction": {
      -        "description": "Set true when the user corrected this mapping. Increments correction_count and demotes VERIFIED→CANDIDATE. Also write a rule_update with reset_seen_count=true for any associated rule.",
      -        "type": "boolean"
      -      },
      -      "increment_use": {
      -        "description": "Set true to increment use_count by 1 for an existing entry.",
      -        "type": "boolean"
      -      },
      -      "library_key": {
      -        "description": "Library key from Figma search. Tracks which DS library this component belongs to.",
      -        "type": "string"
      -      },
      -      "library_name": {
      -        "description": "Human-readable library name (e.g., \"My Team Library\").",
      -        "type": "string"
      -      },
      -      "notes": {
      -        "description": "Optional context note.",
      -        "type": "string"
      -      },
      -      "pattern_key": {
      -        "description": "Required. Canonical taxonomy key (e.g. \"metric/kpi\", \"label/chip\"). Must match the Pattern Key Taxonomy.",
      -        "type": "string"
      -      },
      -      "state": {
      -        "description": "Explicit state override. Omit to let promotion logic handle CANDIDATE→VERIFIED automatically.",
      -        "enum": [
      -          "CANDIDATE",
      -          "VERIFIED",
      -          "REJECTED",
      -          "EXPIRED"
      -        ],
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "pattern_key"
      -    ],
      -    "type": "object"
      -  },
      -  "type": "array"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "updates"
      -]New value: +[
      +  "type",
      +  "id",
      +  "data"
      +]
  2. First observedv1.4.0

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the tool lets Mimic learn across builds, but does not disclose potential failures, permissions, or side effects beyond what annotations cover. With annotations providing the safety profile, the description adds moderate context.

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 concise with two sentences and a brief params summary. It front-loads the purpose and usage guidance without redundancy. Every sentence adds value.

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 there is no output schema, the description is complete. It explains the tool's purpose, usage guidelines, and parameter details. Annotations provide idempotence and non-destructive hints, making the description sufficient for an agent 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 100% with descriptions for all parameters. The description adds extra meaning for the 'type' parameter by providing use cases and examples (e.g., 'rule' for design rules), which goes beyond the schema enum list. The 'id' and 'data' parameters are clear from schema but not further elaborated.

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 that the tool saves knowledge entries (component recipe, layout pattern, DS gap, or design rule) to a persistent store. It uses a specific verb (saves) and resource (knowledge store), and distinguishes itself from the sibling mimic_ai_knowledge_read tool.

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 when to use the 'rule' type (user correcting build behavior in a generalizable way) and notes that other types are usually written automatically. It does not explicitly state when not to use the tool, but the guidance is clear enough.

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