AGA-mcp-server

measure_behavior

Records and proves behavioral drift in AI agent actions using tamper-evident attestation. Optionally enforces phantom quarantine on pattern violations.

Instructions

Measure behavioral patterns (unauthorized tools, rate violations, forbidden sequences). DETECTIVE-ONLY by default: it records and PROVES drift but does not block. Pass enforce=true to also trip the portal into phantom quarantine on drift (opt-in; off by default). (NIST-2025-0035)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "measure_behavior"
  }
}

Input Schema

Name	Required	Description	Default
`enforce`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.1Jul 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the detective-only default, that it records and proves drift but does not block, and that enforce=true triggers phantom quarantine. It could elaborate on what 'phantom quarantine' entails, but it's sufficiently transparent.

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?

The description is two sentences, front-loaded with purpose and followed by details on default behavior and enforce option. Every sentence adds value with no wasted words.

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 tool with one parameter and no output schema, the description covers purpose, default behavior, and the enforce option. It does not describe the output or what triggers measurement, but it is fairly complete given the context. A brief mention of output would improve completeness.

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

Parameters5/5

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

The schema provides only the parameter name and type with 0% coverage. The description adds valuable meaning: it explains that enforce (boolean, default false) opts in to phantom quarantine on drift. This fully compensates for the schema's lack of description.

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 clearly states the tool measures behavioral patterns (unauthorized tools, rate violations, forbidden sequences) and distinguishes itself from sibling tools by highlighting 'DETECTIVE-ONLY' default behavior and an optional enforce parameter for quarantine.

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?

The description explains when to use the tool (for detecting behavioral drift) and how to opt into enforcement via enforce=true. It does not explicitly state when not to use it or compare to siblings like measure_integrity, but the context is clear.

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

Deploy Server