Skip to main content
Glama

claude-faf-mcp

by io.github.Wolfe-Jam
OverviewDiscussionsAdmin

Re-ground on .faf content (drift → refresh → re-grounded)

refresh_faf
Read-onlyIdempotent

Re-ground on .faf content — re-score via the Mk4 Zig-WASM Enterprise scorer (33-slot, honors the authored app-type shape), report drift vs an optional baseline score, and return a stamped re-ground. The explicit re-grounding primitive for long sessions: drift → refresh → re-grounded. Built for Grok, by request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesRaw .faf YAML content to re-ground on.
baselineNoOptional last-known score (0-100). When provided, the drift delta (current - baseline) is reported.
verbatimNoWhen true, return the full .faf content verbatim with the stamp. Default false (stamped delta + summary).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "content": {
-      "items": {
-        "properties": {
-          "text": {
-            "description": "Human-readable tool result.",
-            "type": "string"
-          },
-          "type": {
-            "const": "text",
-            "type": "string"
-          }
-        },
-        "required": [
-          "type",
-          "text"
-        ],
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "isError": {
-      "description": "True when the tool failed.",
-      "type": "boolean"
-    }
-  },
-  "required": [
-    "content",
-    "isError"
-  ],
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "content": {
+      "items": {
+        "properties": {
+          "text": {
+            "description": "Human-readable tool result.",
+            "type": "string"
+          },
+          "type": {
+            "const": "text",
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "text"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "isError": {
+      "description": "True when the tool failed.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "content",
+    "isError"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

With annotations already covering read-only, idempotent, and non-destructive behavior, the description adds useful context: re-scoring via the Mk4 scorer, honoring the authored app-type shape, optional drift delta, and stamped vs verbatim output. It could be clearer about exactly what the 'stamp' contains, but the annotations do not carry that burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is dense and informative, but the second sentence partly repeats the title and process, and the final 'Built for Grok, by request' adds no operational value. The description remains compact but not every sentence earns its place.

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?

Given no output schema, the description sufficiently sketches the shape for both default verbatim and non-verbatim mode: stamped delta+summary vs full content verbatim plus stamp. It supports agent deciscion-making on when to call it in long sessions, and the schema and annotations cover the remaining invocation details.

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%, and the parameter descriptions are already clear about content, baseline drift, and verbatim mode. The tool description mostly rephrases those concepts without adding deeper semantics, which is acceptable at the baseline for fully documented schemas.

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?

States a specific operation: re-ground on .faf content, re-score via a named scorer, report drift against baseline, return a stamped re-ground. The 'explicit re-grounding primitive for long sessions' differentiates it from a plain first-time scoring tool and from the sibling search/analysis 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?

Gives a clear 'when' — any long session where drift needs to be reset via refresh/re-ground. It does not name alternative tools or say when not to use it, so it stops short of explicit when-not/alternatives guidance.

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

All claude-faf-mcp 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