Updates to draft 1.0 #2
Conversation
specification/http/1.0/openapi.json
Outdated
| }, | ||
| "additionalProperties": true | ||
| }, | ||
| "user_id": { |
There was a problem hiding this comment.
How is the validity of the user-id established? How is it used downstream?
There was a problem hiding this comment.
Specifying a valid user ID is up to the client. The downstream tool may or may not need it.
I think this would be a good thing to call out in the requirements section, actually -- the difference between a tool that doesn't care who the user is (Calculator.Add) and one that does (Gmail.SearchEmails)
|
@eyurtsev My latest commit addresses most (not all) of your comments above. I will continue iterating tomorrow. |
eyurtsev
left a comment
eyurtsev
left a comment
There was a problem hiding this comment.
forgot to submit the comments yesterday
| "items": { | ||
| "type": "object", | ||
| "properties": { | ||
| "id": { |
There was a problem hiding this comment.
Do the secrets correspond to things like API keys that users will be passing directly as part of the request?
There was a problem hiding this comment.
Yes, but passed by the client not by the user.
This gives the client the (optional) capability to load a secret like an API key when a tool is called, but keep that invisible from the caller/user.
There was a problem hiding this comment.
Should we add an optional description field?
There was a problem hiding this comment.
description would be useful for humans, but not sure if it's useful for machines (the tool's code).
There was a problem hiding this comment.
One workflow I was imagining is that a developer looks needs to add a specific API key as part of the context for a given tool.
e.g., the tool needs open_api_key, but the developer isn't familiar with what the key is or how to get access to it. So the description could include instructions on how to acquire the key.
And then the developer would client to pick up the key (e.g., as an env variable).
We can drop if this workflow doesn't make sense
Spartee
left a comment
Spartee
left a comment
There was a problem hiding this comment.
One comment that can be addressed in further reviews and revisions.
| }, | ||
| "description": { | ||
| "type": "string", | ||
| "description": "A human-readable explanation of the tool's purpose. This field can be used by both humans and AI models." |
There was a problem hiding this comment.
I disagree that the emphasis should be on human readable. The main purpose of the description is to communicate to the predictor when and under what scenarios to use that particular tool.
There was a problem hiding this comment.
Thanks, I will clarify this
Work in progress: Updates and cleanup in draft 1.0