Skip to main content
Glama
Sign In

Fudge for Shopify

by ai.fudge
OverviewDiscussionsAdmin

Remember for this store

remember

Save a lasting rule, decision, correction or learning to store memory. Use when the user states how things should be done from now on, not for one-off requests. Duplicates change nothing; a contradiction comes back as a conflict.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "note": "<note>"
    },
    "name": "remember"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteYesThe lasting rule, decision or learning to keep, written as it should apply in future work, with its conditions, exceptions and reason. Not a one-off task or a detail of the current draft.
storeNoThe connected store to use. Omit when only one is connected.
personalNoSave only for the person you are serving: how to work with them (language, tone, length, what to ask them). Default: shared with everyone working on this store. Never put a person's private details in shared memory.
replacesNoThe user explicitly corrected or reversed an earlier rule. Replace the old rule instead of returning a conflict.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses two non-obvious behaviors: duplicate submissions are no-ops and contradictions surface as a conflict rather than silently overwriting. There is mild tension with idempotentHint=false ('duplicates change nothing' reads as dedup semantics, which usually implies idempotency), though this can be reconciled as content-level dedup versus call-level repeatability; the description also omits any mention of a required store connection.

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?

Three short sentences with the action and content type front-loaded, then the usage condition, then the edge-case behavior. No filler and nothing could be removed without losing a decision-relevant fact.

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?

For a four-parameter write tool with no output schema, the definition covers what to save, when to save it, and what happens on duplicates or contradictions. What is missing is only peripheral: prerequisite connection state and the shape of a successful response, neither of which would change how an agent calls it.

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?

Schema coverage is 100% and the parameter descriptions are already rich (including the personal/shared distinction and the replaces correction path), so the description does not need to carry parameter detail. It adds only the implicit framing of 'lasting rule' versus 'one-off', which reinforces the note parameter but adds nothing the schema does not already say.

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 opens with a specific verb and resource ('Save a lasting rule, decision, correction or learning to store memory') and enumerates exactly what kind of content belongs in memory. This is unmistakably distinct from the other siblings, which are retrieval, audit, and draft-creation tools.

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?

It gives a concrete triggering condition ('the user states how things should be done from now on') and an explicit exclusion ('not for one-off requests'), which is precisely the decision boundary an agent needs. It stops short of naming an alternative tool for the one-off case, so the routing half of the guidance is inferred rather than stated.

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

All Fudge for Shopify toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources