Skip to main content
Glama
Sign In
paa-guard mcp

paa-guard mcp

by kenhuangus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

paa_guard_check

Check a proposed action against the owner's PAA10 guard before execution to get an allow, require_approval, or deny verdict and prevent unauthorized actions.

Instructions

Check a proposed action against the owner's PAA10 guard BEFORE doing it. Returns allow, require_approval (stop and tell the owner the approval id; retry with approval_token after they approve) or deny (do not attempt the action another way). See the paa10-guard skill for the action fields.

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": {
      "action": "<action>"
    },
    "name": "paa_guard_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesNormalized PAA action

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations exist, so the description must carry behavioral load, and it does: it enumerates all three return states and prescribes the multi-step approval flow including the token retry. It does not state whether the check itself is read-only, what permissions it needs, or how much latency/state it creates.

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?

Three compact sentences with no filler: purpose and timing first, then the decision branches and required follow-up for each, then the pointer to field documentation. The most important constraint (check before acting) is front-loaded.

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?

For a one-parameter gate tool with no output schema, the description covers what an agent must know: when to call, what each result means, and the approval round-trip. The only gap is the undefined action fields, which is explicitly routed to the skill.

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 nominally 100%, but the single nested 'action' object has no defined properties, and the description defers field details entirely to 'the paa10-guard skill'. That cross-reference is useful signposting but leaves the agent dependent on external documentation for the actual payload shape.

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?

States a specific verb ('Check') and resource ('a proposed action against the owner's PAA10 guard'), plus a temporal constraint ('BEFORE doing it'). The verb/resource pair clearly separates it from siblings like paa_guard_remember and paa_guard_status, though no sibling is named explicitly.

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 strong usage rule ('BEFORE doing it') and per-outcome instructions: on require_approval stop and surface the approval id, then retry with approval_token; on deny do not attempt the action another way. It stops short of naming the sibling tools or stating when to skip this check entirely.

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