Skip to content
Tools
AGH RuntimeTools

Tool Registry

How AGH exposes daemon-owned tools to operators and managed agents through one policy-checked registry.

Audience
Operators running durable agent work
Focus
Tools guidance shaped for scanability, day-two clarity, and operator context.

The tool registry is the runtime surface that lets AGH expose structured actions without turning every capability into a one-off prompt convention. Tools have stable IDs, JSON schemas, availability diagnostics, policy checks, redaction rules, and invocation events.

Use this page when you need to understand what a tool is, how agents discover tools, and how the operator CLI relates to the session-bound MCP tool surface.

In one sentence

An AGH tool is a daemon-owned action with a typed input schema, a typed result, policy enforcement, and an audit trail.

Why AGH has tools

Agent sessions need more than text prompts. They need to inspect runtime state, claim work, extend leases, read memory, search skills, inspect hooks, and report progress without scraping prose or calling private Go functions.

The registry gives those actions one shape:

  • discover what exists
  • inspect the schema before calling it
  • invoke through daemon policy
  • redact sensitive input fields
  • record enough evidence for operators to audit what happened

Discovery path

List or search the registry

Operators use the CLI. Managed agents use the hosted MCP tool surface.

agh tool list -o json
agh tool search memory --limit 5 -o json

What happened: AGH returned operator-visible descriptors and availability diagnostics for the current scope.

Inspect the tool before invoking it

agh tool info agh__skill_view -o json

What happened: AGH returned the descriptor, input schema, output shape, policy requirements, and diagnostics for one tool ID.

Invoke through daemon policy

agh tool invoke agh__tool_info --input '{"tool_id":"agh__skill_view"}' -o json

What happened: AGH validated JSON input, applied policy, dispatched the daemon-owned tool, and returned a structured result.

Tool surfaces

SurfaceActorPurpose
agh tool list/search/info/invokeOperator or scriptInspect and invoke operator-visible registry tools.
agh toolsets list/infoOperator or scriptInspect grouped tool exposure and expansion diagnostics.
Hosted MCP toolsManaged agent sessionLet an agent discover and invoke session-scoped tools without shell scraping.
HTTP/UDS APIWeb UI, integrations, local toolingShare the same daemon handler contract behind CLI and browser surfaces.

Default discovery tools

The normal managed-agent path starts with discovery, not blind invocation:

  • agh__bootstrap
  • agh__catalog
  • agh__tool_search
  • agh__tool_info
  • agh__skill_search
  • agh__skill_view

The expected pattern is:

Rendering diagram...

Managed agents should discover tools and skills before invoking a runtime action.

That sequence lets the agent inspect available actions and schemas before it commits to a call.

What belongs in the tool registry

Good tool candidates:

  • runtime state inspection
  • task claim, heartbeat, completion, failure, and release
  • memory read/search/write operations
  • skill and capability discovery
  • hook, automation, and extension lifecycle operations
  • bridge and network diagnostics

Poor tool candidates:

  • UI-only convenience flows with no daemon state
  • arbitrary shell escape hatches
  • hidden aliases for behavior that already has a canonical primitive
  • raw secret retrieval

On this page