Distinguish Agent/MCP/A2A/etc models in OASF object

[nishantapatil3]

Hi Team, is model.ref.type field is being used for any other purposes? wondering if this can be used to distinguish between agent/mcp/a2a : ObjectType which can be the type used for OASF type in order to extend the schema to support only MCP OASF object or only A2A OASF object etc (without agent stuff like skills or categories). Correct me if I am wrong or suggest better method. TIA

> dirctl info sha256:4c9226b3b2d2e66b7a67ea0517ef96470dc453568314a833addbb0739ea80b1f
{
  "digest": "sha256:4c9226b3b2d2e66b7a67ea0517ef96470dc453568314a833addbb0739ea80b1f",
  "type": "mcp",
  "size": 10031
}%                                                                                                                                                                                                                 
> 
> 
> dirctl pull sha256:4c9226b3b2d2e66b7a67ea0517ef96470dc453568314a833addbb0739ea80b1f
{
  "name": "nishantapatil3/mcp2",
  "version": "v1",
  "description": "This is a model for the MCP server for PoC project",
  "authors": [
    "nishantapatil3"
  ],
  "created_at": "2025-07-07T14:13:20-07:00",
  "extensions": [
    {
      "name": "schema.oasf.agntcy.org/features/runtime/mcp",
      "version": "v1.0.0",
…   

[ramizpolic]

Hi @nishantapatil3, great question. Although it is possible to use custom types for objects, some operations on the Directory side will not be supported. The Directory API relies on the general OASF object to enable things like search, announcement, discovery, and other operations in order to support other usage flows. For custom objects, only the storage is supported. Hope this answers your question.

[sfph]

Hi @ramizpolic and @muscariello! We are tasked with adding mcp/a2a agents (including search, etc) to the backend. It seems they must be treated as first class objects but stored as addendums, which makes things a bit tricky. Hoping for a way to tag/identify these objects that can help uniquely identify them (and deal with scenarios like not having an agent in the directory for a particular mcp server, or transitions if an agent is deleted but mcp/a2a should be retained, etc) and not be onerous on the search path (i.e having to store and dig through guts of each record).

[muscariello]

@sfph what is that you're trying to do that you cannot do with OASF? We support MCP and A2A data.

[nishantapatil3]

@muscariello we are in the dev phase of adding MCP and A2A support to Agntcy Hub. So MCP server card is planned to have only MCP related field in OASF object which means no skills/categories and only mcp in extension.

There can be two ways MCP configuration can be defined.

1. OASF object -> Agent Record = Agent + MCP + prompts etc (extensions) -> MCP is associated with an agent
2. OASF object -> MCP Server Record = MCP (extensions)

So we are focusing on point 2 where users would select from the drop down to search for MCP servers alone (as shown in picture) similarly for A2A records. These records would be treated as first class citizens is what Selina was mentioning before.

[muscariello]

Hi @nishantapatil3
There is no such thing as an MCP card AFAICT. There is an in-progress work on an MCP extension in OASF but nothing in OASF prevents a user from adding several objects into a record. Having said that, you can say that a record which contains a single MCP extension is what you may want to call MCP card by using the A2A terminology, which you mix here.
However, I would not mix the two things because an A2A card is an object A2A defines unambiguously.
The current work on the MCP extension is to make sure some downstream applications can use it to announce and discover MCP servers records by using agent directory. The current first example is Microsoft Copilot in VSCode, but also Github Actions.

From your example above you call out "Agent" but it's unclear what it is as there is no unanimous definition of agent and we want to let the user define what they want. There is a PR to remove the term agent from OASF core data models as it creates ambiguity.

For many, an agent is defined formally by having at least one LLM with a system prompt and at least one tool. If the tool is associated to the LLM via an MCP server or via direct tool calling capabilities it does not change the definition.

The current OASF framework allows you to do what you are describing already, w/ some caveats: MCP extension is in progress and the agent definition is actually undefined unless you specify it explicitly for your downstream service but it does not require to change OASF for that.
As we want to be vendor neutral and future proof in case new applications come into play we do not want to define explicitly agents.