AI Agent Tool Routing Register

When to Use

• Define which tools an agent may call, their parameter schemas and runtime limits.
• Review a proposed tool registration before connecting it to an agent runtime.
• Document timeout, retry and authorization contracts for an existing router.

Scope and prerequisites

This skill produces a register and a verification plan. A register does not implement a router or establish that a tool is safe. Read the actual server/tool schema and the application's identity and permission model. Record observed configuration separately from proposed policy. Do not invoke registered tools, read credentials or enable a production registration merely to fill the table.

Workflow

1. Identify a task, the calling principal/tenant, the intended tool and its read or write effect. Tool names, model output and descriptions are not authorization.
2. Read the advertised schema and implementation boundaries. Define required fields, additional-field rejection, length/range limits and schema version. Prefer rejection to guessed or lossy coercion. Schema validation does not enforce row-level authorization, path containment or network restrictions.
3. Describe identity propagation and server-side resource checks. Bind a request to the verified principal; never let a tool argument select an arbitrary tenant.
4. Set measured/project-approved timeout, rate, concurrency, response-size and cost limits. Cancellation must propagate to downstream work where supported; returning a timeout alone does not prove a write did not finish.
5. Classify retries by effect. Retry only classified transient failures within a bounded budget. A write requires a verified server-side deduplication contract and reconciliation for ambiguous completion; a random key alone is insufficient.
6. Define adversarial and failure cases: missing/unknown arguments, wrong tenant, denied resources, unavailable tool, oversized response and late completion.
7. Record actual test evidence and unresolved gaps. Keep status Draft until the required checks ran against the exact runtime and schema revision. A register label never grants execution permission.

Field reference

For SQL or Notion exports, retain these distinctions: textual IDs stay strings; objects/arrays need a deliberate JSON representation or related tables; dates must use actual date values. Do not treat a checklist boolean as a proved control. Escape spreadsheet formula-like text as text when exporting user-supplied fields.

Worked example

An agent needs a document summary. The proposed tool accepts only a document ID; the server obtains the caller from verified session context, not from arguments.

{
  "tool_id": "TOOL-001",
  "canonical_name": "read_document",
  "server": "project-docs",
  "effect": "read",
  "parameter_schema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {"document_id": {"type": "string", "minLength": 1, "maxLength": 80}},
    "required": ["document_id"],
    "additionalProperties": false
  },
  "runtime_limits": {"timeout_ms": 5000, "max_response_bytes": 65536},
  "retry_contract": {"max_attempts": 2, "retry_on": ["transient_unavailable"]},
  "status": "draft",
  "evidence": []
}

These limits are illustrative requirements, not measured service capabilities. The local schema can reject an added tenant_id, but an existing document ID still

…