Skip to main content
Glama
Sign In

FoxPlug

by io.github.OsakaSaul
OverviewDiscussionsAdmin

record_work

Record a build-work summary into FoxPlug as a milestone (source: Claude Code). Call this at the end of a session. It captures what you shipped so FoxPlug can score it and surface the shippable moments in your Radar. It never posts anything. Free — capture is not metered. Do NOT include secrets, keys, or tokens in the summary.

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": {
      "project": "<project>",
      "summary": "<summary>"
    },
    "name": "record_work"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectYesThe 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.
summaryYesA short human summary of what you built or changed this session (1-3 sentences). No secrets.
decisionsNoOptional. Notable decisions or trade-offs made this session (1-2 sentences).
files_touchedNoOptional. Key file paths changed this session — context only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only reveal that this writes without being destructive; the description adds genuinely new traits: nothing is ever posted publicly, the capture is unmetered (free), and secrets/keys/tokens must be excluded. The unresolved-project behavior is stated in the schema rather than the description, so it isn't double-counted here.

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?

Five short sentences, front-loaded with the purpose, followed by timing, side-effect guarantees, cost, and a safety warning — every sentence carries information. The Radar/scoring sentence is slightly promotional but still conveys what happens to the captured data.

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?

With no output schema, the description does explain the downstream effect (scoring and Radar surfacing), and the schema covers the failure reply shape for unresolvable projects. A reader still isn't told whether the call succeeds silently or returns a milestone identifier, which is a minor gap for a write tool.

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 description coverage is 100%, so the schema already explains all four parameters, including the case-insensitive project matching and the optional decisions/files_touched fields. The description only reinforces the "no secrets" constraint on summary, adding no further parameter-level meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource — recording a build-work summary into FoxPlug as a milestone — and states the source (Claude Code) and lifecycle point (end of session). It does not explicitly distinguish itself from a plausibly similar sibling such as log_update, so it falls short of a 5.

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?

"Call this at the end of a session" gives concrete when-to-use guidance, and the scoping to shipped work is clear. There are no explicit when-not-to-use conditions or named alternatives, so an agent must infer that log_update or set_plan serve other purposes.

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