Skip to main content
Glama

td_log

Review the full session log to trace parameter changes, inspect failures, and read repair suggestions. Use summary mode to spot slow or refused methods.

Instructions

Your own trail: every bridge call this host has made, and how it went.

Reach for this when something is wrong and you do not know what you did — an operator is missing, a parameter is not what you set, the artist says "it broke after you touched it". td_status shows only the last call and the next one overwrites it; this is the whole session, and it survives TouchDesigner being closed and reopened, so it also answers "what happened yesterday".

Every call that changed the project is listed with what it changed: tx = 0.5 and ty = expr ... under a td_set_params, each step of a td_build, flags with the value they had before, and the first lines of the code a td_exec ran. To put back what was set earlier, read it here with method="par_set", "batch" or "exec" and a large limit, rather than reconstructing it from a render. An old parameter value is the earlier line that set it; the journal does not record one otherwise.

Also reach for it before repeating a call that failed. failures=True gives the refusals alone, each with the text it refused with, and the repair for the most recent one — repeating a call that a scope claim or a missing path already refused will refuse again for the same reason.

summary=True answers a different question: over everything recorded, which methods refuse and which are slow. Use it to notice a pattern you are inside of — the same method failing five times means the approach is wrong, not the call.

Not everything is here, and the gap matters: only calls that reached the bridge are recorded. The offline tools (td_project_read, td_docs, td_search_operators) never dial it and leave no trace, so an empty journal means no live work, not no work.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
methodNo
summaryNo
failuresNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, and the description fully covers behavioral traits: it records only calls that reached the bridge, survives TouchDesigner restarts, lists changes with specific values (tx, ty, flags, code lines), and includes failure text and repair. It explicitly discloses the limitation that offline tools leave no trace, so an empty journal means no live work.

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 lengthy but front-loaded and dense with unique information, organized into paragraphs for purpose, usage, content, failures, summary, and limitations. Every sentence adds operational value, and the length is justified by the tool's complexity.

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 presence of an output schema, the description covers all necessary aspects: what is logged, how to filter, failure/repair info, summary mode, and limitations. An agent can decide when and how to call this tool without needing additional details.

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 coverage is 0%, so the description compensates by explaining failures=True yields refusals with text and repairs, summary=True aggregates refusal/slow patterns, method filters to specific call types with examples (par_set, batch, exec), and limit is mentioned in context (a large limit for replaying). However, limit's precise behavior and default are not fully spelled out.

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 states a specific verb+resource: 'every bridge call this host has made, and how it went.' It explicitly contrasts with td_status, which shows only the last call and overwrites, so an agent can tell them apart.

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?

It provides explicit when-to-use scenarios: 'when something is wrong and you do not know what you did', 'before repeating a call that failed', and for pattern detection via summary=True. It also names the alternative td_status and explains the gap regarding offline tools that leave no trace.

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