Skip to content
PRESHaiPRESHaiPRESHos Platform

Tool registry

The tool registry is the agent-config building block for atomic capabilities: tools and toolsets agents can call. The registry surface is /ai/tools. Each row carries name, key, source, agents, last called, 30-day calls, and status; filters cover source, status, unadopted tools, and never-called tools. Every tool is a capability and a liability. Tools often reach external systems through connector bindings and MCP installs; the tool is only real for the tenant when that chain is verified in-environment.

  • Separate read from write. Reads can be broad; writes earn their place one by one, each with a written rationale.
  • Separate draft from execute. Prefer tools that propose (draft a change, open a ticket update) over tools that apply, then gate the apply step with approvals.
  • A connector-backed tool is only real when its binding exists for the tenant: install settings.object_mappings scoped to org, package, and connection, identity binding:<uuid> in ai.connector_object_map, destination from the target catalog (for example targetObject: 'work-items' with workItemTypeId; never retired tasks/deliverables).
  • Registered-adapter reality check: HubSpot and ConnectWise PSA are registered; Salesforce scaffolds are not implementations; outbound HubSpot writes are disabled. Unknown providers fail closed.
  • One canonical tool per action. Overlapping tools produce inconsistent sessions and confused approvals.
  • Read the adoption columns. Agents shows which agents call the tool; last-called and 30-day calls show whether it earns its place. A never-called tool is a removal candidate, not a trophy.
Tools registry: callable tools with source, agent adoption, call recency, and status

Per-tool verification checklist

Section titled “Per-tool verification checklist”
  • Works standalone in a test session.
  • Binding coordinates confirmed for this tenant (org, package, connection), not “the connector exists.”
  • Scope respected: reaches only its intended systems and data, under the correct org_id.
  • Approval behavior as designed; MCP-backed tools show fingerprint recheck and guarded fetch verified, not assumed.
  • Added to the capabilities register with kind, rationale, and verification date.

Binding rules in depth: Extend a connector, SDK concepts. The registry surface is /ai/tools; treat the product UI there as the source of truth for fields beyond the guides.