Add a run-tool skill for direct integration tool calls - #2
Merged
Conversation
`sim tools execute <toolId>` runs one built-in integration tool without a
workflow, resolving the credential server-side. Nothing in the skill set
covered it, so an agent asked for a single action against a connected service
built a graph instead.
The payload is the part an agent gets wrong: which auth path a tool wants is
decided by the `visibility` its catalog entry publishes per parameter, not by
guessing. `user-only` takes a `{{VAR_NAME}}` reference resolved server-side,
`hidden` is Sim's to fill, and a tool declaring `oauth.required` wants a
`--credential-id` rather than a key. Getting that wrong reads as an upstream
401 that names nothing.
Also cross-references it from build-workflow, which otherwise implies a graph
is the only way to reach an integration.
…eter
Sixty-eight tools — Snowflake among them — declare `oauthCredential` or
`credential` as a required `user-only` parameter with no `oauth` block. The
skill's rule for `user-only` ("pass a `{{VAR_NAME}}` reference in --input")
would have sent an agent straight into the endpoint's refusal: a credential
under any spelling in --input is a 400 pointing at the top-level field.
Name that shape beside `oauth.required` as a second trigger for
`--credential-id`, and state the endpoint's actual contract once: --input
accepts exactly what `tools get` publishes as the caller's to send, and refuses
the rest by name.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
run-tool, a skill forsim tools execute <toolId>— running one built-in integration tool directly, without wrapping it in a workflow.Nothing in the current five skills covered tools, so an agent asked for a single action against a connected service builds a graph for it.
build-workflownow cross-references this in three lines, since it otherwise implies a graph is the only route to an integration.Why this shape
The skill's payload is the one thing an agent reliably gets wrong: which auth path a tool wants is published, not guessable.
sim tools getlabels every parameter with avisibility, and that label decides where the value comes from:visibilityuser-or-llm--inputuser-only{{VAR_NAME}}reference resolved server-sidehiddenThen the credential binds by the tool's own declaration:
oauth.requiredwants--credential-id;hostedApiKey: alwayswants the key omitted entirely. Guessing here produces an upstream 401 that names nothing, which is a bad thing for an agent to have to debug.The invariants section carries the two rules that matter operationally: never print a resolved secret (the caller holds a credential id and a variable name, nothing more), and never retry a failed write blind — a tool call is not idempotent, and a retry can duplicate the message or record the first attempt created.
Verification
bun run scripts/validate-skills.ts— validates the plugin and 6 skillsbun run test— 7 passedexpectedSkillNames; both plugin manifests point at./skills/as a directory, so neither needed a change.