Skip to main content
Glama
Sign In

FoxPlug

by io.github.OsakaSaul
OverviewDiscussionsAdmin

simulate_buyers

Before you merge or ship, ask your buyers. Give the change as the buyer would see it (pricing text, a feature description, launch copy). FoxPlug builds 3 to 5 buyer personas ONLY from evidence the founder already gave it (their site, the feedback requests they connected, what they shipped), each citing its evidence, and returns how each would react: would buy, hesitate or leave, the objection, the exact sentence that confused them and what would change their mind, plus the top objections and a tighter rewrite. It is a SIMULATION, not real customers, and says so. The first simulation per project is free; more need a paid plan. Nothing is posted or changed.

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": {
      "change": "<change>"
    },
    "name": "simulate_buyers"
  }
}

Input Schema

NameRequiredDescriptionDefault
changeYesThe change as a buyer would read it (20 to 4000 characters): the new pricing page text, the feature description or the launch copy.
projectNoThe project this work belongs to — a FoxPlug project name, domain, or repo (e.g. 'foxplug', 'foxplug.com', or 'owner/lcncagents'). Matched case-insensitively against your own FoxPlug projects and any repo/deploy routes. If it can't be resolved, nothing is written (not dropped) and the reply lists your project names so you can retry with an exact one. Optional when you have exactly one FoxPlug project.

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?

Adds substantial context beyond annotations: it is a simulation and says so, personas are grounded in evidence the founder already provided, and the first simulation per project is free while further runs require a paid plan — a real cost/limit disclosure. There is a mild tension between readOnlyHint=false and 'Nothing is posted or changed', and the description never says what, if anything, it persists, which keeps it short of a 5.

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?

Densely packed but front-loaded with the operational instruction, followed by the evidence basis, the return payload, and the caveats. The middle output enumeration runs long as a single breath, but every clause carries information an agent needs.

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?

With no output schema and only two parameters, the description carries the full burden and does: it explains input shape, evidence sourcing, output contents, the simulation disclaimer, and the free/paid boundary. An agent can decide and invoke correctly from this alone.

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%, so both parameters are already documented. The description adds framing for 'change' (pricing text, feature description, launch copy) that mirrors the schema's own wording, but says nothing about 'project' resolution or the single-project default the schema covers.

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?

Names a specific verb and artifact: builds 3–5 buyer personas from evidence and returns how each would react. It goes further to enumerate the return shape (buy/hesitate/leave, the objection, the confusing sentence, top objections, a tighter rewrite), so an agent knows exactly what it gets without opening a schema.

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?

Gives an explicit trigger ('Before you merge or ship, ask your buyers') and tells the caller exactly what input to supply — the change as a buyer would read it. It does not name the sibling tools it should be preferred over (e.g. check_drift, recall), so the when-not 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 FoxPlug toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources