Skip to main content
@praxa/sdk publishes 12 framework-neutral tool definitions and executable bindings. They let an agent propose Praxa operations while the Integration Gateway continues to enforce scopes, tenant ownership, purpose, budgets, consent, idempotency, and revocation.
A model choosing a tool is a proposal, not authorization. Keep application policy and Praxa’s point-of-effect checks in the execution path.

Choose the integration shape

All 12 wire names intentionally begin with aura_. Praxa-named package exports preserve those compatibility identifiers.

1. Bind the executable tools

Each tool includes name, description, JSON Schema inputSchema, requiredScope, readOnly, and an execute() function.

2. Filter by granted scope and policy

Do not advertise a tool the current principal cannot use. Scope filtering is only an interface improvement; the Gateway must still reject unauthorized calls.
Apply your own product policy after scope filtering. For example, a read-only analysis mode can expose only definitions with readOnly === true.

3. Adapt the definitions

Framework JSON Schema adapters differ. Preserve the package schema and use the host’s documented raw-schema adapter instead of translating types by hand.

Approval placement

Never use a model-written summary as the authoritative approval record. Render the exact normalized action your application will submit, bind approval to that action, and let the Gateway perform its own authorization.

Handle tool errors

Return bounded, non-secret failure information to the model. Keep full error details in redacted server telemetry.

Test the agent boundary

  1. Assert the exact 12 registered names and required scopes.
  2. Assert unknown names are rejected before execution.
  3. Assert malformed inputs fail schema validation before a network call.
  4. Assert read-only mode hides every mutating tool.
  5. Assert a proposed mutation cannot execute without application approval.
  6. Assert an under-scoped or revoked token still fails at the Gateway.
  7. Assert tool failures return bounded model-visible errors with no token, provider body, memory text, or internal trace.
  8. Assert the model cannot override tenant, owner, scope, purpose, or budget fields that your application owns.

Best practices

  • Register only the tools relevant to the current task.
  • Keep tool descriptions factual and action-specific.
  • Separate read tools from mutations in your product policy.
  • Cap tool-loop iterations and total elapsed time.
  • Forward caller cancellation through AbortSignal.
  • Persist mutation idempotency keys before execution.
  • Record tool name, policy decision, status, and latency without logging inputs that can contain customer data.
  • Treat tool success as the returned contract state, not proof of an external provider effect unless the result contains that evidence.

Framework integrations

See the shorter adapter patterns for popular agent frameworks.

MCP host integration

Use the same governed surface through a remote MCP-capable host.
Last modified on August 14, 2026