Is there a machine-readable way to inspect the tools injected into a built agent?

[yuehua1213]

I’m looking at the boundary between phi-agent and consumer-provided tools. The README is unusually clear that the framework provides infrastructure while tools come from agent-works, phi-tools, or custom Tool implementations.

For teams evaluating an assembled agent, that makes the effective capability set depend on runtime composition rather than the phi-agent package alone. A source-linked inventory of the registered tools—including origin, config/dependency requirements, and the build/version it was observed in—could make two agents built on the same framework easier to compare and reproduce.

Does the builder or session API already expose a stable machine-readable inventory of injected tools? If not, where would you consider the authoritative boundary for generating one?

[hibuka-labs]

Thanks for this — it's exactly the right question to ask at this boundary. That clear separation between framework and consumer-provided tools is something we think about a lot, and your framing of it as "runtime composition" is spot-on.

Coincidentally, we had this in the works already: PhiAgent::list_tools() was committed a couple of days ago, and it just shipped in v0.2.2:

let tools: Vec<(String, String)> = agent.list_tools().await;
// → [("execute_command", "Execute a shell command..."), ...]

The REPL also responds to tools directly.

It only returns name + description today — the per-tool origin/version metadata you described isn't there yet. That feels like the right next step, and it probably belongs on the Tool trait in agent-base. A fn metadata(&self) -> ToolMetadata method could fill that gap cleanly. Would be interested in your take on the shape of that struct if you have one in mind.

[yuehua1213]

Thanks — glad the framing landed, and congrats on shipping list_tools() in v0.2.2. Name + description is already a useful runtime surface.

For the next layer, I’d start with the questions the metadata needs to answer:

• What stable identity does this tool have?
• Where did this implementation come from?
• Which implementation or schema version did the agent see?
• Which metadata is intrinsic to the tool, and which was added when the consumer registered it?

A minimal record might include:

• stable tool ID,
• display name and description,
• optional source reference,
• optional implementation version or content digest,
• optional schema digest.

I would keep semver and content digest separate, since they answer different questions.

One design question I’m less certain about: registration origin may belong to the builder/registry rather than the Tool trait itself, because the same tool implementation can be registered by different consumers. The Tool trait could expose intrinsic metadata, while the assembled agent records composition-time origin.

Keeping list_tools() as the lightweight REPL view and adding a richer metadata view separately sounds sensible.

Happy to review a sketch once you decide where intrinsic versus composition metadata should live.

[hibuka-labs]

Thanks for the detailed breakdown — the intrinsic-vs-composition distinction is exactly the right way to think about this.

We shipped ToolMetadata on Tool::metadata() in agent-base v0.1.9 / phi-agent v0.2.3. The struct covers what belongs to the tool itself:

Field	Who defines it
name / description	Tool impl
origin	Crate of origin — phi-tools, agent-base, custom
version	Crate version
requirements	Runtime deps (e.g. chrome-cdp)

let tools: Vec<ToolMetadata> = agent.list_tools().await;

Here's what you see in the phi CLI (cargo install phi-agent):

phi> tools
  Registered tools (2):

  execute_command  phi-tools  v0.1.3
    Execute a shell command locally...

  update_plan  agent-base  v0.1.9
    Create or update a task plan...

The default implementation automatically labels user-defined tools as custom / vunknown — no extra work needed unless you want to supply your own origin.

On origin vs the registry: we kept it on the trait because a tool's source crate is a property of the implementation, not of who wires it in. LocalShellTool is always from phi-tools regardless of consumer. The composition-time "who registered this" layer you described is structurally ready on the builder side — we just haven't had a concrete use case that needs it yet. When it shows up it's a one-field addition. Happy to iterate on the shape then.

[yuehua1213]

Thanks — this closes the boundary clearly. Tool-intrinsic metadata belongs to the implementation, while composition-time “who registered this” remains on the builder side. I’ll record v0.2.3 as an observable inventory surface, not as behavioral verification. No further ask from me. 李跃华 ***@***.***

[yuehua1213]

Thanks — v0.2.3 gives us a concrete validation boundary. Would you be open to a small public evidence run against a frozen phi-agent/agent-base commit? The exam would only assert: 1. a built agent returns ToolMetadata for its registered tools; 2. crate-backed tools expose origin + version + requirements; 3. a user-defined tool is explicitly marked custom / unknown rather than being attributed to the framework. We would use the repository’s own preferred test command and publish the frozen commit, environment, test fixture, and result. This would not claim that ToolMetadata proves the tool works; only that runtime capability composition is inspectable and its uncertainty is explicit. If that scope is useful, could you point me to the best existing test file/command and confirm whether public CI links may reference the result? Best, Yuehua

[hibuka-labs]

Thanks for the thoughtful analysis! You're right that the runtime composition model makes tool inventory especially important.

To answer your first question: yes, PhiAgent::list_tools() already returns Vec<ToolMetadata> with name, description, origin, version, and requirements fields. Crate-backed tools (e.g. UpdatePlanTool from agent-base) report their origin and version, while user-defined tools default to origin: "custom" and version: "unknown".

We don't yet have dedicated tests for this, so a contribution would be very welcome. Feel free to open a PR — adding the assertions you described to tests/integration_test.rs would be a natural fit. Happy to review!