agentsclimarketplace
Sign in

Configure

Skill Alation/alation-plugins/skills/configure

Use when the user wants to create, modify, or manage AI agents, custom tools, LLM configurations, or data source connections. Triggers: create agent, configure agent, clone agent, publish agent as tool, create HTTP tool, create SMTP tool, add tool, configure LLM, bring your own model, BYOM, add data source, create connection, parameter bindings, tool authentication, set up agent, set up tool, manage LLM credentials. Key signal: if "set up" refers to infrastructure (agents, tools, LLMs, connections), use this skill. If "set up" refers to scheduling or automation, use automate. Not for scheduling or workflows — use automate. Not for creating data products — use curate.From its SKILL.md

Install
npx -y skills add Alation/alation-plugins --skill configure

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.2 KB, as published. Nobody here has run it

Configure

Create and manage agents, tools, LLMs, and data source connections.

Routing

User IntentCLI CommandWhen to Use
Manage AI agentsscripts/run-cli agentCreate, clone, update, delete, publish agents
Manage toolsscripts/run-cli toolCreate HTTP/SMTP tools, update, delete
Manage LLMsscripts/run-cli llmBYOM setup, credentials, LLM configs
Manage data sourcesscripts/run-cli datasourceCreate, update, delete data source connections

Not This Skill

  • User wants to schedule or automate workflows → use automate
  • User wants to query data or chat with an agent → use ask
  • User wants to create a data product → use curate
  • User wants to browse data source contents → use explore

Key distinction: configure creates and manages the infrastructure (agents, tools, LLMs, connections). automate uses that infrastructure in workflows. "Create an SMTP tool" is configure. "Set up a daily email report" is automate.

Agent Configuration

Creating an Agent

  1. Define the agent's purpose. What should it do? Be specific — "answer sales questions against the superstore dataset" is better than "answer questions."

  2. Identify the data and context it needs. What data products, data sources, or domain knowledge will the agent work with? Some of this becomes fixed tool bindings (step 5), some goes into the agent prompt (step 6).

  3. Select tools. Browse available tools with scripts/run-cli tool list and see references/default-tools.md for the selection matrix. Pick the combination needed for the agent's purpose. If a required tool doesn't exist (e.g., an HTTP or SMTP integration), create it first — see Tool Configuration below.

  4. Create the agent config with the selected tools: scripts/run-cli agent create < config.json Tip: if a default agent is close to what you need, clone it as a starting point: scripts/run-cli agent clone ID

  5. Configure tool parameter bindings. Bindings control how tool parameters get their values at runtime, constraining what the agent can do for reliability and consistency. For each tool parameter, choose a binding source:

    • fixed: The value is always the same. Use this to lock a tool to a specific resource like a data_product_id. The agent can't change it.
    • user: The caller provides the value when invoking the agent. Use for things like a recipient email or a data_product_id when the agent supports multiple products.
    • agent: The LLM decides the value based on the conversation. This is the default for most parameters — the agent interprets the user's message and figures out what to pass to the tool. For example, data_product_id can be agent-determined if the agent has a search tool and is expected to find the right product itself.

    Some parameters are hidden from the model (x-hidden-from-model: true) and must be fixed or user since the LLM can't see them to decide.

    See references/bindings.md for JSON structure, validation rules, and detailed patterns.

  6. Configure the agent prompt. Describe the agent's high-level goal, its domain context, and when to use each of its tools. This is the agent's system prompt — it guides the LLM's behavior.

  7. Choose the LLM. Pick a model powerful enough for the task. See references/default-llms.md for recommendations by use case.

  8. Test the agent. Use the ask skill to send it a message and verify it works: echo '{"message": "..."}' | scripts/run-cli chat send <agent_uuid>

Publishing as Tool

scripts/run-cli agent publish ID makes an agent callable by other agents.

Tool Configuration

Creating HTTP Tools

See references/http-tools.md for full guide. Key constraints:

  • HTTPS only (no HTTP, no localhost, no IP addresses)
  • Auth types: API_KEY, BEARER, BASIC, OAUTH2, NONE

Creating SMTP Tools

See references/smtp-tools.md for provider-specific configs (SendGrid, AWS SES, Gmail, M365).

Important: Before creating a new tool, always list existing tools first with scripts/run-cli tool list. An SMTP or HTTP tool may already be configured.

LLM Configuration (BYOM)

  1. Create credentials: scripts/run-cli llm creds-create < creds.json See references/credentials.md for provider-specific formats (API_KEY, AWS, AZURE, GCP).
  2. Validate: scripts/run-cli llm creds-validate ID --provider PROVIDER --model MODEL
  3. Create LLM config: scripts/run-cli llm create < config.json referencing the credential ID. See references/providers.md for provider model details.

Data Source Management

  • scripts/run-cli datasource list / scripts/run-cli datasource get ID / scripts/run-cli datasource create / scripts/run-cli datasource update ID / scripts/run-cli datasource delete ID
  • Note: connector setup, MDE, and QLI configuration require the Alation web UI.

Common Mistakes

Mistake: Copying a data product's full spec into the agent prompt to "teach" it about the data. Why it seems reasonable: the agent needs to know what data is available. Instead: Set data_product_id as a fixed parameter binding on the agent's tools. The tools will fetch the product context at runtime. See references/bindings.md pattern 1.

Mistake: Creating a new SMTP tool when one already exists. Why it seems reasonable: the user asked to send email. Instead: Run scripts/run-cli tool list first. Look for existing tools with tool_type: "SMTP".

Mistake: Asking the user for an API token or credentials during agent/tool creation. Why it seems reasonable: auth might seem like a per-operation concern. Instead: Authentication is handled automatically by credentials.local. If auth fails, direct the user to the setup skill.

Next Steps

After finishing configuration, suggest next steps to the user — but don't proceed without their go-ahead unless their original request already implies it.

  • After creating an agent or tool: Share the url from the CLI response so the user can view it in the Alation UI.
  • After creating an agent: Always offer to test it by sending a message via the ask skill. Then suggest scheduling it with the automate skill if relevant.
  • After creating a tool: Suggest adding it to an agent (using this skill) or wiring it into a workflow (using the automate skill).

Red Flags

  • "I'll add the product schema to the agent's system prompt" — use parameter bindings instead.
  • "I need to create an SMTP tool" — check if one exists first.
  • "What's your API token?" — credentials come from credentials.local, not the user.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.