Skip to main content
Glama

log_agent_run

Log completed agent runs to a database for audit and dashboard tracking, with optional session result events for pipeline integration.

Instructions

Log a completed agent run to the database for audit and dashboard tracking.

Records that an agent did a piece of work so it appears in the dashboard's
Agents view and in get_agent_runs. Call it after writing an output file, per
the output contract. When a session_id is supplied it also writes a "result"
event to session_events, closing the loop for /metis pipeline calls.

Args:
    agent_slug: Slug of the agent that performed the work (e.g. "librarian").
    task_summary: Brief description of what the agent did.
    input_path: Path to the input file(s), if any (default empty string).
    output_path: Path to the output file(s) produced, if any (default empty).
    complexity: The run status stored in the `status` column — typically
        "completed", "partial", or "failed" (default "standard").
    input_tokens: Input tokens consumed, for cost tracking (default 0).
    output_tokens: Output tokens produced, for cost tracking (default 0).
    model: Model identifier used, e.g. "claude-sonnet-4-6" (default empty).
    session_id: Pipeline session ID from session_bootstrap(); when set, also
        records a result event in session_events (default empty string).

Returns:
    A confirmation message naming the agent and task that were logged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_slugYes
task_summaryYes
input_pathNo
output_pathNo
complexityNostandard
input_tokensNo
output_tokensNo
modelNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries full burden. It explains side effects (writing to database and optionally to session_events), the meaning of complexity parameter (stored in status column), and return value. It could mention idempotency or potential failures, but it's already transparent.

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?

The description is well-structured with a clear purpose sentence, usage note, and a parameter list. It's slightly lengthy due to the parameter documentation, but that is necessary given no schema descriptions. Front-loaded with key information.

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?

Given 9 parameters, 2 required, and an output schema, the description covers all parameters, side effects, and return value. It includes example values (e.g., 'librarian'). However, it lacks error handling details or constraints (e.g., uniqueness of agent_slug).

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 coverage is 0%, but the description provides a detailed parameter documentation block explaining each parameter's purpose, default values, and typical use (e.g., complexity values like 'completed'). This adds significant value beyond the schema's names and types.

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?

The description clearly states it logs agent runs for audit and dashboard tracking. It specifies when to call (after writing output file) and the conditional behavior with session_id. While it doesn't explicitly contrast with sibling tools like save_session_event, the unique purpose for agent runs is 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 description provides a clear 'when' to call ('after writing an output file, per the output contract') and mentions the session_id scenario for pipeline calls. However, it lacks 'when-not' guidance or alternatives (e.g., when to use save_session_event instead), which would be helpful given the large sibling set.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SVerITG/Metis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server