Improvements for MCP-based agents · modelcontextprotocol/modelcontextprotocol · Discussion #111 (original) (raw)

@jspahrsummers This is a really good list - I'd add one more item here, and would be curious about your thoughts. Specifically, for agentic flows, you can imagine a world where agents have the ability to discover, then call, mcp servers that have a per use cost, but WITHOUT a heavy user involved registration flow. So, a user asks for the weather, the agent discovers a weather server, it has some sort of budget for calls, it determines this is a good use of funds, and then calls the weather MCP server for a penny.

In order to enable this flow, I think there needs to be some metadata / capabilities definition on the tool type itself. I don't think the properties are quite right here - if I'm being dilligent about architecture here, I want the weather call to just take a city, state, country, I don't want to co-mingle all the different permutations of how payments could work in the tool call - that is to say, imagine you have some mechanism for per-use call, but then some other mechanism for a subscription fee, it doesn't feel right to basically pollute the "method" invocation properties with optional properties around this.

I think this would tend toward some sort of custom "extension" (which I think the MCP world we're calling a custom capabilities) for payment types (proof of pre-payment, usage based payment, etc). So, I would say, some sort of metadata extension here for tool calls themselves so in the list view you can get custom capabilities / extensions, and in the tool call you can supply custom required fields outside the primary method call.

I do believe this is separate than a pure call property, but I could be wrong. That is to say, you could always have a property that is "proof of prepayment" but that's not an explicit "extension" or "capability" that's being defined and specific protocol being adhered to, which makes it hard to infer. So, I'd like to say, this tool requires adherence to pre-payment protocol XYZ, which means we're expecting some sort of proof of pre-payment identifier passed in in the tool metadata.

Thoughts?

EDIT:

I'll add, this COULD be a server level capabilities where tool calls then expect a header with payment information, but I think that's a bit non-ideal because you might still have cost metadata on a call by call basis that you want to communicate. I've seen other proposals on here for cost metadata in the well-known file, but that also just feels weird, because based on the agent identity (from authorization) the cost might be different.