Runtime Tool Discovery
Runtime tool discovery shows which tools a specific client, API key, tenant, module, and configured agent can see at the time of use. It is the source for building reliable Agent workflows because the visible tool set can change when scopes, module enablement, tenant configuration, or agent binding changes.
Use this page when a workflow needs to confirm available tools, investigate an empty tool list, or prepare an access package for a new Agent workflow.
Discovery flow
What affects visible tools
The tool list is tenant-specific. A tool appears only when the access path and configured workflow support it.
| Factor | What it controls | Review question |
|---|---|---|
| Endpoint | Which product or module surface the client enters. | Is the client using the endpoint intended for this workflow? |
| API key | Which tenant and access package the client represents. | Was the key issued for this tenant, workflow, and environment? |
| Scopes | Which tool families can be seen or called. | Does the key include the minimum approved scopes for the task? |
| Module enablement | Whether the product module is available in the tenant. | Is the module enabled and ready for this customer environment? |
| Agent binding | Which tools belong to the configured agent. | Is the tool assigned to the agent that users enter from Agent Hub? |
| Risk and review boundary | Whether a tool can be used as read-only, analysis, draft, or action-capable. | Does the workflow have the review path required by the tool type? |
| Data readiness | Whether the tool can return useful results. | Are required records, documents, signals, or scenes ready enough for use? |
Use Access and Scope Planning to plan the access package before testing discovery.
Discovery checklist
Before building prompts, automation, or workflow logic around a tool, confirm:
- The client is connected to the correct endpoint.
- The API key belongs to the intended tenant and environment.
- Runtime discovery returns the tool name expected by the workflow.
- The key has the required scopes for that tool.
- The agent entry in Agent Hub is the one expected by the user.
- Required source data, documents, scenes, or operating records are available.
- Missing tools, unexpected tools, and scope gaps are recorded before launch.
Record the visible tool set in the Workflow Run Record for accepted runs.
Tool visibility patterns
| Pattern | What it usually means | Next step |
|---|---|---|
| Tool list is empty | Endpoint works, but the key has no matching tool visibility. | Check endpoint, tenant, scopes, module enablement, and agent binding. |
| Only read tools appear | The access package supports investigation workflows. | Keep the workflow read-only or request reviewed action access. |
| Module tools are missing | The module may be unavailable in this tenant or the endpoint may be wrong. | Confirm module enablement and endpoint selection. |
| Tool appears but call is blocked | Discovery succeeded, but scope, input, risk gate, or review policy stopped execution. | Use Tool Execution Governance to review the call path. |
| Tool visibility differs by user | Keys, scopes, tenant context, or agent binding differ. | Compare access packages and Agent Hub entry points. |
| Tool output is weak | Tool access works, but source data is incomplete or stale. | Run Data Readiness before expanding the workflow. |
Tool reference vs runtime discovery
The MCP Tool Reference explains available tool families, expected parameters, and scope planning. Runtime discovery confirms what the current client can actually use in the current tenant.
Use both views:
| Need | Use |
|---|---|
| Plan candidate tools and scopes | Tool Reference and Scope Reference. |
| Validate the current access package | Runtime discovery. |
| Debug a missing tool | Runtime discovery plus endpoint, scope, module, and agent checks. |
| Record evidence for a run | Runtime-visible tool list in the run record. |
Discovery and Agent Hub
Agent Hub is the user-facing entry point. Runtime discovery is the technical confirmation that the configured agent has the expected tools available.
Before a Hub entry is treated as ready, confirm:
- the card name and summary match the tool-supported workflow;
- the entry route sends users to the correct module, dashboard, assistant, or workflow;
- the visible tool set supports the promised task;
- data-health hints match the tools' source dependencies;
- action-capable tools have confirmation or approval paths.
Use Agent Hub and Agent Lifecycle and Configuration to manage the product entry point.
Troubleshooting
| Symptom | Check |
|---|---|
| Connection fails | Host, endpoint path, trailing slash, and API key header. |
| Tool list is empty | Tenant, key, scopes, endpoint, module enablement, and agent binding. |
| Tool name fails | Replace hard-coded tool assumptions with runtime discovery. |
| Expected module tool is missing | Confirm module endpoint and customer enablement. |
| Output lacks evidence | Check source readiness and evidence requirements. |
| Action tool is blocked | Review scope, risk gate, confirmation, human approval, and audit requirements. |
Use MCP Errors and Audit for detailed failure triage.
Related pages
| Need | Use |
|---|---|
| Plan endpoints and scopes | Access and Scope Planning |
| Review execution behavior | Tool Execution Governance |
| Define risk and review gates | Risk Governance and Safety |
| Check tool and scope reference | MCP Tool Reference and Scope Reference |
| Diagnose errors and audit | MCP Errors and Audit |