Skip to main content
Glama

log_agent_run

Record completed agent runs to the database for audit and dashboard tracking. Accept task summary, paths, tokens, and session ID to link pipeline results.

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?

No annotations provided, so the description carries full burden. It discloses that the tool writes to the database for audit/dashboard, can write to session_events, and returns a confirmation message. It does not mention authorization or rate limits, but overall it transparently describes the tool's behavior.

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 one-sentence summary, contextual explanation, and parameter list. It is somewhat verbose due to the parameter docstrings, but it remains clear and front-loaded. Minor reduction in verbosity could improve conciseness.

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, no schema coverage, and an existing output schema, the description explains all parameter semantics, return value, and side effects. It covers prerequisites (session_bootstrap for session_id) and dual behavior. It lacks error handling or edge cases, but for a logging tool, it is fairly complete.

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 provides all parameter semantics. It gives detailed explanations for each of the 9 parameters, including types, defaults, and clarifications (e.g., 'complexity' maps to status column). This adds significant value beyond 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?

The description clearly states the tool logs a completed agent run for audit and dashboard tracking. It specifies the action ('log'), the resource ('agent run'), and the purpose. It distinguishes from siblings like get_agent_runs (retrieval) and session_bootstrap (initialization) by explaining when to call it and the effect on session_events.

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

Usage Guidelines4/5

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

The description explicitly says 'Call it after writing an output file, per the output contract.' It also explains when session_id is supplied, it writes a result event. This provides clear context for use, though it does not explicitly mention when not to use the tool.

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_PH'

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