Skip to main content
Glama

twining_record

Record session activity, decisions, and discoveries for future agents. Captures choices with rationale and creates blackboard entries; scope auto-inferred from git diff.

Instructions

Record what you did, any choices you made, and anything you discovered. Call before committing or ending a session. The summary becomes a status post. Decisions become tracked records with rationale. Findings become blackboard entries visible to future agents. Scope is auto-inferred from git diff if omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoArea of codebase affected. Auto-inferred from git diff if omitted.
summaryYesWhat you did this session — one or two sentences. Kept to 200 characters — longer text is truncated with the full text preserved in the entry detail. Lead with the most important information: similarity search weighs the opening of the text most heavily.
agent_idNoAgent identifier (default: main)
findingsNoDiscoveries, warnings, needs, and surprises — anything the next session would want to know that is not visible from the diff: odd patterns you noticed, fragile spots, dead ends you ruled out, things that did not work as expected. Prefix with "warning:" or "need:" for severity. E.g. ["Auth tokens stored in localStorage — fails SOC2", "warning: No token rotation exists", "need: Add rate limiting before launch"]. A substantial change with zero findings is usually under-recording, not a clean run. Lead each finding with the most important information — the first ~200 characters carry the most weight in similarity search.
decisionsNoChoices you made. Each item is either a natural-language sentence ("Chose X over Y — reason") or a structured object ({ summary, rationale, alternatives: [{ option, reason_rejected }] }) when the content is too long or too structured for the NL parser to split cleanly.
depends_onNoIDs of prior decisions that your decisions depend on (from twining_assemble or twining_why output)
reversibleNoWhether your decisions are easily reversible (default: true)
supersedesNoID of a prior decision that your work replaces or invalidates
assumptionsNoConditions your decisions depend on. E.g. ["Data is relational", "No strict ordering required"]
commit_hashNoGit commit hash to associate with these decisions
constraintsNoWhat limited your options. E.g. ["Must support Node 18+", "Cannot add new dependencies"]
affected_filesNoFile paths you changed or that are affected by your decisions
affected_symbolsNoFunction/class/method names affected by your decisions
Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It discloses useful behaviors: scope auto-inference from git diff, summary truncation at 200 characters, similarity search weighting on openings, and a warning about twining_housekeeping with promote_provisionals. It does not cover potential pitfalls like idempotency or concurrency, but the coverage is strong.

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 a single paragraph that efficiently conveys purpose, timing, and key behaviors. It is front-loaded with the core action. While it could be more structured (e.g., using bullet points), it is not verbose and every sentence adds 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 the complexity of 13 parameters (only 1 required) and no output schema, the description provides a solid overview. It covers auto-inference, truncation, similarity search, and housekeeping warnings. It lacks details on error handling or return values, but the description is sufficient for an AI agent to understand the tool's main purpose and usage.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the 'summary' truncation and search weighting, the 'findings' prefix conventions, and the structured decision object usage. This goes beyond the schema's own descriptions, justifying a 4.

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's purpose: 'Record what you did, any choices you made, and anything you discovered.' It also specifies when to call it ('before committing or ending a session'), effectively distinguishing it from sibling tools like twining_post or twining_status, which have different responsibilities.

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 gives explicit timing guidance ('Call before committing or ending a session') and explains the outcomes (status post, tracked decisions, blackboard entries). While it doesn't explicitly state when not to use the tool or compare to siblings, the context is clear and provides actionable instructions.

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/daveangulo/twining-mcp'

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