Skip to main content
Glama

Awareness — Memory, Knowledge & Agent Markets

awareness_run_agent_task

Run a task with a marketplace agent bound to a memory (requires login).

Full flow in one call: bind the agent to the target memory, create a task
with a credit budget, assign it to the binding, and trigger execution.
The agent works against the memory and reports back.

Args:
    agent_slug: Agent slug (or id) from the marketplace catalog.
    memory_id: Target memory the agent should work on (must be yours).
    title: Task title (max 200 chars).
    description: Task details.
    budget_credits: Credit budget held from your balance (default 50).
    api_key: Bearer token for authentication (required).

Returns:
    {"task": {...}, "status": str} with task id, assigned agent, and run
    status, or {"error": str}.

Input Schema

NameRequiredDescriptionDefault
titleYes
api_keyNo
memory_idYes
agent_slugYes
descriptionNo
budget_creditsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a fair job: it discloses authentication requirements (login / api_key Bearer), that credits are held from the user's balance, that execution is triggered asynchronously and the agent 'reports back', and it documents the return envelope. It omits reversibility, expected duration, and idempotency of the run.

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

Conciseness4/5

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

Front-loaded one-line summary followed by the flow, then Args and Returns sections; every sentence contributes. Slight redundancy between the summary line and the flow paragraph, but nothing wasteful.

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

Completeness4/5

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

For a six-parameter, no-annotation, no-output-schema, mutating tool, the description supplies auth requirements, budget semantics, the full operation sequence, and the return shape. It stops short of error handling detail and side effects on failure, but is otherwise complete enough to call correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does: every one of the six parameters is documented with added meaning beyond the schema — agent_slug accepts slug or id, memory_id must be the caller's, title is capped at 200 chars, budget_credits defaults to 50 and is held from the balance, and api_key is the required Bearer token.

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?

States a specific verb and resource ('Run a task with a marketplace agent bound to a memory') and spells out the composite operation: bind, create task with budget, assign, trigger. It clearly describes the action, but never explicitly contrasts itself with sibling paths such as awareness_chat_agent or awareness_hire_agent, so an agent must infer which entry point to pick.

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?

Usage context is implied by the flow description and the '(requires login)' note, plus 'memory must be yours', but there is no explicit when-to-use / when-not-to-use statement and no named alternative among the many awareness_* siblings. Adequate but not routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources