{ "name": "Fuel Made Brain MCP Server", "version": "1.0.0", "description": "Search, read and capture Fuel Made shared agency and client knowledge", "repository": "fuelmade/fuel-made-claude-plugins", "branch": "main", "iconUrl": "https://brain.mcp.fuelmade.com/icon.svg", "tools": [ { "name": "search_brain", "description": "Search the Fuel Made brain's indexes for notes relevant to a task or question. Returns one line per matching note (name, status, description, path), never note bodies, so it stays cheap no matter how large the brain grows. Use this FIRST, then read_note for the one or two that matter. Covers agency canon (how we write code, Foundry patterns, Shopify behaviour, process, design) and client knowledge (a client's stack, decisions, quirks and history).", "annotations": { "title": "Search the brain", "readOnlyHint": true, "destructiveHint": false, "idempotentHint": true, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "query": { "type": "string", "description": "What you actually need. Search the specific artifact or decision ('reduced motion', 'metaobject', 'back in stock'), not a broad domain word like 'Foundry', 'design' or 'section'. Those describe most of this corpus and will match a large slice of the index." }, "area": { "type": "string", "enum": [ "all", "agency", "clients" ], "description": "Restrict the search. Default 'all'. Use 'clients' when you already know the question is about one client." } }, "required": [ "query" ] } }, { "name": "read_note", "description": "Read the full body of one brain note by its name (the `name:` value shown in search_brain results). Read only the notes a task genuinely needs, usually one to three.", "annotations": { "title": "Read a brain note", "readOnlyHint": true, "destructiveHint": false, "idempotentHint": true, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "name": { "type": "string", "description": "The note's name, e.g. 'respect-reduced-motion'." } }, "required": [ "name" ] } }, { "name": "submit_note", "description": "Capture a durable learning into the Fuel Made brain. Use when someone says 'add this to the brain', 'the team should know this', or when a lasting fact about a client emerges that the next person would otherwise have to rediscover.\n\nWRITES TO A SHARED TEAM KNOWLEDGE BASE that every colleague Claude reads. Show the person the full drafted note and get their confirmation BEFORE calling this.\n\nOnly client knowledge, design constraints, and Klaviyo or inbox-rendering behaviour (scope 'email') can be captured directly. Anything about code, Foundry, Shopify platform behaviour or developer process is queued as a proposal for a developer instead. That is normal, not a failure: say so plainly and move on.\n\nLINKING IS YOUR JOB, NOT THE PERSON'S. Name related notes in `related` (or write [[note-name]] into the body) after searching for their exact names — never ask the person about links. Omit it and the client's workstream overview is used. A pointer back to the new note is added to that overview automatically, so it is findable by reading rather than only by searching.\n\nCORRECTING AN EXISTING NOTE IS THE SAME TOOL. Send the same name with the whole revised note and overwrite: true. The first attempt without it hands you back what is currently there rather than replacing it, so you can carry forward what is still true — a revision that has not read the current note is how a hard-won detail gets dropped. Previous versions are kept in the brain's history.\n\nWHAT DOES NOT BELONG: anything true of one moment rather than durably (status and scheduling go in the task tracker); anything a competent person would do by default; anything already in official Shopify documentation; anything that does not change a decision; a record of one task rather than a fact about the client. If it fails those, say so instead of capturing it.\n\nNEVER WRITE, whatever is asked: sentiment about the client or the work, and anything about an individual person (their reliability, their behaviour, whose judgement to trust). Notes are permanent and read agency-wide by people who will meet that person cold. Capture the mechanism, never the feeling about it.", "annotations": { "title": "Add a note to the brain", "readOnlyHint": false, "destructiveHint": true, "idempotentHint": false, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "scope": { "type": "string", "enum": [ "client", "design", "email", "operations" ], "description": "'client' for a fact about one client (their store, stack, decisions, preferences, history, whether dev, design or strategy). 'design' for a constraint a designer needs while designing, stated in canvas terms. 'email' for Klaviyo behaviour or inbox-rendering behaviour met while building marketing emails — the boundary is the platform, not the subject: Klaviyo and email clients here, Shopify storefront and admin are out of scope for this channel. 'operations' for how the agency runs a project — a standard operating procedure, a statement-of-work convention, procedure attached to a stage of a project. The boundary with developer process is who verifies it: if a developer would have to check the claim against the codebase, it is a proposal, not an operations note." }, "topic": { "type": "string", "enum": [ "email-rendering", "klaviyo-platform", "standard-procedures", "sow-and-scoping", "project-lifecycle" ], "description": "Required when scope is 'email' or 'operations', and the valid values differ by scope. For 'email': 'email-rendering' for how a client renders what you built, 'klaviyo-platform' for how Klaviyo itself behaves. For 'operations': 'standard-procedures' for an SOP or recurring internal procedure, 'sow-and-scoping' for statement-of-work conventions, 'project-lifecycle' for procedure attached to a stage of a project rather than to a document. Reuse one rather than inventing a neighbour." }, "client": { "type": "string", "description": "Client name, kebab-case (e.g. 'jonas-paul-eyewear'). Required when scope is 'client'." }, "codebase": { "type": "string", "description": "The client's workstream or codebase folder, kebab-case — which sub-folder this fact belongs in. Pass 'email' for ANYTHING learned building their marketing emails (fonts, palette, footer, their Klaviyo account, how their designs arrive), so it sits with the rest of that workstream instead of loose in the client's root. Pass the repo or store name for a fact true of one codebase. Omit ONLY for a fact true of the client as a whole, independent of discipline — which is rarer than it sounds." }, "slug": { "type": "string", "description": "Short kebab-case file name capturing the rule, e.g. 'quiz-results-are-headless'." }, "description": { "type": "string", "description": "One line telling a future reader WHEN this note matters: the trigger condition, in the words they would actually search for. This is the entire retrieval signal; a description that only makes sense to someone who already knows the note exists is a note nobody finds." }, "body": { "type": "string", "description": "The learning itself: concise, concrete, and including the WHY. A rule without its reasoning cannot be applied to a case it does not literally cover." }, "type": { "type": "string", "enum": [ "rule", "pattern", "process", "reference" ], "description": "Defaults to 'reference'." }, "related": { "type": "array", "items": { "type": "string" }, "description": "Names of existing notes this one sits beside — the client's other notes, or the convention it is an instance of. Search for them; never ask the person, who should not have to think about how the brain is wired. Leave it out and the client's workstream overview is used, which is the right answer more often than not. Use each note's exact `name` from search_brain: a name that is not a real note is refused, because a broken link fails the index rebuild for the whole team." }, "overwrite": { "type": "boolean", "description": "Required to revise a note that already exists at this slug. Set it only after the first attempt has handed back the current note and you have carried forward everything in it that is still true." } }, "required": [ "scope", "slug", "description", "body" ] } }, { "name": "submit_proposal", "description": "Queue a suggestion for a developer when a learning is real but falls outside what this channel may write directly: code standards, Foundry patterns, Shopify platform behaviour, or developer process. It is stored unindexed (so it costs nothing and is never mistaken for agency policy) until a developer reviews it. Tell the person plainly that it went to a developer rather than into the brain.", "annotations": { "title": "Propose a note for developer review", "readOnlyHint": false, "destructiveHint": false, "idempotentHint": false, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "slug": { "type": "string", "description": "Short kebab-case name for the suggestion." }, "description": { "type": "string", "description": "One line: what this claims and when it would matter." }, "body": { "type": "string", "description": "The suggestion in full, including why the person believes it and what they observed." }, "suggested_namespace": { "type": "string", "enum": [ "code-standards", "foundry", "shopify", "process", "apps" ], "description": "Where the person thinks it belongs. A hint for the reviewing developer, not a decision." } }, "required": [ "slug", "description", "body" ] } }, { "name": "submit_client_file", "description": "Save the machine-checkable half of a client's email setup into the brain — `style.json`: the font families exactly as registered in Klaviyo, the type scale including the mobile pairs, and the palette. It is what the style check holds a built email against, so without it that check cannot run at all.\n\nYOU compose the file; this carries it. Show the person what it records in plain words and get their confirmation BEFORE calling this. They are confirming the facts, never the format.\n\nOnly a client the brain already knows, only their email workstream, only .json or .txt. Reasoning, warnings and anything a person would read as prose goes to submit_note instead — this channel is for values a program compares against.\n\nReplacing a file that already exists needs overwrite: true, and the first attempt hands back what is currently there rather than replacing it unseen. Merge what is worth keeping: a font url somebody recovered by hand from a live template cannot be looked up again, and a well-meaning rewrite is exactly what loses it.", "annotations": { "title": "Save a client's email configuration", "readOnlyHint": false, "destructiveHint": true, "idempotentHint": false, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "client": { "type": "string", "description": "The client's folder name in the brain, kebab-case (e.g. 'wildflower-cases'). It must already exist: this never creates a client, because being given a Klaviyo account is not what makes one." }, "filename": { "type": "string", "description": "A bare file name, kebab-case, ending .json or .txt — almost always 'style.json'. No folders: the path is decided here." }, "content": { "type": "string", "description": "The complete file, exactly as it should land. JSON is parsed before anything is written, so a malformed file fails here rather than in front of whoever runs the check next." }, "overwrite": { "type": "boolean", "description": "Required to replace a file that already exists. Set it only after you have seen the current contents and merged anything worth keeping into yours." } }, "required": [ "client", "filename", "content" ] } }, { "name": "submit_skill", "description": "Write a new skill into a Fuel Made plugin, or revise one. Use when someone describes a procedure they want Claude to FOLLOW from now on — a repeatable way of producing a document or running a process — rather than a fact they want recorded. A fact is a note: use submit_note.\n\nTHIS IS THE MOST POWERFUL TOOL HERE. A skill is instructions every colleague's Claude follows once their plugin updates, and no developer reviews it first. Draft it, show the person the FULL text including the description, and get their explicit confirmation before calling this.\n\nOnly 'fuel-made-ops' (operations and project management), 'fuel-made-toolkit' (PM/AM/sales — note this one is installed team-wide, so prefer fuel-made-ops when a skill is operations-shaped) and 'fuel-made-email-forge' (the email team). The developer plugins are refused: a Liquid or Foundry convention is verified against the codebase, so it goes through Claude Code. Say that plainly rather than working around it.\n\nTHE DESCRIPTION IS THE WHOLE TRIGGERING MECHANISM — it is how Claude decides to reach for the skill at all, so write when to use it and the words a person would actually say, not a title. It is capped at 1024 characters because claude.ai silently stops triggering a skill whose description is longer.\n\nA SKILL IS NOT A PLACE FOR KNOWLEDGE. Procedure that other skills also need, and every fact about a client, belongs in a note that the skill points at by name — a copy inside a skill drifts from the note and nobody notices. Keep the body to the steps and the judgement calls.\n\nREVISING IS THE SAME TOOL: send the same slug with the whole revised skill and overwrite: true. The first attempt without it hands you back what is there now.", "annotations": { "title": "Write a skill into a plugin", "readOnlyHint": false, "destructiveHint": true, "idempotentHint": false, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "plugin": { "type": "string", "enum": [ "fuel-made-ops", "fuel-made-toolkit", "fuel-made-email-forge" ], "description": "Which plugin the skill belongs to. 'fuel-made-ops' for operations and project-management procedure — SOWs, SOPs, project lifecycle. 'fuel-made-toolkit' for answering questions and client communication; it is installed team-wide, so a skill here reaches everyone. 'fuel-made-email-forge' for the email team's own build procedure." }, "slug": { "type": "string", "description": "Short kebab-case name, used as both the folder name and the skill's name. It is what a person types after a slash, so make it the obvious short phrase for the job (e.g. 'sow-generator')." }, "description": { "type": "string", "description": "When to use this skill and the words someone would say when they want it — this is what makes it trigger, so it matters more than the body. At most 1024 characters." }, "body": { "type": "string", "description": "The skill itself in markdown, WITHOUT frontmatter — the server writes that. Steps, questions to ask, and judgement calls. Point at brain notes by name for anything that is knowledge rather than procedure." }, "overwrite": { "type": "boolean", "description": "Required to replace a skill that already exists. The first attempt without it returns the current version and writes nothing." } }, "required": [ "plugin", "slug", "description", "body" ] } }, { "name": "register_klaviyo_account", "description": "Record which Klaviyo account belongs to a client, once the person has confirmed the account name that was read back to them during setup. That confirmation IS the human judgement this record exists to hold.\n\nWhat it buys: from then on, connecting a different account for that client fails a mechanical check, instead of depending on somebody reading a name carefully while tired. It is the check that stops a template landing in the wrong client's account.\n\nSafe to call again — an entry that already matches changes nothing. A contradiction (this client against a different account, or this account against a different client) is refused rather than resolved, because that is a question for a person.", "annotations": { "title": "Record a client's Klaviyo account", "readOnlyHint": false, "destructiveHint": false, "idempotentHint": true, "openWorldHint": false }, "inputSchema": { "type": "object", "properties": { "client": { "type": "string", "description": "The client's folder name in the brain, kebab-case (e.g. 'wildflower-cases')." }, "account_id": { "type": "string", "description": "The public account id the connection reported — short letters and digits, e.g. 'KS4Rh3'. Not the account's display name, which is what a person reads back and is often not the brand at all." } }, "required": [ "client", "account_id" ] } } ] }