Skip to content

Add a run-tool skill for direct integration tool calls - #2

Merged
icecrasher321 merged 2 commits into
mainfrom
add-run-tool-skill
Sep 2, 2026
Merged

Add a run-tool skill for direct integration tool calls#2
icecrasher321 merged 2 commits into
mainfrom
add-run-tool-skill

Conversation

@icecrasher321

Copy link
Copy Markdown
Contributor

What

Adds run-tool, a skill for sim 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-workflow now 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 get labels every parameter with a visibility, and that label decides where the value comes from:

visibility Who supplies it
user-or-llm the caller, in --input
user-only the caller, but as a {{VAR_NAME}} reference resolved server-side
hidden Sim, from a bound credential or a hosted key — never the caller

Then the credential binds by the tool's own declaration: oauth.required wants --credential-id; hostedApiKey: always wants 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 skills
  • bun run test — 7 passed
  • Registered in expectedSkillNames; both plugin manifests point at ./skills/ as a directory, so neither needed a change.

`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.
@icecrasher321
icecrasher321 merged commit bd22424 into main Sep 2, 2026
2 checks passed
@icecrasher321
icecrasher321 deleted the add-run-tool-skill branch September 2, 2026 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant