What can you do with this server?

The SINT Protocol server is a security-first governance layer for physical AI systems, providing secure delegation, human oversight, and tamper-evident auditing of AI agent actions. System Monitoring & Status * sint__status — Check system health, connected servers, and queue size * sint__servers — List downstream MCP servers with connection status and health metrics * sint__whoami — View current agent identity, public key, active token, and session info Approval Workflow * sint__pending — List pending escalated actions awaiting human review * sint__approve / sint__deny — Approve or deny pending actions by request ID with audit trails Audit & Compliance * sint__audit — Query the SHA-256 hash-chained evidence ledger for recent policy decisions and events; aligned with IEC 62443, EU AI Act Article 13, and NIST AI RMF Server Management * sint__add_server / sint__remove_server — Dynamically add or remove downstream MCP servers at runtime Capability Token Administration * sint__issue_token — Issue scoped Ed25519-signed capability tokens with defined resources, actions, and expiry * sint__revoke_token — Revoke an active capability token * sint__delegate_to_agent — Issue attenuated tokens to sub-agents (max depth 3) * sint__list_delegations — View the active delegation tree rooted at the current operator token * sint__revoke_delegation_tree — Cascade-revoke an entire delegation subtree Operator Interface Controls * sint__interface_status — Get current operator interface state (mode, HUD panels, memory, session) * sint__interface_mode — Switch display mode: hud, compact, voice-only, or silent * sint__speak — Schedule TTS voice output to the operator with priority levels * sint__show_hud — Update HUD panels (approvals, audit, context, or memory) * sint__notify — Send proactive notifications, optionally with actionable buttons Memory Bank * sint__store_memory — Store keyed entries with optional tags and session persistence * sint__recall_memory — Search the memory bank for entries matching a query string

de en es ja ko ru zh

SINT Protocol

by sint-ai

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

The SINT Protocol server is a security-first governance layer for physical AI systems, providing secure delegation, human oversight, and tamper-evident auditing of AI agent actions.

System Monitoring & Status

sint__status — Check system health, connected servers, and queue size
sint__servers — List downstream MCP servers with connection status and health metrics
sint__whoami — View current agent identity, public key, active token, and session info

Approval Workflow

sint__pending — List pending escalated actions awaiting human review
sint__approve / sint__deny — Approve or deny pending actions by request ID with audit trails

Audit & Compliance

sint__audit — Query the SHA-256 hash-chained evidence ledger for recent policy decisions and events; aligned with IEC 62443, EU AI Act Article 13, and NIST AI RMF

Server Management

sint__add_server / sint__remove_server — Dynamically add or remove downstream MCP servers at runtime

Capability Token Administration

sint__issue_token — Issue scoped Ed25519-signed capability tokens with defined resources, actions, and expiry
sint__revoke_token — Revoke an active capability token
sint__delegate_to_agent — Issue attenuated tokens to sub-agents (max depth 3)
sint__list_delegations — View the active delegation tree rooted at the current operator token
sint__revoke_delegation_tree — Cascade-revoke an entire delegation subtree

Operator Interface Controls

sint__interface_status — Get current operator interface state (mode, HUD panels, memory, session)
sint__interface_mode — Switch display mode: hud, compact, voice-only, or silent
sint__speak — Schedule TTS voice output to the operator with priority levels
sint__show_hud — Update HUD panels (approvals, audit, context, or memory)
sint__notify — Send proactive notifications, optionally with actionable buttons

Memory Bank

sint__store_memory — Store keyed entries with optional tags and session persistence
sint__recall_memory — Search the memory bank for entries matching a query string

References academic papers from arXiv as part of the SINT Protocol's academic grounding and evaluation framework, including the ROSClaw empirical safety study and MCP security analysis.

Provides containerized deployment options for the SINT MCP server with Dockerfiles and Docker Compose profiles for development, edge, production, and simulation environments.

Hosts the SINT Protocol repository with CI/CD workflows, community documentation, and security bulletins as part of the open-source collaboration infrastructure.

Provides CI/CD workflows for the SINT Protocol repository, including automated testing, documentation deployment, and quality assurance processes.

Integrates with Google A2A (Agent-to-Agent) protocol through the SINT Bridge Layer for secure communication between AI agents in physical AI systems.

Provides MQTT Sparkplug bridge for Industrial IoT integration, enabling secure communication with MQTT-based industrial automation systems through the SINT Protocol.

Provides the runtime environment for the SINT MCP server with Node.js >= 22 requirement for executing the protocol's security and governance functions.

Hosts the SINT MCP server package for installation via npx, enabling easy deployment and execution of the SINT Protocol's governance layer.

Provides comprehensive coverage of OWASP ASI01-ASI10 security requirements for AI systems as part of SINT's security framework for physical AI.

Used as the package manager for the SINT Protocol workspace, enabling efficient dependency management and workspace operations for the monorepo structure.

Provides persistent storage for the SINT Operator Interface and other components, supporting ledger-backed persistent context and system state management.

Provides in-memory data storage for the SINT Operator Interface stack, supporting real-time operations and caching for the governance system.

Provides ROS 2 bridge integration for robotic systems, enabling secure communication with ROS topics and nodes through the SINT Protocol's governance layer.

Provides the primary implementation language for the SINT Protocol with TypeScript 5.7, ensuring type safety and maintainability for the security-critical codebase.

Powers the SINT Protocol documentation site with VitePress, providing developer documentation, community guides, and security bulletins.

Provides schema validation for the SINT Policy Gateway, ensuring type-safe validation of SintRequest objects and security policy enforcement.

SINT Protocol

Node.js TypeScript License

Glama

Open-source runtime security and governance for AI agents, MCP tools, robotics, industrial automation, and physical AI.

Mission Authority: SINT also provides a hardware-agnostic authority and evidence protocol for autonomous air, ground, maritime, and robotic systems. It binds platform identity, mission scope, operator authorization, abort behavior, and signed after-action evidence without selecting targets or generating effects. See docs/mission-authority.md.

SINT Protocol is an open protocol and TypeScript reference stack that sits between AI agent intent and real-world execution. Before a governed tool call, robot command, industrial write, payment-like action, or actuator movement can run, the request passes through PolicyGateway.intercept() for capability-token authorization, T0-T3 approval tiering, physical constraint enforcement, revocation checks, and tamper-evident evidence logging.

What is SINT Protocol?

SINT is an AI agent security control plane for actions with real-world consequence. It helps teams answer four questions before an autonomous system acts:

Who is allowed to act? Ed25519 capability tokens bind issuer, subject, resource, action, expiry, constraints, and delegation chain.
What constraints apply? Velocity, force, geofence, budget, rate-limit, and consent constraints travel with the token instead of living in ad hoc config.
When is human review required? T0-T3 approval tiers route low-risk actions automatically and escalate physical or irreversible actions to operators.
How do you prove what happened? Every decision can be written to a SHA-256 hash-chained EvidenceLedger with portable proof receipts.

Related MCP server: Semgrep MCP Server

Where SINT Fits

SINT is not a replacement for MCP, A2A, ROS 2, MAVLink, MQTT, OPC UA, Open-RMF, or industrial robot tooling. It is the enforcement layer in front of those systems:

MCP security: authorize tool calls before an MCP server executes them.
Agent runtime governance: add pre-tool authorization, typed deny/escalate outcomes, and evidence references to agent frameworks.
Robotics and drones: enforce ROS 2, MAVLink, PX4, and fleet actions with physical constraints and e-stop semantics.
Industrial automation: govern OPC UA, MQTT/Sparkplug, SRCI, simulator, and offline robot-program paths before PLC or robot actions touch equipment.
Consumer and regulated data: apply consent, caregiver delegation, differential privacy, and audit exports for smart-home and health workflows.

Latest Implementation Highlights

Installable MCP proxy: npx -y sint-mcp --stdio runs the security-first multi-MCP proxy.
Industrial humanoid shipyard safety: executable conformance fixtures now cover Persona-style shipyard humanoid welding, hot-work permits, fire watch, fume extraction, confined-space gas safety, bystander escalation, simulation-to-execution drift, material load envelopes, and unconditional e-stop rollback.
Shipyard bridge and evidence scaffolding: ROS 2 weld-start profile helpers, OPC UA safety-signal mappings, Isaac Sim receipt stubs, and sintctl shipyard evidence export generate hash-chained JSONL evidence for supervisor review, remote survey support, and incident reconstruction.
Agent commerce governance: the Economic Layer now includes a conformance profile for agent-to-agent task markets: task creation, bids, worker selection, benchmark-proof submission, settlement release, and x402-style payment permits.
Five-minute interceptor demo: pnpm run demo:interceptor-quickstart shows request -> decision -> receipt and the fail-closed path.
Production gateway posture: production mode requires durable stores, explicit authentication, readiness checks, and signature enforcement.
Industrial action pack: pnpm run demo:factory-action and pnpm run demo:industrial-pack verify deny, escalate, approve, simulate, and receipt-chain flows before vendor adapter execution.
Autonomy supervisor: @pshkv/autonomy-supervisor adds an authority lane for managed autonomy: stable -> metacognitive_recovery -> assisted_recovery -> regulated_control.
External evidence packets: OWASP Agentic AI landscape, MITRE ATLAS candidate mappings, AAIF RFC-001 packet, NIST bundle, dependency review, and production-slice validation artifacts are published under docs/.

Academic and compliance grounding: SINT is designed with reference to IEC 62443 FR1-FR7, EU AI Act Article 13, and NIST AI RMF. The evaluation framework references the ROSClaw empirical safety study (arXiv:2603.26997) and MCP security analysis (arXiv:2601.17549).

Agent ──► SINT Bridge ──► Policy Gateway ──► Allow / Deny / Escalate
                               │
                       Evidence Ledger (SHA-256 hash-chained)
                               │
                    ProofReceipt (pluggable attestation)

Install the MCP server

The installable server entrypoint is sint-mcp.

npx -y sint-mcp --stdio
npx -y sint-mcp --config ./sint-mcp.config.example.json --stdio

If you prefer containers, build and run the repo root Dockerfile:

docker build -t sint-mcp .
docker run --rm -i sint-mcp

Try the interceptor flagship in 5 minutes

If you want the fastest builder-facing path into the SEP-1763 interceptor work:

pnpm install
pnpm run build
pnpm run demo:interceptor-quickstart

That walkthrough shows the full flagship loop in one terminal transcript:

MCP-style request enters the interceptor
SINT returns allow or escalate
an audit receipt is generated for the allowed path
execution fail-closes when a gate prerequisite is missing

Start here:

Production-Ready Core

For production deployments, SINT now fails closed unless the gateway is started with durable stores and explicit authentication:

SINT_ENV=production
SINT_STORE=postgres
SINT_CACHE=redis
DATABASE_URL=postgresql://...
REDIS_URL=redis://...
SINT_API_KEY=...
SINT_REQUIRE_SIGNATURES=true
SINT_WS_ALLOW_QUERY_API_KEY=false

Use /v1/ready as the orchestration health gate; it verifies the configured store and cache, while /v1/health only proves the process is alive.

Production references:

Why SINT?

AI agents now execute code, call tools, move money, operate robots, control smart-home devices, and interact with industrial systems. The risk is no longer only prompt quality; it is whether the runtime has a verifiable control point between "the model decided" and "the world changed."

SINT makes that control point explicit. It turns agent execution into a governed workflow with scoped authority, pre-action policy evaluation, operator review, physical limits, revocation, and audit evidence.

Capability Coverage

Capability	SINT Protocol	Microsoft AGT	MCP Baseline	SROS2
Physical constraint enforcement (velocity, force, geofence)	✅ In token	❌	❌	❌
Tier-based human oversight (T0–T3)	✅ 4-tier	⚠️ Execution rings	❌	❌
Append-only hash-chained audit	✅ SHA-256	⚠️ Logging	❌	❌
ROS 2 / MAVLink / industrial bridges	✅ 12 bridges	❌ Digital only	❌	⚠️ ROS only
Consumer smart home governance	✅ Home Assistant + Matter	❌	❌	❌
HIPAA + GDPR health data access	✅ FHIR + HealthKit	❌	❌	❌
OWASP ASI01–ASI10 coverage	✅ 10/10 Full	✅ 10/10	❌	❌
Economic routing + budgets	✅ bridge-economy	❌	❌	❌
Swarm collective constraints	✅ SwarmCoordinator	❌	❌	❌
E-stop / CircuitBreaker	✅ EU AI Act Art. 14	✅ Kill switch	❌	❌
Caregiver delegation + consent	✅ FHIR Consent tokens	❌	❌	❌
Differential privacy ledger	✅ Per-query epsilon budget	❌	❌	❌

SINT is designed for physical AI and regulated data workflows where actions can be irreversible: robots, drones, smart homes, health fabric, industrial control, and critical infrastructure. Microsoft AGT focuses on digital/software governance patterns; SINT focuses on pre-action enforcement across tool, robotics, and industrial execution boundaries.

The empirical case for SINT:

ROSClaw (IROS 2026): Up to 4.8× spread in out-of-policy LLM action proposals across frontier models under identical safety envelopes. The 3.4× divergence between frontier backends is measurable, reproducible, and persistent.
MCP security (arXiv:2601.17549): 10 documented real-world MCP breaches in under 8 months, including a CVSS 9.6 command injection affecting 437,000 downloads.
SROS2: Formally demonstrated to contain 4 critical vulnerabilities at ACM CCS 2022, including access-control bypasses permitting arbitrary command injection.
Unitree BLE worm (September 2025): Hardcoded crypto keys enabled wormable BLE/Wi-Fi command injection across robot fleets — precisely the scenario SINT's per-agent token scoping and real-time revocation prevent.

Core guarantees:

No agent action ever bypasses the Policy Gateway (invariant I-G1: No Bypass)
Every decision is recorded in a tamper-evident SHA-256 hash-chained ledger (invariant I-G3: Ledger Primacy)
Physical constraints (velocity, force, geofence) are enforced at the protocol level — in the token, not in config
Tier-gated verifiable compute hooks support provable-execution evidence on critical actions
E-stop is universal across all non-terminal DFA states (invariant I-G2: E-stop Universality)
Per-agent capability tokens with real-time revocation

Quick Start

# Prerequisites: Node.js >= 22, pnpm >= 9
pnpm install
pnpm run build
pnpm run test        # full workspace test suite

Start the Gateway Server

pnpm --filter @sint/gateway-server dev
# → http://localhost:3100/v1/health
# → http://localhost:3100/v1/ready
# → http://localhost:3100/v1/docs

Start Production-Like Stacks (One Command)

pnpm run stack:dev
pnpm run stack:edge
pnpm run stack:prod-lite
pnpm run stack:gazebo-validation
pnpm run stack:isaac-sim-validation

Compose profiles:

Developer Docs Site (`docs.sint.gg`)

pnpm run docs:dev
pnpm run docs:build
pnpm run docs:preview

Docs source lives in docs/, VitePress config is in docs/.vitepress/config.mts, and deployment is handled by docs-site.yml.

Deploy note:

branch builds validate docs locally and in CI
public docs.sint.gg deployment publishes from main under GitHub Pages environment rules

Community/adoption assets:

Run a Single Package

pnpm --filter @sint/gate-policy-gateway test
pnpm --filter @sint/bridge-mcp test

Consumer Domains: Smart Home & Health

SINT extends far beyond industrial robotics. Two major consumer domains now have governance frameworks:

Consumer Smart Home (Home Assistant + Matter)

AI agents accessing your smart home go through the Policy Gateway:

import { HAInterceptor } from "@sint/bridge-homeassistant";

const interceptor = new HAInterceptor({
  policyGateway,
  homeAssistantHost: "homeassistant.local",
});

// Claude says: "unlock the front door"
const result = await interceptor.intercept({
  toolName: "call_service",
  toolInput: { domain: "lock", service: "unlock", entity_id: "lock.front_door" },
});
// → Escalates to T2_ACT (requires human approval)
// → Evidence Ledger records the decision and outcome

Tier-appropriate defaults:

T0 (OBSERVE): Security cameras, sensors (read-only, no facial recognition)
T1 (PREPARE): Lights, thermostats, media players (logged auto-allow)
T2 (ACT): Smart locks, garage doors, alarms (requires approval)
T3 (COMMIT): Create/modify automations (mandatory human review)

See packages/bridge-homeassistant and packages/bridge-matter.

Health Fabric (FHIR + HealthKit/Health Connect)

Patient data accessed by AI agents goes through consent-based governance:

import { createFHIRConsentToken } from "@sint/bridge-health";

// Patient grants AI agent 7-day read access to health observations
const consentToken = createFHIRConsentToken(
  "did:key:patient123",   // grantor (patient)
  "did:key:aiagent456",   // grantee (AI agent)
  ["Observation", "DiagnosticReport"],
  ["read"],
  new Date(Date.now() + 7 * 24 * 60 * 60 * 1000),
  { scope: "patient-privacy", purposeOfUse: ["TREAT"] }
);

await policyGateway.issueToken(consentToken);

Civil liberties guarantees:

On-device first: Raw sensor data (heart rate, blood pressure) stays on device; only aggregates egress
Differential privacy: Every query consumes an epsilon budget; exhausted budget = no more access
Caregiver delegation: Elderly parent grants adult child 30-day, revocable access to health data
HIPAA + GDPR: Consent tokens, user-owned keys, audit ledger export for patient access rights

See packages/bridge-health and the consumer smart home integration guide.

SINT Operator Interface

A voice-first, HUD-based control surface for SINT operators. Every command flows through the Policy Gateway.

pnpm run stack:interface  # starts gateway + interface + postgres + redis
# Opens: http://localhost:3202

Features:

Voice input: Web Speech API, zero external dependencies, real-time transcript
Command HUD: three-panel approvals, action stream, and context view
Operator memory: ledger-backed persistent context (@sint/memory)
Proactive notifications: sint__notify runs as T2 and requires confirmation
T2/T3 approvals: one-click approve/deny with timeout countdown

See docs/guides/sint-interface.md for full setup and usage.

For AI Agents

If you are an AI agent (Claude, GPT, Gemini, Cursor, etc.) working in this repo, read AGENTS.md first. It covers key invariants, common mistakes, and entry points for the most common tasks. For deeper implementation details, see CLAUDE.md.

Architecture

┌──────────────────────────────────────────────────────────────┐
│  AI Agents / Foundation Models                               │
│  (Claude, GPT, Gemini, open-source)                         │
└──────────────────┬───────────────────────────────────────────┘
                   │
┌──────────────────▼───────────────────────────────────────────┐
│  SINT Bridge Layer (L1)                                      │
│  ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────┐  │
│  │ bridge-mcp │ │ bridge-ros2│ │ bridge-a2a │ │ bridge-  │  │
│  │ MCP tools  │ │ ROS topics │ │ Google A2A │ │ open-rmf │  │
│  └────────────┘ └────────────┘ └────────────┘ └──────────┘  │
│  ┌──────────────────────┐ ┌───────────────────────────────┐  │
│  │ bridge-mqtt-sparkplug│ │ bridge-opcua                  │  │
│  │ Industrial IoT       │ │ PLC / OT control plane bridge │  │
│  └──────────────────────┘ └───────────────────────────────┘  │
│  Per-resource state: UNREGISTERED→PENDING_AUTH→AUTHORIZED    │
│  →ACTIVE→SUSPENDED (real-time revocation without restart)    │
└──────────────────┬───────────────────────────────────────────┘
                   │ SintRequest (UUIDv7, Ed25519, resource, action, physicalContext)
┌──────────────────▼───────────────────────────────────────────┐
│  SINT Gate (L2) — THE choke point                           │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │  PolicyGateway.intercept()                              │ │
│  │  1. Schema validation (Zod)                             │ │
│  │  2. Token validation (Ed25519 + expiry + revocation)    │ │
│  │  3. Resource scope check                                │ │
│  │  4. Per-token rate limiting (sliding window)            │ │
│  │  5. Physical constraint enforcement                     │ │
│  │  6. Forbidden action sequence detection                 │ │
│  │  7. Tier assignment: max(BaseTier, Δ_human, Δ_trust...) │ │
│  │  8. T2/T3 → escalate to approval queue                 │ │
│  │  9. T0/T1 + approved T2/T3 → allow                     │ │
│  │  10. Bill via EconomyPlugin (if configured)             │ │
│  └─────────────────────────────────────────────────────────┘ │
│                          ↓                                   │
│  EvidenceLedger (SHA-256 hash chain + ProofReceipt)        │
└──────────────────────────────────────────────────────────────┘

APS vs SINT Primitives

APS Concept	SINT Implementation
Principal	`agentId` (Ed25519 public key) + W3C DID identity
Capability	`SintCapabilityToken` (Ed25519-signed, scoped, attenuatable)
Authority	`PolicyGateway.intercept()` — single choke point
Confinement	Per-token resource scope + physical constraints (velocity, force, geofence)
Revocation	`RevocationStore` + ConsentPass endpoint (real-time)
Audit	`EvidenceLedger` — append-only, SHA-256 hash-chained

Packages

Gate (Security Core)

Package	Description	Tests
`@sint/core`	Types, Zod schemas, tier constants, formal DFA states	—
`@sint/gate-capability-tokens`	Ed25519 tokens, delegation, W3C DID identity	55
`@sint/gate-policy-gateway`	Authorization engine: tiers, constraints, rate limiting, M-of-N quorum	256
`@sint/gate-evidence-ledger`	SHA-256 hash-chained append-only audit log with pluggable attestation	45

Bridges (15 bridges)

Industrial & Robotics (9)

Package	Description	Tests
`@sint/bridge-mcp`	MCP tool call interception and risk classification	66
`@sint/bridge-ros2`	ROS 2 topic/service/action interception with physics extraction	20
`@sint/bridge-a2a`	Google A2A Protocol bridge for multi-agent coordination	38
`@sint/bridge-iot`	Generic MQTT/CoAP edge IoT bridge with gateway session interception	21
`@sint/bridge-mqtt-sparkplug`	MQTT Sparkplug profile mapping with industrial command tiering defaults	8
`@sint/bridge-opcua`	OPC UA node/method mapping with safety-critical write/call promotion	6
`@sint/bridge-open-rmf`	Open-RMF fleet/facility mapping for warehouse dispatch workflows	5
`@sint/bridge-grpc`	gRPC service/method profile mapping with default tier assignment	5
`@sint/bridge-mavlink`	MAVLink drone/UAV command bridge	15

Coordination & Economics (2)

Package	Description	Tests
`@sint/bridge-economy`	Economy bridge: balance, budget, trust, billing ports	47
`@sint/bridge-swarm`	Multi-robot swarm coordination bridge	9

Consumer & Health (3) — Phase 1-5 Physical AI Governance

Package	Description	Tests
`@sint/bridge-homeassistant`	Consumer smart home MCP interceptor with device profiles (locks, cameras, alarms, climate, vacuums) — Phase 1	36
`@sint/bridge-health`	FHIR R5 + HealthKit/Health Connect with differential privacy, consent tokens, and caregiver delegation — Phase 5	—
`@sint/bridge-matter`	Matter protocol bridge for unified smart home device governance — Phase 2	—

Note: some consumer/health bridges are currently in “prototype API” state. CI may temporarily skip their build/typecheck/test scripts until their public interfaces are aligned with the @sint/core request/decision model.

Reference Implementation (1)

Package	Description	Tests
`@sint/sint-pdp-interceptor`	Reference SEP-1763 PDP adapter for MCP interceptor hosts backed by `PolicyGateway.intercept()`	5

Engine (AI Execution Layer)

Package	Description	Tests
`@sint/engine-system1`	Neural perception: sensor fusion, ONNX inference, anomaly detection	42
`@sint/engine-system2`	Symbolic reasoning: behavior trees, task planning, System 1/2 arbitration	86
`@sint/engine-hal`	Hardware Abstraction Layer: auto-detect hardware, select deployment profile	26
`@sint/engine-capsule-sandbox`	WASM/TS capsule loading, validation, and sandboxed execution	36
`@sint/avatar`	Avatar Layer (L5): behavioral identity profiles, CSML-driven tier escalation	25

Reference Capsules

Package	Description	Tests
`@sint/capsule-navigation`	Waypoint following navigation reference capsule	11
`@sint/capsule-inspection`	Visual anomaly detection for manufacturing QA	8
`@sint/capsule-pick-and-place`	Gripper control for pick-and-place tasks	12

Persistence

Package	Description	Tests
`@sint/persistence`	Storage interfaces + in-memory/PG/Redis implementations	26
`@sint/persistence-postgres`	Production PostgreSQL adapters for ledger, revocation, and rate-limit durability	14

Apps & SDKs

Package	Description	Tests
`@sint/gateway-server`	Hono HTTP API with approvals, SSE streaming, A2A routes	—
`sint-mcp`	Security-first multi-MCP proxy server	—
`@sint/interface`	Voice HUD and Conductor approvals for operator review	25
`@sint/dashboard`	Archived real-time approval dashboard with operator auth	29
`@sint/client`	TypeScript SDK for the Gateway API (delegation, SSE)	—
`@sint/sdk`	Zero-dependency public TypeScript SDK aligned to gateway v0.2 contracts	9
`@sint/conformance-tests`	Security regression suite — all phases	—

Total: 49 repo packages, apps, examples, and capsules · CI-backed full-suite and conformance coverage

Note: Run pnpm test to get the current exact passing test count.

Approval Tiers

Graduated authorization mapped to physical consequence severity:

Tier	Name	DFA States	Auto-approved?	Example
T0	OBSERVE	→ OBSERVING	Yes (logged)	Read sensor data, query database
T1	PREPARE	→ PREPARING	Yes (audited)	Write file, save waypoint, stage plan
T2	ACT	ESCALATING → ACTING	Requires review	Move robot, operate gripper, publish `/cmd_vel`
T3	COMMIT	ESCALATING → COMMITTING	Requires human + optional M-of-N	Execute trade, novel environment entry, irreversible action

Tier escalation triggers (Δ factors):

Δ_human: Human presence sensor active in workspace → +1 tier
Δ_trust: Agent trust score below threshold or recent failures → +1 tier
Δ_env: Robot near physical boundary or unstructured environment → +1 tier
Δ_novelty: Action outside validated distribution (novelty detector) → +1 tier

Formal Specification

Request Lifecycle DFA

SINT models every request as a deterministic finite automaton with 12 states:

IDLE → PENDING → POLICY_EVAL → PLANNING → OBSERVING/PREPARING/ACTING → COMMITTING → COMPLETED
                     ↓                              ↓
                ESCALATING                      ROLLEDBACK  (estop, execution failure)
                     ↓
                  FAILED     (approval denied, timeout)

The ACTING state is only reachable via POLICY_EVAL with a valid token. Physical actuation is structurally impossible without a valid capability token.

Tier Assignment Function

Tier(r) = max(BaseTier(r), Δ_human(r), Δ_trust(r), Δ_env(r), Δ_novelty(r))

Formal Invariants

Invariant	Description
I-T1 (Attenuation)	`scope(child_token) ⊆ scope(parent_token)` — delegation can only reduce permissions
I-T2 (Unforgeability)	Capability tokens are Ed25519-signed; valid tokens are computationally unforgeable
I-T3 (Physical Constraint Primacy)	Physical constraints (velocity, force, geofence) in a token cannot be weakened by any downstream layer
I-G1 (No Bypass)	Physical actuation is only reachable from the ACTING DFA state, which is only reachable via POLICY_EVAL
I-G2 (E-stop Universality)	The `estop` event transitions any non-terminal state to ROLLEDBACK unconditionally
I-G3 (Ledger Primacy)	COMMITTING → COMPLETED requires `ledger_committed`; no action completes without a ledger record

Benchmark Results

PolicyGateway latency (measured on M3 MacBook Pro, pnpm run bench):

Tier	p50	p99
T0 (OBSERVE)	~1ms	~3ms
T1 (PREPARE)	~1ms	~3ms
T2 (ACT)	~1ms	~3ms
T3 (COMMIT)	~1ms	~3ms

The gateway adds sub-3ms overhead at p99 for all tiers. Run benchmarks: pnpm run bench.

ROS2 control-loop target benchmark:

Path	SLA Target	Command
ROS2 command path (`/cmd_vel`)	`p99 < 10ms`	`pnpm run benchmark:ros2-loop`

Industrial benchmark artifacts:

Compliance mapping assets:

docs/compliance/tier-crosswalk-pack.md

Key Concepts

Capability Tokens

Ed25519-signed capability tokens — the only authorization primitive. Unlike RBAC (ambient authority to principals), OCap requires explicit token presentation for every operation.

Token fields:

Resource scoping — what the agent can access (ros2:///cmd_vel, mcp://filesystem/*, a2a://agents.example.com/*)
Action restriction — what operations are allowed (publish, call, subscribe, a2a.send)
Physical constraints — max velocity (m/s), max force (N), geofence polygon, time window, rate limit
Verifiable compute requirements — optional proof type/verifier/freshness/public-input constraints for T2/T3 actions
Delegation chains — max 3 hops, attenuation only (invariant I-T1)
Revocation — instant invalidation via revocation store (ConsentPass endpoint)
W3C DID identity — did:key:z6Mk... format for agent portability

Evidence Ledger

Every policy decision is recorded in a SHA-256 hash-chained append-only log. Chain integrity: ℓ_k.previousHash = SHA256(canonical(ℓ_{k-1})). A gap or hash mismatch constitutes tamper evidence.

For portable verification across bridges and external tooling, SINT now routes receipt and tool-definition signing through a shared deterministic canonical JSON serializer instead of relying on insertion-order-sensitive JSON.stringify() behavior.

For strong-tier flows, SINT can emit a linked bilateral receipt pair: a gate receipt before execution is allowed to proceed and a completion receipt once execution settles. The pair shares a stable actionRef and linkageHash so auditors can verify both authorization and outcome as one governed action.

Retention policy:

Tier	Retention
T0 (OBSERVE)	30 days
T1 (PREPARE)	90 days
T2 (ACT)	180 days
T3 (COMMIT)	365 days (indefinite if legal hold)

CSML: Composite Safety-Model Latency

A deployment metric that fuses behavioral and physical safety dimensions:

CSML(m, p, t) = α·AR_m + β·BP_m + γ·SV_m - δ·CR_m + ε·𝟙[ledger_intact(t)]

CSML above a deployment threshold θ automatically escalates all subsequent requests from that model backend to the next tier.

Compliance Mapping

IEC 62443 FR1–FR7

FR	Title	SINT Mechanism
FR1	Identification & Authentication	SintCapabilityToken with Ed25519 agent identity; W3C DID portability
FR2	Use Control	Four-tier Approval Gate; `maxRepetitions` constraint; per-resource action allowlists
FR3	System Integrity	SHA-256 hash-chained Evidence Ledger; ProofReceipt for T2/T3 (TEE attestation planned)
FR4	Data Confidentiality	Zenoh TLS transport; capability scope prevents sensor access without explicit token
FR5	Restricted Data Flow	Policy Gateway allowlists; `geofence` constraint; SINT Bridge per-topic DFA
FR6	Timely Response	`safety.estop.triggered` event; E-stop universality invariant I-G2
FR7	Resource Availability	Per-token rate limiting; `maxRepetitions`; budget enforcement in capsule sandbox

EU AI Act Article 13

Requirement	SINT Approach
Logging and traceability	SHA-256 hash-chained Evidence Ledger — tamper detection is cryptographic
Human oversight	Dynamic Consent + T3 approval gate — T3 actions cannot execute without recorded human approval
Risk management	Tier escalation based on real-time physical context (Δ_human, Δ_env, Δ_novelty)

Tier Crosswalk (NIST AI RMF / ISO 42001 / EU AI Act)

SINT Tier	NIST AI RMF	ISO/IEC 42001	EU AI Act
T0 Observe	MAP + MEASURE + MANAGE monitoring controls	Clause 9 + Clause 8 controls	Article 12 + Article 13
T1 Prepare	GOVERN + MANAGE controlled write path	Clause 8.1/8.2 operational risk treatment	Article 9 + Article 12
T2 Act	MANAGE risk response with accountable oversight	Clause 8 + Clause 6 operational controls	Article 14 + Article 15
T3 Commit	Highest-consequence GOVERN + MANAGE controls	Clause 8.3 + Clause 10 corrective governance	Article 14(4)(e) + Articles 9/12/15

Machine-readable crosswalk endpoint: GET /v1/compliance/tier-crosswalk

API Endpoints

Method	Endpoint	Description
`GET`	`/.well-known/sint.json`	Public protocol discovery (version, bridges, profiles, schemas)
`GET`	`/v1/health`	Health check
`POST`	`/v1/intercept`	Evaluate a single request
`POST`	`/v1/intercept/batch`	Evaluate multiple requests (207 Multi-Status)
`POST`	`/v1/tokens`	Issue a capability token
`POST`	`/v1/tokens/delegate`	Delegate (attenuate) a token
`POST`	`/v1/tokens/revoke`	Revoke a token
`GET`	`/v1/ledger`	Query audit ledger events
`GET`	`/v1/approvals/pending`	List pending approval requests
`POST`	`/v1/approvals/:id/resolve`	Approve or deny a request (M-of-N quorum)
`GET`	`/v1/approvals/events`	SSE stream for real-time approval events
`GET`	`/v1/approvals/ws`	WebSocket stream for low-latency approval events
`POST`	`/v1/a2a`	JSON-RPC 2.0 A2A protocol endpoint
`GET`	`/v1/metrics`	Prometheus metrics
`GET`	`/v1/openapi.json`	OpenAPI surface for gateway integration
`GET`	`/v1/compliance/tier-crosswalk`	SINT tier mapping to NIST AI RMF / ISO 42001 / EU AI Act controls
`POST`	`/v1/economy/route`	Cost-aware route selection with optional x402 pay-per-call quotes

Development Phases

SINT Protocol Core (6 phases complete)

Phase	Description	Tests
Phase 1 (complete)	Security Wedge — capability tokens, PolicyGateway, EvidenceLedger	425
Phase 2 (complete)	Engine Core — bridge-mcp, bridge-ros2, engine packages, persistence, gateway-server	+221 (646)
Phase 3 (complete)	Economy Bridge — @sint/bridge-economy with port/adapter pattern, EconomyPlugin	+91 (737)
Phase 4 (complete)	Standards Alignment — A2A bridge, rate limiting, M-of-N quorum, W3C DID identity	+78
Phase 5 (complete)	Protocol Surface v0.2 — discovery/OpenAPI/schema endpoints, industrial profiles	shipped
Phase 6 (complete)	Engine layer — System1/2 engines, HAL, capsule sandbox, Avatar/CSML, reference capsules	shipped

Physical AI Governance Roadmap 2026–2029 (Phases 1–5 in progress)

Extending SINT to consumer, health, and critical infrastructure domains:

Phase	Focus	Status	Examples
Phase 1	Consumer Smart Home (Q2–Q3 2026)	✅ Complete	`bridge-homeassistant` — Home Assistant MCP interceptor with 12 device classes (locks, cameras, alarms, climate, robot vacuums). Tier-appropriate defaults: locks/alarms→T2, lights/climate→T1, cameras→T0.
Phase 2	Matter Protocol Unification (Q3–Q4 2026)	✅ Complete	`bridge-matter` — Unified smart home governance across Matter-certified devices. Device discovery, service profiles, and tier assignment.
Phase 3	Occupancy & Human Presence (2027)	📋 Planned	`Δ_human` plugin: escalate robot vacuums to T2 when occupancy detected. Build on Phase 1 sensor fusion.
Phase 4	Critical Infrastructure (2027–2028)	📋 Planned	Power grids, water systems, industrial facilities. Formalized risk models and emergency-mode escalation.
Phase 5	Health Fabric & Wellbeing (Q4 2026–Q1 2027)	✅ Complete	`bridge-health` — FHIR R5 consent governance, HealthKit/Health Connect on-device processing, differential privacy ledger, and caregiver delegation tokens. HIPAA + GDPR alignment.

See docs/roadmaps/PHYSICAL_AI_GOVERNANCE_2026-2029.md for full roadmap.

Deployment

Railway (Recommended)

brew install railway
railway login
./scripts/railway-setup.sh
railway variables --set SINT_STORE=postgres SINT_CACHE=redis SINT_API_KEY=$(openssl rand -hex 32)
railway up

Docker Compose

docker-compose up
# Gateway:   http://localhost:3100
# Dashboard: http://localhost:3201
# Postgres:  localhost:5432
# Redis:     localhost:6379

Tech Stack

Runtime: Node.js 22+
Language: TypeScript 5.7 (strict mode)
Monorepo: pnpm workspaces + Turborepo
HTTP: Hono
Validation: Zod
Crypto: @noble/ed25519, @noble/hashes (audited, zero-dependency)
MCP SDK: @modelcontextprotocol/sdk
Dashboard: React 19, Vite 6
Testing: Vitest (run pnpm test for current count)
Infra: Docker, PostgreSQL 16+, Redis 7, GitHub Actions CI, Railway

Docs & Artifacts

Protocol spec: docs/SINT_v0.2_SPEC.md
SIP governance: docs/SIPS.md
Release notes: docs/RELEASE_NOTES_v0.2.md
Conformance matrix: docs/CONFORMANCE_CERTIFICATION_MATRIX_v0.2.md
EU AI Act mapping: docs/compliance/eu-ai-act-mapping.md
ISO 13482 alignment: docs/compliance/iso-13482-alignment.md
Formal threat model: docs/security/formal-threat-model.md
MITRE ATLAS candidate mappings: docs/security/mitre-atlas-agent-technique-mappings.md
Getting started: docs/getting-started.md
Deployment profiles: docs/profiles/
Examples: examples/ (hello-world, warehouse-amr, industrial-cell)
Multi-language SDKs: sdks/ (TypeScript, Python, Go)
Operator CLI: apps/sintctl/README.md
Standalone certification tool guide: docs/guides/standalone-certification-tool.md
Persistence baseline guide: docs/guides/persistence-baseline.md
WebSocket approvals guide: docs/guides/websocket-approvals.md
API docs site guide: docs/guides/api-documentation-site.md
gRPC bridge guide: docs/guides/grpc-bridge-skeleton.md
AutoGen interop fixtures guide: docs/guides/autogen-interop-fixtures.md
AgentSkill delegated authority fixtures guide: docs/guides/agentskill-authz-interop-fixtures.md
Industrial humanoid shipyard safety pack: docs/guides/industrial-humanoid-shipyard-safety-pack.md
Industrial humanoid shipyard sprint: docs/roadmaps/industrial-humanoid-shipyard-safety-sprint.md
Shipyard humanoid evidence export sample: docs/reports/shipyard-humanoid-evidence-export.jsonl
action_ref identity/explainability profile: docs/specs/action-ref-identity-explainability-profile.md
Payment governance profile (Economic Layer v1): docs/specs/payment-governance-profile-v1.md
Agent commerce governance profile: docs/specs/agent-commerce-governance-profile-v1.md
OpenAI Agents SDK governance guide: docs/guides/openai-agents-sdk-integration.md
Cursor integration guide: docs/guides/cursor-integration.md
Benchmark report: docs/reports/industrial-benchmark-report.md
ROS2 loop benchmark report: docs/reports/ros2-control-loop-benchmark.md
Hardware safety controller roadmap: docs/roadmaps/hardware-safety-controller-integration.md
Hardware safety handshake fixture: packages/conformance-tests/fixtures/industrial/hardware-safety-handshake.v1.json
Physical AI runtime safety fixtures: packages/conformance-tests/fixtures/physical-ai/runtime-safety-fixtures.v0.1.json
Physical AI runtime safety fixture schema: packages/conformance-tests/fixtures/physical-ai/runtime-safety-fixture.schema.json
Certification bundle summary: docs/reports/certification-bundle-summary.md
NIST submission playbook: docs/guides/nist-submission-playbook.md
NIST submission bundle report: docs/reports/nist-submission-bundle.md

Physical AI Governance (Consumer, Health, Critical Infrastructure)

Physical AI Governance Roadmap 2026–2029: docs/roadmaps/PHYSICAL_AI_GOVERNANCE_2026-2029.md — Complete phases 1–5 timeline and specifications
Consumer smart home integration guide: docs/guides/consumer-smart-home-integration.md — Home Assistant + Matter setup and deployment
Home Assistant bridge package: packages/bridge-homeassistant — 12 device classes with tier-appropriate defaults and occupancy-aware escalation
Matter protocol bridge: packages/bridge-matter — Unified smart home governance across Matter-certified devices
Health fabric bridge: packages/bridge-health — FHIR R5 consent governance, HealthKit/Health Connect mapping, differential privacy ledger, caregiver delegation
Implementation status: docs/IMPLEMENTATION_STATUS.md — Session completion report and artifact inventory
Execution summary: EXECUTION_SUMMARY.md — Phase completion metrics and deliverables
Master index: INDEX.md — Complete documentation navigation

Design Principles

Single choke point — Every agent action flows through PolicyGateway.intercept(); no bridge adapter makes authorization decisions independently
Result<T, E> over exceptions — All fallible operations return discriminated unions, never throw
Attenuation only — Delegated tokens can only reduce permissions, never escalate (I-T1)
Append-only audit — The evidence ledger is INSERT-only with SHA-256 hash chain integrity (I-G3)
Physical safety first — Velocity, force, and geofence constraints live in the token, not in external config
Interface-first persistence — Storage adapters implement clean interfaces; swap in-memory for Postgres/Redis
Fail-open on infrastructure — Economy/rate-limit infrastructure failures do not block the safety path
E-stop universality — The hardware E-stop bypasses all token checks and is unconditional (I-G2)

References

ROSClaw: Empirical safety analysis of LLM-controlled physical AI — arXiv:2603.26997 (IROS 2026)
MCP Security Analysis: Architectural vulnerabilities in the Model Context Protocol — arXiv:2601.17549
IEC 62443: Industrial automation and control systems cybersecurity standard
EU AI Act Article 13: Transparency requirements for AI systems
NIST AI RMF: AI Risk Management Framework
W3C DID Core: Decentralized Identifiers specification

Roadmap

The active execution pages are:

The current emphasis is straightforward:

production-ready gateway behavior
release and evidence discipline
collaborator-facing integration artifacts
stronger external adoption and maintainership signals

License

Apache-2.0

Available Tools

21 tools

sint__add_serverB

Dynamically add a new downstream MCP server at runtime

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Unique name for the server
`command`	Yes	Command to spawn the server
`args`	No	Arguments for the command

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions needed, whether this affects system stability, if changes persist, error handling, or what happens on success/failure. 'Dynamically' hints at runtime modification but lacks specifics.

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?

Single sentence with zero waste—every word contributes essential information: action ('add'), resource ('downstream MCP server'), and key constraint ('dynamically...at runtime'). No redundant or verbose phrasing.

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 tool that performs a system modification (adding servers) with no annotations and no output schema, the description is insufficient. It doesn't explain what 'downstream MCP server' means in this context, what the tool returns, or critical behavioral aspects like side effects or security implications.

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 parameters are fully documented in the schema. The description adds no additional meaning beyond implying these parameters configure the server addition. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 specific action ('add') and resource ('new downstream MCP server'), with the qualifier 'dynamically...at runtime' distinguishing it from static configuration. It differentiates from sibling 'sint__remove_server' by specifying addition rather than removal.

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

Usage Guidelines3/5

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

The description implies usage context ('at runtime') but doesn't explicitly state when to use this tool versus alternatives like 'sint__servers' (likely for listing) or 'sint__remove_server'. No guidance on prerequisites, error conditions, or specific scenarios for dynamic server addition is provided.

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

sint__approveC

Approve a pending escalated action by its request ID

ParametersJSON Schema

Name	Required	Description	Default
`requestId`	Yes	The approval request ID to approve
`by`	No	Identifier of the approver (default: current agent)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a mutation ('Approve') but doesn't disclose permissions needed, side effects (e.g., what happens after approval), rate limits, or response format. This is inadequate for a tool that likely changes system state.

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 a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a simple tool, making it easy to parse quickly.

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?

Given no annotations and no output schema, the description is incomplete for a mutation tool. It lacks details on behavioral traits (e.g., authorization, effects), response format, and usage context, failing to compensate for the missing structured data.

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 fully documents both parameters. The description adds no additional meaning beyond implying 'requestId' identifies a pending action, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the action ('Approve') and resource ('a pending escalated action by its request ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'sint__deny' (which presumably denies rather than approves) or 'sint__pending' (which might list pending actions), missing explicit sibling distinction.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a pending action), exclusions, or comparisons to siblings like 'sint__deny' for rejection scenarios, leaving usage context unclear.

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

sint__auditB

Query the SINT evidence ledger for recent decisions and events

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max events to return (default: 20)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Query' implies a read-only operation, it doesn't specify authentication requirements, rate limits, pagination behavior, or what constitutes 'recent' events. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.

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

Completeness3/5

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

Given the tool's moderate complexity (querying an evidence ledger), lack of annotations, and no output schema, the description is minimally adequate. It identifies the resource and scope but doesn't explain return values, error conditions, or behavioral constraints, leaving room for improvement in completeness.

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?

The input schema has 100% description coverage (the 'limit' parameter is fully documented in the schema), so the baseline score is 3. The description doesn't add any parameter-specific information beyond what's already in the schema, but it doesn't need to compensate for gaps either.

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 clearly states the tool's purpose with a specific verb ('Query') and resource ('SINT evidence ledger'), and specifies the scope ('for recent decisions and events'). However, it doesn't explicitly differentiate this read operation from siblings like 'sint__list_delegations' or 'sint__pending', which might also retrieve information.

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?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'sint__list_delegations', 'sint__pending', and 'sint__status' that might retrieve related information, there's no indication of what makes this tool unique or when it should be preferred over others.

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

sint__delegate_to_agentA

Issue an attenuated capability token to a sub-agent, granting it a reduced tool scope. Depth is parent.depth + 1; max depth 3. Returns the new tokenId.

ParametersJSON Schema

Name	Required	Description
`subagentId`	Yes	Public key of the sub-agent to delegate to
`toolScope`	Yes	Resource URI patterns the sub-agent may access (must be a subset of caller's scope)
`expiresInHours`	No	Token lifetime in hours (default: 4)
`maxCallsPerMinute`	No	Optional rate limit for sub-agent

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it creates a new token (implies mutation), specifies depth constraints (parent.depth + 1; max depth 3), and mentions the return value (tokenId). It could improve by addressing potential side effects or error conditions, but it covers core behavior well.

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 highly concise and front-loaded, with two sentences that efficiently convey the tool's purpose, constraints, and outcome. Every sentence earns its place by providing essential information without redundancy or fluff.

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

Completeness3/5

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

Given the tool's complexity (delegation with depth limits), no annotations, and no output schema, the description is moderately complete. It covers the core operation and constraints but lacks details on error handling, security implications, or the format of the returned tokenId. It meets minimum viability but has clear gaps for a mutation 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 documents all parameters thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't clarify format for subagentId or toolScope patterns). Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 specific action ('Issue an attenuated capability token to a sub-agent') and resource ('granting it a reduced tool scope'), distinguishing it from siblings like sint__issue_token (which likely issues tokens without delegation) and sint__list_delegations (which lists rather than creates). It precisely defines the operation's purpose.

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 provides clear context for when to use this tool: for delegating capabilities to sub-agents with depth constraints (max depth 3). However, it does not explicitly state when not to use it or name alternatives (e.g., vs. sint__issue_token for non-delegated tokens), missing full explicit guidance.

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

sint__denyB

Deny a pending escalated action by its request ID

ParametersJSON Schema

Name	Required	Description
`requestId`	Yes	The approval request ID to deny
`reason`	No	Reason for denial
`by`	No	Identifier of the denier (default: current agent)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool denies an action, implying a mutation operation, but does not disclose other behavioral traits such as required permissions, whether the denial is reversible, what happens after denial (e.g., notifications, status changes), or any rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.

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 a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key verb ('Deny') and resource, making it easy to parse and understand immediately. Every part of the sentence earns its place by specifying the action and target.

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?

Given the complexity of a denial operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It lacks information on behavioral aspects like permissions, consequences, or response format, which are crucial for safe and effective use. The description alone does not provide enough context for an agent to fully understand the tool's implications.

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?

The input schema has 100% description coverage, with clear descriptions for all parameters (requestId, reason, by). The description does not add any additional meaning or context beyond what the schema provides, such as format details or examples. Since the schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

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 action ('Deny') and the target resource ('a pending escalated action by its request ID'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like 'sint__approve' (which likely approves instead of denies) and 'sint__pending' (which likely lists pending actions rather than acting on them).

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

Usage Guidelines3/5

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

The description implies usage when there is a 'pending escalated action' to deny, but it does not explicitly state when to use this tool versus alternatives (e.g., 'sint__approve' for approval or other tools for different actions). No exclusions or prerequisites are mentioned, leaving the context somewhat implied rather than fully guided.

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

sint__interface_modeB

Change the operator interface display mode: hud, compact, voice-only, or silent

ParametersJSON Schema

Name	Required	Description	Default
`mode`	Yes	Target interface mode

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool changes the interface mode, implying a mutation, but fails to describe critical behaviors like whether this requires specific permissions, if changes are reversible, what side effects occur (e.g., impact on other tools), or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 a single, efficient sentence that directly states the tool's purpose and enumerates the modes without any wasted words. It is front-loaded with the core action and resource, making it highly concise and well-structured for quick comprehension.

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?

Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like permissions, reversibility, side effects, or response format. While the parameter is well-covered by the schema, the overall context for safe and effective use is insufficient, especially compared to siblings that may have overlapping or related functionalities.

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

Parameters4/5

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

The schema description coverage is 100%, with the parameter 'mode' fully documented in the schema, including its enum values. The description adds minimal value by listing the enum values, but it doesn't provide additional semantics beyond what the schema already covers. With only one parameter and high schema coverage, a baseline of 3 is appropriate, but the description slightly enhances clarity by explicitly naming the modes, warranting a score of 4.

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 action ('Change') and the resource ('operator interface display mode'), and it enumerates the specific modes (hud, compact, voice-only, silent), making the purpose highly specific and unambiguous. It effectively distinguishes this tool from its siblings, such as sint__interface_status or sint__show_hud, by focusing on mode changes rather than status checks or display actions.

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?

The description provides no guidance on when to use this tool versus alternatives, such as sint__interface_status for checking the current mode or sint__show_hud for displaying the HUD. It lacks context on prerequisites, timing, or exclusions, leaving the agent without clear usage instructions beyond the basic action.

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

sint__interface_statusA

Return current operator interface state: mode, listening/speaking flags, active HUD panels, memory context size, and session ID

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states this is a read operation ('Return'), implying non-destructive behavior, but lacks details on permissions, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

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 a single, dense sentence that front-loads the core purpose and efficiently lists all returned attributes without unnecessary words. Every element (verb, resource, attributes) earns its place, making it highly concise and well-structured for quick comprehension.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description adequately covers what the tool returns. However, it lacks output format details (e.g., structure of returned data) and behavioral context like error handling, which would be beneficial for full completeness despite the low complexity.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics without redundant parameter info, earning a baseline score above minimum viable due to efficient handling of the parameter-less case.

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 specific action ('Return') and the exact resource ('current operator interface state'), listing specific attributes like mode, listening/speaking flags, HUD panels, memory context size, and session ID. It distinguishes itself from sibling tools like 'sint__status' (likely general status) and 'sint__interface_mode' (likely just mode) by specifying the comprehensive interface-focused state retrieval.

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

Usage Guidelines3/5

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

The description implies usage when needing interface state details, but provides no explicit guidance on when to use this tool versus alternatives like 'sint__status' or 'sint__interface_mode'. It doesn't mention prerequisites, exclusions, or specific contexts for invocation, leaving usage inferred rather than clearly defined.

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

sint__issue_tokenC

Issue a new capability token with restricted scope (admin). Returns tokenId on success.

ParametersJSON Schema

Name	Required	Description
`subject`	Yes	Public key of the token subject
`resource`	Yes	Resource URI pattern (e.g. 'mcp://filesystem/*')
`actions`	Yes	Allowed actions (e.g. ['call', 'exec.run'])
`expiresInHours`	No	Token lifetime in hours (default: 24)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool issues a token and returns a tokenId on success, which covers the basic outcome. However, it lacks details on critical behaviors: it doesn't mention authentication requirements, potential side effects (e.g., token persistence), error conditions, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 a single, efficient sentence that front-loads the purpose and outcome. It avoids redundancy and wastes no words, making it easy to parse. It could be slightly improved by structuring into separate purpose and result clauses, but it's already highly concise and well-organized.

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?

Given the complexity of issuing a token (a mutation operation), no annotations, and no output schema, the description is incomplete. It covers the basic action and return value but omits essential context: it doesn't explain the token's lifecycle, admin requirements, error handling, or how the token integrates with sibling tools. For a tool with 4 parameters and significant implications, more detail is needed to guide the agent effectively.

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%, meaning the input schema fully documents all parameters (subject, resource, actions, expiresInHours). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. However, since the schema is comprehensive, the baseline score of 3 is appropriate, as the description doesn't need to compensate for gaps.

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 clearly states the action ('Issue a new capability token') and the resource ('capability token'), with the added detail of 'with restricted scope (admin)'. It distinguishes this from siblings like sint__revoke_token or sint__list_delegations by focusing on creation rather than management or querying. However, it doesn't explicitly differentiate from all siblings (e.g., sint__delegate_to_agent might also involve token-like operations), keeping it from a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives. It mentions 'restricted scope (admin)', which implies an admin context, but doesn't specify prerequisites, exclusions, or direct comparisons to siblings like sint__delegate_to_agent or sint__approve. Without explicit when/when-not instructions, the agent must infer usage from the purpose alone.

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

sint__list_delegationsB

List the active delegation tree rooted at the current operator token. Returns a JSON array of DelegationNode objects.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List') and return type ('JSON array of DelegationNode objects'), but lacks details on permissions, rate limits, side effects, or how the 'current operator token' is determined, which is critical for a tool that likely involves authentication and data retrieval.

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 a single, efficient sentence that front-loads the core action and resource, with no wasted words. It's appropriately sized for a tool with no parameters, making it easy to scan and understand quickly.

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?

Given the complexity implied by terms like 'delegation tree' and 'operator token', and with no annotations or output schema, the description is insufficient. It doesn't explain what a DelegationNode is, how the tree is structured, or any behavioral traits, leaving gaps for effective tool use in a broader context.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add param info, maintaining focus on the tool's purpose and output, which aligns with the baseline for zero parameters.

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 clearly states the verb ('List') and resource ('active delegation tree rooted at the current operator token'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'sint__servers' or 'sint__pending', which might also involve listing operations, so it misses full sibling distinction.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for 'current operator token', or compare to siblings like 'sint__servers' for server listings or 'sint__pending' for pending delegations, leaving usage unclear.

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

sint__notifyC

Send a proactive notification to the operator, optionally with an actionable button

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	Notification message text
`action`	No	Optional action button attached to the notification

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions sending a notification with an optional button, but lacks critical behavioral details: whether this is a read-only or mutative operation, if it requires specific permissions, rate limits, or how the notification is delivered (e.g., pop-up, log). For a tool with potential user impact, this is a significant gap.

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 a single, efficient sentence that front-loads the core purpose ('Send a proactive notification to the operator') and adds the optional feature concisely. Every word earns its place with zero waste, making it easy for an agent to parse quickly.

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?

Given the tool's complexity (notifications with interactive buttons), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like delivery method, user response handling, or error conditions. For a tool that could affect user experience, more context is needed to ensure proper agent usage.

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 documents both parameters (message and action) thoroughly. The description adds minimal value beyond the schema by implying the button is 'actionable' and attached to the notification, but doesn't provide additional syntax, format, or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the verb 'send' and resource 'proactive notification to the operator', specifying it can include an 'actionable button'. It distinguishes from siblings like sint__speak (which might be for speech output) or sint__show_hud (which might be for visual displays), but doesn't explicitly contrast with them. The purpose is specific but lacks explicit sibling differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives. It mentions the optional button feature but doesn't specify scenarios (e.g., for urgent alerts, user interactions, or system updates) or exclusions. With many sibling tools available, this omission leaves the agent without context for selection.

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

sint__pendingA

List all pending approval requests awaiting human review

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It indicates a listing operation but lacks details on behavioral traits such as pagination, sorting, permissions required, rate limits, or what constitutes 'pending' (e.g., timeframes, states). This is a significant gap for a tool with no annotation coverage.

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 a single, efficient sentence that front-loads the key information ('List all pending approval requests') without any wasted words. It is appropriately sized for a no-parameter tool and earns its place by clearly stating the purpose.

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

Completeness3/5

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

Given the tool's complexity (simple listing with no parameters) and lack of annotations/output schema, the description is minimally adequate. It states what the tool does but omits behavioral details like return format or operational constraints, leaving gaps that could hinder effective use by an AI agent.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate, but it does imply the scope ('all pending approval requests'), providing slight semantic context beyond the schema. Baseline is 4 for zero parameters.

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 specific action ('List all') and resource ('pending approval requests awaiting human review'), distinguishing it from siblings like sint__approve, sint__deny, or sint__audit. It precisely communicates a read-only listing function focused on pending items requiring review.

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 implies usage context by specifying 'pending approval requests awaiting human review,' suggesting this tool is for monitoring or managing approval workflows. However, it does not explicitly state when to use it versus alternatives like sint__audit or provide exclusion criteria, leaving some ambiguity.

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

sint__recall_memoryB

Search the memory bank for entries matching a query string. Returns matching entries as JSON.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query to match against memory entries
`limit`	No	Maximum number of results to return (default: 10)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('as JSON') but lacks details on permissions, rate limits, error handling, or whether the search is case-sensitive/fuzzy. For a search tool with zero annotation coverage, this leaves significant 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.

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core action and outcome without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it optimally concise.

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

Completeness3/5

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

Given the tool's moderate complexity (search operation with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and return format but lacks details on search behavior, result structure, or error cases, which could hinder effective use by an agent.

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?

The schema description coverage is 100%, with clear descriptions for both parameters ('query' and 'limit'). The description adds no additional parameter semantics beyond what the schema provides, such as search syntax or matching criteria, so it meets the baseline for high schema coverage.

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 specific action ('Search'), the target resource ('memory bank'), and the outcome ('Returns matching entries as JSON'). It distinguishes itself from siblings like 'store_memory' by focusing on retrieval rather than storage, making the purpose immediately understandable.

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?

The description provides no guidance on when to use this tool versus alternatives. While it implies usage for searching memory entries, it doesn't mention when not to use it or refer to sibling tools like 'store_memory' for related operations, leaving the agent without contextual usage cues.

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

sint__remove_serverC

Remove a downstream MCP server by name

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the server to remove

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Remove' implies a destructive operation, it doesn't specify whether this action is reversible, requires specific permissions, affects system stability, or has side effects like stopping processes. For a tool that likely modifies system state, this lack of detail is a significant gap.

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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning full marks for brevity and clarity.

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?

Given the lack of annotations and output schema, and the tool's likely destructive nature (implied by 'Remove'), the description is incomplete. It doesn't address key contextual aspects like what 'downstream MCP server' entails, confirmation requirements, error handling, or return values, leaving the agent with insufficient information for safe and effective use.

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%, with the single parameter 'name' clearly documented in the schema as 'Name of the server to remove'. The description adds no additional semantic context beyond this, such as format examples or naming conventions, so it meets the baseline for adequate but not enhanced parameter understanding.

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 clearly states the action ('Remove') and the resource ('a downstream MCP server by name'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like sint__revoke_delegation_tree or sint__revoke_token, which might also involve removal operations in different contexts.

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?

The description provides no guidance on when to use this tool versus alternatives, such as sint__servers (which might list servers) or sint__revoke_token (which might remove tokens). There's no mention of prerequisites, consequences, or appropriate contexts for removal, leaving the agent with insufficient usage direction.

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

sint__revoke_delegation_treeA

Revoke an entire delegation subtree rooted at the given tokenId. All descendant tokens are cascade-revoked.

ParametersJSON Schema

Name	Required	Description	Default
`rootTokenId`	Yes	Root tokenId of the subtree to revoke
`reason`	No	Reason for revocation

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the cascade revocation behavior ('All descendant tokens are cascade-revoked'), which is a key behavioral trait. However, it lacks details on permissions, reversibility, or error handling, leaving gaps for a mutation tool.

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 a single, efficient sentence that front-loads the core action and includes all necessary details (verb, resource, scope, cascade effect). There is zero waste, and every word earns its place.

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

Completeness3/5

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

Given the tool's complexity (mutation with cascade effects), no annotations, and no output schema, the description is incomplete. It covers the purpose and cascade behavior but lacks details on permissions, response format, or error conditions, which are important for safe invocation.

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 documents both parameters (rootTokenId and reason). The description adds context by explaining that rootTokenId identifies the 'subtree to revoke' and implies cascade effects, but does not provide additional syntax or format details beyond the schema. Baseline 3 is appropriate as the schema handles parameter documentation.

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 specific action ('revoke') and resource ('entire delegation subtree'), including the scope ('rooted at the given tokenId') and cascade effect ('All descendant tokens are cascade-revoked'). It distinguishes from sibling tools like sint__revoke_token by specifying subtree vs. single token revocation.

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

Usage Guidelines3/5

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

The description implies usage for revoking a delegation subtree with cascade effects, but does not explicitly state when to use this tool versus alternatives like sint__revoke_token or provide exclusions. The context is clear but lacks explicit guidance on alternatives or prerequisites.

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

sint__revoke_tokenC

Revoke an active capability token by its ID (admin)

ParametersJSON Schema

Name	Required	Description	Default
`tokenId`	Yes	ID of the token to revoke
`reason`	No	Reason for revocation

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool is for admins and involves revocation, but doesn't explain what revocation entails (e.g., immediate deactivation, irreversible action, system impact), nor does it cover error conditions, permissions required beyond 'admin', or response format.

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 a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple revocation tool, though it could be slightly more structured by separating the admin constraint into its own clause.

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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after revocation, what the return value might be, error scenarios, or system implications. The '(admin)' hint is helpful but doesn't provide complete operational context.

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 fully documents both parameters (tokenId and reason). The description adds no additional parameter semantics beyond what's in the schema, but doesn't need to since the schema is complete. Baseline 3 is appropriate when schema does all the work.

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 clearly states the action ('revoke') and the resource ('active capability token by its ID'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'revoke_delegation_tree' or 'issue_token', but the verb+resource combination is specific enough for basic understanding.

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?

The description provides no guidance on when to use this tool versus alternatives like 'revoke_delegation_tree' or 'deny', nor does it mention prerequisites or constraints beyond the '(admin)' hint. There's no explicit when/when-not usage context provided.

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

sint__serversA

List all downstream MCP servers with connection status, tool counts, and health

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions listing with attributes but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires permissions, how data is formatted, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant gaps.

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 a single, efficient sentence that front-loads the key action ('List all downstream MCP servers') and specifies attributes without wasted words. Every part earns its place by clarifying scope and output details.

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

Completeness3/5

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

Given the tool's complexity (simple listing with 0 params) and lack of annotations/output schema, the description is minimally adequate. It states what it does but lacks behavioral context (e.g., safety, format). For a no-parameter tool, this is passable but not comprehensive.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any, earning a baseline score above 3 for not introducing confusion.

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 action ('List all') and resource ('downstream MCP servers') with specific attributes ('connection status, tool counts, and health'). It distinguishes from siblings like sint__add_server (adds) and sint__remove_server (removes) by focusing on listing existing servers.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare to siblings like sint__status (which might show overall status) or sint__interface_status (which could relate to interfaces).

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

sint__show_hudB

Update a HUD panel with new data. Emits an operator.hud.updated event.

ParametersJSON Schema

Name	Required	Description	Default
`panel`	Yes	Which HUD panel to update
`data`	No	Data to display in the panel (any JSON value)

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the mutation behavior ('Update') and side effect ('Emits an operator.hud.updated event'), which is valuable. However, it lacks details about permissions needed, whether updates are persistent, rate limits, or what happens if invalid data is provided.

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 perfectly concise with two sentences that each add value. The first sentence states the core functionality, and the second adds important behavioral context about event emission. No wasted words or redundancy.

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

Completeness3/5

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

For a mutation tool with no annotations and no output schema, the description provides basic but incomplete context. It covers what the tool does and mentions an event emission, but lacks details about success/failure responses, data format expectations beyond 'any JSON value', or how this integrates with the broader HUD system.

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 fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (panel selection and data payload). This meets the baseline for high schema coverage.

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 clearly states the action ('Update') and resource ('a HUD panel with new data'), making the purpose immediately understandable. It distinguishes from siblings by specifying HUD panel updates, though it doesn't explicitly differentiate from similar UI tools like 'sint__interface_mode' or 'sint__interface_status'.

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?

The description provides no guidance on when to use this tool versus alternatives. It mentions an event emission ('Emits an operator.hud.updated event') which hints at notification purposes, but doesn't specify use cases, prerequisites, or exclusions compared to sibling tools.

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

sint__speakC

Schedule TTS voice output to the operator with a configurable priority level

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to speak aloud to the operator
`priority`	No	Voice output priority (default: normal)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but lacks behavioral details. It mentions scheduling and priority but doesn't disclose execution timing, persistence, error handling, or system impact. For a tool that interacts with operator audio, this is a significant gap.

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 a single, efficient sentence that front-loads the core purpose. Every word contributes to understanding without redundancy or fluff.

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 tool with no annotations, no output schema, and interaction with operator systems, the description is incomplete. It lacks details on return values, side effects, or operational context, leaving gaps for safe and effective use.

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 parameters are well-documented in the schema. The description adds minimal value by mentioning 'configurable priority level', which aligns with the priority parameter, but doesn't explain text formatting or priority implications beyond the schema.

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 clearly states the action ('Schedule TTS voice output') and target ('to the operator'), with a specific feature ('configurable priority level'). It distinguishes from siblings like sint__notify or sint__status by focusing on scheduled audio output, though it doesn't explicitly compare to them.

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?

No guidance is provided on when to use this tool versus alternatives like sint__notify or sint__interface_status. The description implies it's for voice output but doesn't specify scenarios, prerequisites, or exclusions.

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

sint__statusA

Show SINT MCP status: connected servers, agent identity, queue size, and system health

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the tool's read-only nature by using 'Show' and lists specific data points returned, but does not mention behavioral traits like rate limits, authentication needs, or error conditions. The description adds value but lacks comprehensive behavioral context.

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 a single, efficient sentence that front-loads the purpose and details the scope without waste. Every word earns its place, making it easy to scan and understand quickly.

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 the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for a status-checking tool. It specifies what information is returned, though it could benefit from mentioning the output format or any system dependencies. The lack of output schema means the description should ideally cover return values, but it partially compensates by listing data points.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not discuss parameters, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary information.

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 specific action ('Show') and resource ('SINT MCP status') with detailed scope ('connected servers, agent identity, queue size, and system health'). It distinguishes from siblings like sint__servers (likely lists servers only) and sint__interface_status (likely interface-specific status).

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 implies usage context for checking overall system status, but does not explicitly state when to use this vs. alternatives like sint__interface_status or sint__servers. No exclusions or prerequisites are mentioned, though the context is clear enough for basic differentiation.

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

sint__store_memoryC

Store an entry in the memory bank with optional tags and persistence

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Unique key for the memory entry
`value`	Yes	Value to store (any JSON value)
`tags`	No	Optional tags for categorisation and search
`persist`	No	Whether to persist beyond this session (default: false)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions 'persistence beyond this session' which hints at session-bound behavior, it doesn't address critical aspects like whether this operation overwrites existing entries, what happens on duplicate keys, error conditions, or performance characteristics. The description is insufficient for a mutation tool with zero annotation coverage.

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 a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a straightforward storage operation and front-loads the essential action.

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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens on success/failure, what gets returned, how errors manifest, or the implications of the persistence setting. The agent lacks sufficient context to use this tool effectively in production scenarios.

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?

With 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description adds minimal value by mentioning 'optional tags and persistence' but provides no additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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 clearly states the action ('Store an entry') and resource ('in the memory bank'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'sint__recall_memory' beyond the basic verb difference, missing an opportunity to clarify their complementary relationship.

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?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'sint__recall_memory' and 'sint__pending' that might relate to memory operations, there's no indication of appropriate contexts, prerequisites, or exclusions for this storage function.

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

sint__whoamiA

Show current agent identity: public key, active token, session info

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It clearly indicates this is a read-only operation ('Show') that reveals sensitive authentication information. However, it doesn't disclose potential rate limits, whether this requires specific permissions, or how the information is formatted/structured in the response.

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?

Extremely concise single sentence that front-loads the core purpose ('Show current agent identity') followed by specific details of what's included. Every word earns its place with no redundancy or unnecessary elaboration.

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 zero-parameter identity query tool with no annotations and no output schema, the description provides adequate context about what information is returned. However, it doesn't specify the format/structure of the returned data or mention any authentication requirements for accessing this sensitive identity information.

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

Parameters4/5

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

The tool has zero parameters with 100% schema coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on what the tool returns rather than what it accepts. Baseline for zero parameters is 4.

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 specific action ('Show') and the resource ('current agent identity'), listing the exact information returned (public key, active token, session info). It distinguishes itself from sibling tools like sint__status or sint__interface_status by focusing specifically on identity details rather than general system status.

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 implies usage context - when you need to verify or display the current agent's authentication and session state. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the specificity of 'identity' information provides some implicit differentiation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

21 tool updatesv0.1.0Apr 16, 2026
- First observedsint__add_server
- First observedsint__approve
- First observedsint__audit
- First observedsint__delegate_to_agent
- First observedsint__deny
- First observedsint__interface_mode
- First observedsint__interface_status
- First observedsint__issue_token
- First observedsint__list_delegations
- First observedsint__notify
- First observedsint__pending
- First observedsint__recall_memory
- First observedsint__remove_server
- First observedsint__revoke_delegation_tree
- First observedsint__revoke_token
- First observedsint__servers
- First observedsint__show_hud
- First observedsint__speak
- First observedsint__status
- First observedsint__store_memory
- First observedsint__whoami

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity. Tools like sint__approve and sint__deny handle opposite actions, sint__audit and sint__pending cover different review aspects, and sint__store_memory and sint__recall_memory manage separate memory operations. The descriptions make each tool's unique role immediately apparent.

Naming Consistency5/5

All tools follow a consistent 'sint__verb_noun' pattern throughout, with clear and descriptive names like sint__add_server, sint__remove_server, and sint__list_delegations. The naming convention is uniform, using snake_case and prefixed verbs that accurately reflect each tool's function without deviation.

Tool Count4/5

With 21 tools, the count is slightly high but reasonable for the server's purpose of managing MCP servers, operator interfaces, and security capabilities. It covers a broad scope including server management, delegation, approval workflows, and memory operations, though it could be streamlined without losing essential functionality.

Completeness5/5

The tool set provides comprehensive coverage for the SINT Protocol domain, including full lifecycle management for servers (add, remove, list), delegation (issue, list, revoke), approval workflows (pending, approve, deny), memory operations (store, recall), and operator interface control. No obvious gaps exist; agents can perform all expected operations without dead ends.

Maintenance

ActivitySlowing

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
Occludra — MCP Gateway (AI Security Gateway)
ai.occludra
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Security Agent Orchestration
1
gateway
ai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security Agent Orchestration
1
shadowgate-mcp
io.github.josephibra
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security Monitoring
2

Related MCP Servers

GitHub MCP Serverofficial
Version Control Developer Tools File Systems
modelcontextprotocol
-
license
Not graded
quality
A
maintenance
MCP Server for the GitHub API, enabling file operations, repository management, search functionality, and more.
Updated 3 days ago (2026-09-03 01:42 UTC)
117,296
90,042
MIT
Semgrep MCP Server
Code Analysis Developer Tools Security
stefanskiasan
A
license
Not graded
quality
D
maintenance
Enables integration of Semgrep in development environments via the MCP protocol, supporting static code analysis, rule management, and scan result operations.
Updated 2 years ago (2025-02-01 17:19 UTC)
2
MIT
Semgrep MCP Serverofficial
Code Analysis Security Autonomous Agents
semgrep
A
license
B
quality
F
maintenance
An MCP server that provides a comprehensive interface to Semgrep, enabling users to scan code for security vulnerabilities, create custom rules, and analyze scan results through the Model Context Protocol.
Updated 10 months ago (2025-10-28 22:32 UTC)
6
685
MIT
Cloudflare Playwright MCPofficial
Browser Automation Cloud Platforms Developer Tools
cloudflare
A
license
B
quality
F
maintenance
A server that leverages Playwright for automated browser testing and integrates with Cloudflare Workers, enabling AI assistants to control web browsers for navigation, interaction, and screenshots.
Updated 4 months ago (2026-04-23 20:52 UTC)
22
5,881,527
258
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sint-ai/sint-protocol'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SINT Protocol

What is SINT Protocol?

Where SINT Fits

Latest Implementation Highlights

Install the MCP server

Try the interceptor flagship in 5 minutes

Production-Ready Core

Why SINT?

Capability Coverage

Quick Start

Start the Gateway Server

Start Production-Like Stacks (One Command)

Developer Docs Site (docs.sint.gg)

Run a Single Package

Consumer Domains: Smart Home & Health

Consumer Smart Home (Home Assistant + Matter)

Health Fabric (FHIR + HealthKit/Health Connect)

SINT Operator Interface

For AI Agents

Architecture

APS vs SINT Primitives

Packages

Gate (Security Core)

Bridges (15 bridges)

Engine (AI Execution Layer)

Reference Capsules

Persistence

Apps & SDKs

Approval Tiers

Formal Specification

Request Lifecycle DFA

Tier Assignment Function

Formal Invariants

Benchmark Results

Key Concepts

Capability Tokens

Evidence Ledger

CSML: Composite Safety-Model Latency

Compliance Mapping

IEC 62443 FR1–FR7

EU AI Act Article 13

Tier Crosswalk (NIST AI RMF / ISO 42001 / EU AI Act)

API Endpoints

Development Phases

SINT Protocol Core (6 phases complete)

Physical AI Governance Roadmap 2026–2029 (Phases 1–5 in progress)

Deployment

Railway (Recommended)

Docker Compose

Tech Stack

Docs & Artifacts

Design Principles

References

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Semgrep MCP Serverofficial

Cloudflare Playwright MCPofficial

Latest Blog Posts

MCP directory API

Developer Docs Site (`docs.sint.gg`)