Add registry functions that return raw schema information #21
Conversation
| return { | ||
| description: 'Returns information about Pulumi Registry resources', // Consider making this more specific, e.g., "Resource not found" | ||
| content: [ | ||
| { | ||
| type: 'text' as const, | ||
| text: `No information found for ${args.resource}${args.module ? ` in module ${args.module}` : ''}. Available resources: ${availableResources.join(', ')}` // Slightly improved message | ||
| text: `No information found for ${args.resource}${args.module ? ` in module ${args.module}` : ''}. You can call list-resources to get a list of resources` // Slightly improved message |
There was a problem hiding this comment.
Would it be better to just let the LLM decide to call list-resources? It may even have already called list-resources. I've been running into a lot of context exceeded issues so have been trying to limit it.
corymhall
force-pushed
the
corymhall/schema
branch
from
20e40ed to
5b426de
Compare
| @@ -51,8 +86,44 @@ export const registryCommands = function (cacheDir: string) { | |||
| } | |||
|
|
|||
| return { | |||
| 'get-type': { | |||
There was a problem hiding this comment.
This function is pretty low-level because it requires knowledge of the specific $ref. The idea is that it would have already called get-resource which would contain the $ref.
Another option would be to either add a separate function or update this one to also be more generic and take
{
provider: string,
module: string,
propertyName?: string,
ref?: string,
}
So then it could try and find the type if it only knew the property name (which it would know from looking at code).
There was a problem hiding this comment.
Should this tool have the same arguments as get-resource - provider, version, module, name? Or what's the difference?
There was a problem hiding this comment.
It should definitely have version, i'll add that.
For the others, that's what I was asking about. If get-resource returns something like
"inputProperties": {
"nestedProp": {
"type": "object",
"$ref": "#/types/provider:module/SomeType:SomeType"
}
}Then the LLM would have the exact type token to call get-type.
The question is whether there is a use case for calling get-type on it's own. For example if the LLM were evaluating some code:
new aws.s3.Bucket('my-bucket', {
acl: 'read',
});It could potentially call just get-type with
{
"provider": "aws",
"module": "s3",
"name": "acl"
}But that has very limited usefulness. The LLM would probably want to see all the properties on Bucket so would probably need to call get-resource anyway. Also if the type returned had any nested types then it would need to call get-type for those as well.
|
This change is part of the following stack: Change managed by git-spice. |
| text: JSON.stringify({ | ||
| // for now leaving out: | ||
| // - `description`: Can be pretty large and contains all language examples (if we knew the language we could extract the specific language example) | ||
| // - `properties`: contains a lot of duplicated properties with `inputProperties` and is probably less useful |
There was a problem hiding this comment.
properties may be important to read the right resource outputs. Should we filter out the inputProperties keys from properties and return the remaining set?
src/pulumi/registry.ts
Outdated
| /** | ||
| * A type with additional properties | ||
| */ | ||
| additionalProperties?: ResourcePropertyItems; |
There was a problem hiding this comment.
Do we need to define all these properties? Won't we just serialize whatever properties we read from the schema as-is?
| @@ -51,8 +86,44 @@ export const registryCommands = function (cacheDir: string) { | |||
| } | |||
|
|
|||
| return { | |||
| 'get-type': { | |||
There was a problem hiding this comment.
Should this tool have the same arguments as get-resource - provider, version, module, name? Or what's the difference?
This PR updates the
get-resourcefunction to return the JSON schema instead of a formatted string.It also adds a new function
get-typeto return information on a specific type.fixes #20