Skip to Content
ToolsSDK tools

SDK tools

Many services publish a JavaScript library (an SDK, published as an npm package) instead of, or as well as, a web API. An SDK tool uses one function from such a library, for example “create a customer” from a payments library, and makes it a tool your assistants can call. You don’t write any code: you pick the package, the function and where each of its inputs comes from.

Create one

First, connect the library as an API.

  1. Open APIs, click Connect an API and pick SDK / npm.
  2. Give it a Name and, under Packages, add each package name and version.
  3. If the package lives in your company’s private package registry, tick Use a private npm registry and fill in the Registry URL, the Scope (optional) and the Auth token, picked from Credentials or created right there.
  4. Click Connect API and wait for almyty to finish reading the package. It lists what the package offers: its classes, functions and their inputs.

Then make the tool.

  1. Open Tools, click Create tool and, under Execution method, pick SDK / npm package.
  2. Name the tool, choose its SDK API, then pick the Package, the Class / export and the Method from what almyty found.
  3. For each input under Constructor parameters and Method arguments, choose where the value comes from: Tool param (the assistant supplies it), Hardcoded (a fixed value) or Credential (a key kept on Credentials). The tool params become the tool’s inputs.
  4. Optionally set a Response data path to return only part of the answer, and open View generated code to see what will run.
  5. Choose who can use it and click Create tool. Test it on its Test tool tab before you give it to an agent or gateway.

If the SDK API or the method you want is missing, open the API and check what almyty found when it read the package.

For developers

What is stored. The tool keeps an sdkConfig: package name and version, imports, optional client construction, the method call and each argument’s mapping. When it runs, almyty assembles JavaScript from that configuration and runs it in the same sandbox as JavaScript tools. You never paste generated code into the tool.

Inputs. The tool’s input schema comes from the package’s type information and the arguments you map as tool params. Review it before publishing: type information and runtime behaviour can differ, so test the method with representative inputs.

Credentials. A credential mapping stores a reference such as credentialName.field, not the secret. Use hardcoded values for non-secret constants. The private registry’s token is a separate credential the SDK API points at (npmRegistry.credentialId); it only authorizes downloading the package, not the calls the method makes.

Limits. Installing and reading the package must succeed before its methods can be picked. Native addons, access to the host and outbound requests stay subject to the sandbox’s restrictions, so a package that installs is not proof every export runs.

See the API reference for creating SDK APIs, package maps and tool configuration.

MCP toolsSOAP tools