Skip to main content
Glama
Sign In

DialogBrain

by com.dialogbrain.api
OverviewDiscussionsAdmin

tasks_create

Create a task in this workspace. Leave the assignee empty to put it in the backlog, or name someone to hand it over.

Input Schema

NameRequiredDescriptionDefault
titleYesTask title
due_atNoISO datetime when the task is due, e.g. '2026-03-31T15:00:00Z'. A time without a zone is read as UTC.
tag_idsNoTopics for the task: ids of workspace tags that apply to tasks (ai_tags.list with applies_to='task'). Replaces the current set; [] clears it.
agent_idNoAct as this agent instead of as yourself — the task is recorded as authored by it. Optional.
assigneeNoWho should do this: a workspace member (email, username, or user:<id> as workspace.members lists them), an AI agent (its name), or a contact (display name). Use 'me' for yourself. Call workspace.members to see who can be assigned. Where this listing offers assignee_user_id / assignee_agent_id / assigned_to_contact_id, they name an exact target instead.
due_dateNoDate when task is due (e.g. '2026-03-31'). Use with due_time or alone.
due_timeNoTime when task is due (e.g. '15:00'). Used with due_date.
priorityNoTask priority (default: medium)
thread_idNoRelated thread ID
descriptionNoDetailed description
repeat_unitNoUnit for repeat_every.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
repeat_everyNoMake the task repeat: completing it creates the next occurrence, due this many repeat_unit after the previous deadline. E.g. repeat_every=3, repeat_unit='month' for quarterly.
target_sessionNoOnly for an agent that has no session of its own (agents.update target_session); otherwise the task goes to the agent's session and this is ignored. Name or session_id from workspace.desktops. A value no connected session answers to is stored, but the answer carries a warning listing live sessions.
assignee_user_idNoExact workspace member to assign to
assignee_agent_idNoExact AI agent to assign to
attachment_file_idsNoFile IDs to attach (from files.upload)
assigned_to_contact_idNoExact contact to assign to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / target_session / description
      Previous value: -"Which desktop Claude session should run this, by the name shown in workspace.desktops. Only needed when the assignee is an AI agent that runs on a machine and more than one session is connected — otherwise the task is not dispatched at all, rather than sent to a machine you did not mean."New value: +"Only for an agent that has no session of its own (agents.update target_session); otherwise the task goes to the agent's session and this is ignored. Name or session_id from workspace.desktops. A value no connected session answers to is stored, but the answer carries a warning listing live sessions."
  2. Changed1 schema field changed
    • changedInput schema / properties / assignee / description
      Previous value: -"Who should do this: a workspace member (email or username), an AI agent (its name), or a contact (display name). Use 'me' for yourself. Call workspace.members to see who can be assigned. For an exact target, pass assignee_user_id / assignee_agent_id / assigned_to_contact_id instead."New value: +"Who should do this: a workspace member (email, username, or user:<id> as workspace.members lists them), an AI agent (its name), or a contact (display name). Use 'me' for yourself. Call workspace.members to see who can be assigned. Where this listing offers assignee_user_id / assignee_agent_id / assigned_to_contact_id, they name an exact target instead."
  3. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  4. Added
  5. Removed
  6. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-destructive, non-idempotent write. The description adds the non-obvious placement consequence of an empty assignee (backlog vs assigned), but says nothing about repeat-task behavior, session targeting for agents, warnings on unresolved target_session, or what the call returns.

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?

Two short sentences with zero filler; the core action is front-loaded and the conditional behavior follows immediately. Nothing could be removed without losing information.

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

Completeness3/5

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

For an 18-parameter creation tool with no output schema, the description covers only the assignee/backlog decision and leaves the agent to rely entirely on the schema for recurrence, attachments, agent impersonation, and session targeting. Given the schema's 100% coverage this is defensible, but the description does little to help an agent navigate the tool's real complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so all 18 parameters are already documented, and the baseline of 3 applies. The description does add one piece of meaning beyond the schema — that omitting assignee routes the task to the backlog — but the other 17 parameters (repeat_every/repeat_unit, agent_id, target_session, in_workspace) get no additional explanation here.

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

Purpose4/5

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

"Create a task in this workspace" names a specific verb and resource, so an agent immediately knows this is the creation entry point in the tasks family. It does not differentiate itself from siblings such as tasks_update, tasks_get, or tasks_list, but the verb+resource pairing makes the distinction largely self-evident.

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

Usage Guidelines3/5

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

The second sentence gives actionable conditional guidance for one decision: leave assignee empty for the backlog, or name someone to hand it over. That is usage guidance about a parameter's effect rather than about when to choose this tool over tasks_update or tasks_list, and there is no mention of prerequisites or exclusions.

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

All DialogBrain 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