Server definition

Hash: sha256:33fa86d7b29629c02798b78c579c928fc71a5508f6fda122346a08f0d42291ba
What it is: What a remote MCP server returned when asked what it offers: 16 tools

The blob, as servednamed by its sha256

{
  "instructions": "Mutator automates short-form marketing: it generates posts into a library, and publishes the ones a person chooses, on a schedule.\n\nThree rules govern everything here.\n\n1. You cannot post. No tool on this server pushes anything to a social account, and neither does the REST API, which has no endpoint that schedules one — that is deliberate, not a permissions gap. A run publishes nothing at all: what it makes goes to the library, and a post exists only once a person has picked a file, an account and a time in Mutator, with their name on it. When a run has made something, say what it made and let them decide.\n\n2. You can build, but you cannot switch on. mutator_create_automation and mutator_save_automation_graph save DRAFTS. A draft never runs: it has no active version, the scheduler only fires active automations, and nothing here can activate one. Build freely, then hand back a link and say plainly what you chose on the user's behalf. Never describe what you built as live or running.\n\n3. Runs are dry by default, and a dry run is not free. Dry means nothing is published: mutator_start_run still generates exactly as a real run does, spending the workspace's credits. Start a run only when the user wants one, pass dryRun: false only when they have asked for a real run in this conversation, and check mutator_get_spend_limits first.\n\nBefore building, read the real vocabulary rather than inventing one: mutator_list_brands for the brand an automation belongs to, mutator_list_step_types for the steps that exist, mutator_list_formats for the content formats, and mutator_list_connections for the account a publishing step must name.\n\nTwo things this product does NOT have, which briefs often assume. There is no trend, virality or discovery data anywhere — nothing here knows what is performing on any platform, so do not claim a format is trending or viral. And a schedule runs an automation at most once a day; how many posts a day an account makes is how many posting times a person gave it on the Schedule.\n\nTypical order to operate: mutator_list_automations, mutator_get_automation, mutator_start_run, mutator_get_run.",
  "tools": [
    {
      "description": "Create a new automation as a DRAFT, optionally with its steps already wired. It is never activated and never runs: a draft has no active version, the scheduler only fires active automations, and nothing here can activate one. The person opens it, reads it, and turns it on. An invalid graph is still saved — the problems come back as `issues` for you to fix and save again, rather than the whole call failing. Report what you built and what is left to decide; do not describe it as live.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "brandId": {
            "description": "From mutator_list_brands.",
            "type": "string"
          },
          "description": {
            "maxLength": 600,
            "type": "string"
          },
          "graph": {
            "additionalProperties": false,
            "description": "Optional. The steps and their connections. Omit to create an empty draft.",
            "properties": {
              "edges": {
                "items": {
                  "type": "object"
                },
                "type": "array"
              },
              "nodes": {
                "items": {
                  "type": "object"
                },
                "type": "array"
              }
            },
            "required": [
              "nodes",
              "edges"
            ],
            "type": "object"
          },
          "name": {
            "maxLength": 120,
            "minLength": 1,
            "type": "string"
          }
        },
        "required": [
          "brandId",
          "name"
        ],
        "type": "object"
      },
      "name": "mutator_create_automation",
      "outputSchema": null
    },
    {
      "description": "Read how published content performed over a window of days — the same report the dashboard shows. Use it to answer what worked and to suggest what to run next.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "days": {
            "description": "Window in days. Defaults to 30.",
            "maximum": 365,
            "minimum": 1,
            "type": "integer"
          }
        },
        "type": "object"
      },
      "name": "mutator_get_analytics",
      "outputSchema": null
    },
    {
      "description": "Read one automation in detail: status, its schedule if it has one, and its own spending limits. Use it before starting a run to check the automation is active and what a run may cost.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "automationId": {
            "description": "Automation id from mutator_list_automations.",
            "type": "string"
          }
        },
        "required": [
          "automationId"
        ],
        "type": "object"
      },
      "name": "mutator_get_automation",
      "outputSchema": null
    },
    {
      "description": "Read one run with its per-step detail, so a failure can be traced to the step that caused it. Runs are asynchronous: a run still marked running has not finished, so poll rather than assume.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "runId": {
            "description": "Run id, as returned by mutator_start_run.",
            "type": "string"
          }
        },
        "required": [
          "runId"
        ],
        "type": "object"
      },
      "name": "mutator_get_run",
      "outputSchema": null
    },
    {
      "description": "Report the workspace's daily and monthly spending ceilings and how much of each is already committed. Generation runs on Mutator's own accounts and is paid for in credits, and the ceilings still apply, so check this before starting anything that generates — a run that would pass a ceiling is refused before any provider is contacted.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_get_spend_limits",
      "outputSchema": null
    },
    {
      "description": "Always empty. Approvals were removed on 20 September 2026: a run publishes nothing, and a post is made by a person picking a file, an account and a time in Mutator. Tell the person that, rather than reporting an empty queue as if something were wrong. Use mutator_get_run to report what a run made.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_list_approvals",
      "outputSchema": null
    },
    {
      "description": "List every automation in the workspace with its id, name and status (draft, active or paused). Start here when the user refers to an automation by name and you need its id.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_list_automations",
      "outputSchema": null
    },
    {
      "description": "List the brands in the workspace. Every automation belongs to one, so this is the first call when creating anything: mutator_create_automation needs a brandId from here. The brand carries the voice an automation writes in — audience, tone, call to action.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_list_brands",
      "outputSchema": null
    },
    {
      "description": "List the accounts and providers this workspace has connected, with the id a publishing step needs. A publish step points at a connection, not at a platform name — there is no 'post to TikTok' field, only 'post to this account, which happens to be TikTok'. Read this before wiring one, because a publish step with no connection is refused at activation rather than saved and forgotten.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_list_connections",
      "outputSchema": null
    },
    {
      "description": "The content formats this product actually knows, and the niches they suit. Use one of these when building — do not invent a format. There is no trend, virality or discovery data anywhere in Mutator: nothing here knows what is performing on any platform this week, and a niche only ORDERS this list, it never filters it. If a user asks for 'viral formats in my niche', these are the formats, ordered by fit, and the word viral is not something this tool can stand behind.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "niche": {
            "description": "Optional niche id to order the list by fit. Formats that suit no niche still appear.",
            "type": "string"
          }
        },
        "type": "object"
      },
      "name": "mutator_list_formats",
      "outputSchema": null
    },
    {
      "description": "List recent runs of one automation, newest first, with status, whether each was a dry run, and what it cost. Use it to answer 'did it work' and 'what did it cost'.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "automationId": {
            "description": "Automation id from mutator_list_automations.",
            "type": "string"
          },
          "limit": {
            "description": "How many runs to return. Defaults to 10.",
            "maximum": 50,
            "minimum": 1,
            "type": "integer"
          }
        },
        "required": [
          "automationId"
        ],
        "type": "object"
      },
      "name": "mutator_list_runs",
      "outputSchema": null
    },
    {
      "description": "The complete vocabulary of steps, with the settings each one takes. An automation is a graph of these joined by edges. Read this before building one: the step list is closed, and a graph naming a type that is not here is refused. Most settings have defaults, so a step can usually be sent with an empty config and still run.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_list_step_types",
      "outputSchema": null
    },
    {
      "description": "Replace an automation's steps with the ones given, saved as a DRAFT. An active automation keeps running its current version until a person activates the draft, so editing something live is safe. Problems come back as `issues` rather than failing the call — read them and save a corrected graph.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "automationId": {
            "description": "Automation id from mutator_list_automations.",
            "type": "string"
          },
          "graph": {
            "additionalProperties": false,
            "properties": {
              "edges": {
                "items": {
                  "type": "object"
                },
                "type": "array"
              },
              "nodes": {
                "items": {
                  "type": "object"
                },
                "type": "array"
              }
            },
            "required": [
              "nodes",
              "edges"
            ],
            "type": "object"
          }
        },
        "required": [
          "automationId",
          "graph"
        ],
        "type": "object"
      },
      "name": "mutator_save_automation_graph",
      "outputSchema": null
    },
    {
      "description": "Set when an automation would run, saved switched OFF. Turning a schedule on requires an already-active automation, so this can only ever prepare one — the settings survive until a person activates it. A schedule runs an automation AT MOST ONCE A DAY: it holds a single time, and frequency chooses which days rather than how many times within one. Two posts a day is not a schedule setting: it is one daily run producing two items, with maxPostsPerDay on the publishing step.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "automationId": {
            "description": "Automation id from mutator_list_automations.",
            "type": "string"
          },
          "frequency": {
            "enum": [
              "daily",
              "weekdays",
              "weekly",
              "custom"
            ],
            "type": "string"
          },
          "timeOfDay": {
            "description": "24-hour local time, \"HH:mm\".",
            "type": "string"
          },
          "timezone": {
            "description": "IANA zone, e.g. \"America/New_York\".",
            "type": "string"
          },
          "weekdays": {
            "description": "ISO weekdays, Monday is 1. Used by weekly and custom.",
            "items": {
              "maximum": 7,
              "minimum": 1,
              "type": "integer"
            },
            "type": "array"
          }
        },
        "required": [
          "automationId",
          "frequency",
          "timeOfDay",
          "timezone"
        ],
        "type": "object"
      },
      "name": "mutator_set_schedule",
      "outputSchema": null
    },
    {
      "description": "Start a run of an automation. Defaults to a DRY RUN, which skips publishing but not generation: it makes the same paid generation calls a real run makes, costs the same credits or provider charges, and counts against the same spend limits. So start one only when the user wants a run, and leave it dry unless they have asked for a real run in this conversation. A real run still publishes nothing on its own: anything it generates goes to the workspace's library, and is posted only when a person schedules it in Mutator. Requires an idempotencyKey; replaying the same value returns the original run instead of starting a second one, so retry with the same key rather than a new one.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {
          "automationId": {
            "description": "Automation id from mutator_list_automations.",
            "type": "string"
          },
          "dryRun": {
            "description": "Defaults to true. Pass false only when the user has explicitly asked for a real run.",
            "type": "boolean"
          },
          "idempotencyKey": {
            "description": "Your own key for this attempt, 8-80 characters. Reuse it verbatim when retrying.",
            "maxLength": 80,
            "minLength": 8,
            "type": "string"
          }
        },
        "required": [
          "automationId",
          "idempotencyKey"
        ],
        "type": "object"
      },
      "name": "mutator_start_run",
      "outputSchema": null
    },
    {
      "description": "Confirm the API key works and report which Mutator workspace it reaches and what it may do. Call this first when the connection is new or a later call fails with an authorization error.",
      "inputSchema": {
        "additionalProperties": false,
        "properties": {},
        "type": "object"
      },
      "name": "mutator_whoami",
      "outputSchema": null
    }
  ]
}

Verify it yourself

curl -s https://api.teppi.xyz/v1/evidence/sha256:33fa86d7b29629c02798b78c579c928fc71a5508f6fda122346a08f0d42291ba | sha256sum