Skip to main content
Glama

Sliq

by com.getsliq
OverviewDiscussionsAdmin

Create Agent

create_agent

Create a background agent that runs automatically based on triggers.

Do NOT create a new agent for follow-ups, event handlers, or scheduled checks that continue an existing agent's work — use add_trigger on that agent instead.

When the agent matches one of the built-in agent templates — the template_id enum lists them — set its template_id and seed workspace.inputs per that agent's skill guide. The template_id runs the template's setup; seed a template's inputs without it and the agent is not fully wired up. If no template fits, omit template_id and the agent runs as a general background agent.

You MUST call get_skill_guide('trigger_code') before writing any trigger's code — the qualification rules, sandbox globals, tool surface, and out contract live in the skill. code runs on the trigger's next firing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesComplete instructions for what the agent should accomplish. Write as if instructing another assistant. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.
titleYesShort name for the agent (e.g. "Outreach to Q2 leads", "Email triage")
triggersYesList of triggers that determine when the agent runs. An agent can have multiple triggers of different types (e.g. one schedule plus one event handler) — they fire independently. At least one trigger is required. In each trigger's prompt, name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.
workspaceNoOptional `{'inputs': {...}, 'outputs': {...}}` dict that seeds the agent's workspace. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.
template_idNoOptional template ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / goal / description
      Previous value: -"Complete instructions for what the agent should accomplish. Write as if instructing another assistant."New value: +"Complete instructions for what the agent should accomplish. Write as if instructing another assistant. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat."
    • changedInput schema / properties / triggers / description
      Previous value: -"List of triggers that determine when the agent runs. An agent can have multiple triggers of different types (e.g. one schedule plus one event handler) — they fire independently. At least one trigger is required."New value: +"List of triggers that determine when the agent runs. An agent can have multiple triggers of different types (e.g. one schedule plus one event handler) — they fire independently. At least one trigger is required. In each trigger's prompt, name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat."
    • changedInput schema / properties / workspace / description
      Previous value: -"Optional `{'inputs': {...}, 'outputs': {...}}` dict that seeds the agent's workspace."New value: +"Optional `{'inputs': {...}, 'outputs': {...}}` dict that seeds the agent's workspace. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat."
  2. Changed4 schema fields changed
    • changedInput schema / properties / goal / description
      Previous value: -"Complete instructions for what the task should accomplish. Write as if instructing another assistant."New value: +"Complete instructions for what the agent should accomplish. Write as if instructing another assistant."
    • changedInput schema / properties / title / description
      Previous value: -"Short name for the task (e.g. \"Outreach to Q2 leads\", \"Email triage\")"New value: +"Short name for the agent (e.g. \"Outreach to Q2 leads\", \"Email triage\")"
    • changedInput schema / properties / triggers / description
      Previous value: -"List of triggers that determine when the task runs. A task can have multiple triggers of different types (e.g. one schedule plus one event handler) — they fire independently. At least one trigger is required."New value: +"List of triggers that determine when the agent runs. An agent can have multiple triggers of different types (e.g. one schedule plus one event handler) — they fire independently. At least one trigger is required."
    • changedInput schema / properties / workspace / description
      Previous value: -"Optional `{'inputs': {...}, 'outputs': {...}}` dict that seeds the task's workspace."New value: +"Optional `{'inputs': {...}, 'outputs': {...}}` dict that seeds the agent's workspace."
  3. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide almost no coverage (readOnlyHint=false, destructiveHint=false are defaults), so the description carries the full burden. It discloses important behavioral traits: code runs on the trigger's next firing, template_id runs template setup and incomplete seeding leaves the agent unwired, and get_skill_guide('trigger_code') is a mandatory prerequisite. This is substantial behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured into short, purposeful paragraphs, each carrying a distinct decision or rule: purpose, exclusion, template wiring, and the code prerequisite. The most important scoping statement is front-loaded, and every sentence earns its place; nothing is redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity — multiple trigger types, template wiring, and the need to reference an external skill guide — the description covers the critical decisions needed to call the tool correctly. The input schema provides the detailed trigger shapes, and the description supplies the inter-field relationships and mandatory prerequisites that the schema cannot express. No return-value explanation is needed for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining template_id behavior, the dependency between template_id and workspace.inputs, and the required get_skill_guide call before writing trigger code. It doesn't deeply expand every parameter, but it meaningfully supplements the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Create a background agent that runs automatically based on triggers.' The opening sentence conveys exactly what the tool produces, and the second paragraph explicitly distinguishes it from add_trigger, so an agent can tell it apart from the most relevant sibling without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-not-to-use guidance: 'Do NOT create a new agent for follow-ups, event handlers, or scheduled checks that continue an existing agent's work — use add_trigger on that agent instead.' It also provides template-selection rules, when to omit template_id, and when workspace.inputs must be seeded. This is direct, actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Sliq toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources