Skip to main content
Glama
Sign In
joinwell52-AI

fcop-mcp

by joinwell52-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mark_human_approved

Append independent human authorization evidence to a review record for stage decisions, requiring explicit expiry and Core validation—caller-supplied approver text alone is not authority.

Instructions

Ask Core to append independent authorization evidence. Caller-supplied approver text alone is never authority; expires_at must be explicit.

Input Schema

NameRequiredDescriptionDefault
commentNo
approverYes
decisionYes
to_stageYes
issued_atYes
review_idYes
attempt_idNo
expires_atYes
from_stageYes
profile_refYes
issuer_proofNo
family_digestNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv4.0.5
    • removedInput schema / properties / approver / description
      Removed value: -"Role code of the human approver. MUST be an agent\nwith ``layer: admin`` (e.g. ``ADMIN``)."
    • addedInput schema / properties / attempt_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • removedInput schema / properties / channel
      Removed value: -{
-  "default": "cli",
-  "description": "Channel through which the approval was submitted.\nOne of ``mobile`` / ``cli`` / ``web`` / ``manual_file_edit``.\nDefault: ``cli``.",
-  "type": "string"
-}
    • removedInput schema / properties / comment / description
      Removed value: -"Optional free-text comment from the approver."
    • removedInput schema / properties / decision / description
      Removed value: -"Human's binary decision: ``approve`` or ``reject``."
    • addedInput schema / properties / expires_at
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • addedInput schema / properties / family_digest
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • addedInput schema / properties / from_stage
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / issued_at
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / issuer_proof
      Added value: +{
+  "default": null,
+  "title": "Issuer Proof"
+}
    • addedInput schema / properties / profile_ref
      Added value: +{
+  "type": "string"
+}
    • removedInput schema / properties / review_id / description
      Removed value: -"The stable review ID — filename stem without ``.md``\n(e.g. ``REVIEW-20260510-001-ADMIN-on-some-task``)."
    • addedInput schema / properties / to_stage
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "review_id",
-  "approver",
-  "decision"
-]New value: +[
+  "review_id",
+  "decision",
+  "approver",
+  "profile_ref",
+  "from_stage",
+  "to_stage",
+  "issued_at",
+  "expires_at"
+]
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. First observedv3.2.4

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description usefully discloses a security-critical behavior: caller-supplied approver text alone is never authority, and expires_at must be explicit. However, it does not describe whether this is a write operation, what permissions or issuer evidence are required, what side effects occur, or what is returned, leaving important behavioral gaps.

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?

The description is compact and front-loads the action before adding two critical constraints. Both sentences carry weight, though the second is terse and somewhat cryptic for a tool with 8 required parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, 8-required mutation-style tool with no annotations and no output schema, the description is far too incomplete. It highlights authority and expiry semantics but leaves most required parameters and the overall approval workflow unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 12 parameters, so the description must carry parameter semantics. It only adds meaning for two fields, approver and expires_at, and gives no explanation of required fields such as review_id, decision, profile_ref, from_stage, to_stage, or issued_at.

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

Purpose3/5

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

The description gives a specific but unusually abstract action: 'Ask Core to append independent authorization evidence.' It is not a tautology, but it never plainly says this marks a human approval or explains how it differs from sibling tools like approve_task, so the agent must infer the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no mention of alternatives such as approve_task or reject_task. The description provides constraints on authority and expiry, but it does not tell the agent when this tool should be selected over its siblings.

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

Deploy Server

Other Tools