Enhance FoundryModelInfo: Add 'tools' Attribute

Hey there, fellow developers! Have you ever found yourself diving into the world of Foundry, perhaps running foundry model list via the command-line interface (CLI)? You probably noticed how it presents a neat overview of your models, sometimes showing tasks like chat or even chat, tools. It’s a handy way to quickly grasp what each model is capable of, right? Well, we’ve got a little suggestion that could make working with Foundry even smoother, especially when you’re leveraging its SDK. The core idea is to add a tools attribute to the FoundryModelInfo object. This small but mighty addition could significantly improve how we interact with and understand model capabilities programmatically. Imagine the convenience of having this information readily available right within the SDK, just as you see it in the CLI output. This would streamline workflows, reduce the need for workarounds, and ultimately make your development process more efficient. Let’s explore why this change is so beneficial and how it could be implemented.

The Current Landscape and the Need for tools

Currently, when you list models using the Foundry SDK, the FoundryModelInfo object provides a good amount of detail, but it seems to be missing a direct indicator for tool usage. While the CLI’s output for foundry model list cleverly includes chat, tools to denote models that support tools alongside chat functionalities, this distinction isn't directly reflected in the SDK’s FoundryModelInfo object. This discrepancy can lead to a bit of confusion and requires developers to potentially infer tool capabilities through other means, or perhaps even make assumptions that might not always be accurate. The convenience of the CLI is that it gives you this quick visual cue. Bringing this tools information into the FoundryModelInfo object via the SDK would bring parity, offering developers the same level of insight they get from the command line, but in a format that's directly usable within their code. Think about it: if a model can handle both conversational AI and execute specific tools (like retrieving data, performing calculations, or interacting with other services), knowing this upfront is crucial for building sophisticated applications. Without this explicit tools field, developers might overlook a model's full potential or spend extra time trying to figure out if tool integration is possible, thereby reducing development velocity.

This isn't just about having more information; it's about having the right information at the right time. When you're building an application that relies on a model's ability to interact with external systems or perform specific actions, having a clear tools flag or list within the model's information object is invaluable. It allows for more robust error handling, better feature selection, and more intelligent routing of requests to the appropriate models. For instance, if your application needs to perform a data lookup, you could programmatically check if the selected model supports the necessary tools before even sending a request. This proactive approach prevents wasted computation and potential errors. The current situation, while functional, is akin to having a car dashboard that shows you the speed and fuel level but omits the indicator for whether the air conditioning is on. You can still drive, but having that extra piece of information makes the driving experience more informed and comfortable. The addition of the tools attribute would bridge this gap, providing a more complete and developer-friendly representation of model capabilities.

Proposed Implementation: FoundryModelInfo with tools

So, how could this enhancement be implemented? The suggestion is to modify the FoundryModelInfo object to include a new field dedicated to tool information. There are a couple of thoughtful ways this could manifest, catering to different scenarios and providing flexibility. One approach is to introduce a boolean tools attribute. This would be straightforward: true if the model supports tools, false otherwise. This is particularly useful for models where the primary distinction is simply whether tool invocation is a supported capability. For non-chat models, this could simply be None or false, clearly indicating that tool usage isn't applicable. For example, a model primarily designed for text generation might not have tool capabilities, so its tools attribute would be false. A more advanced model, capable of both conversation and executing predefined actions, would have tools: true.

However, to offer even greater granularity and power, a more comprehensive approach would be to have the tools attribute be a string or a list of strings (e.g., list[str]). This would allow you to not only know if a model supports tools but also which specific tools it supports. For instance, `tools: [