OrgLines

Log a decision

log_decision

Record a decision in the caller's personal decision journal. Provide a 'title'; optional 'context', 'options' (list), 'decision', 'reasons' and 'review_date' (YYYY-MM-DD). A future review_date auto-schedules a reminder to review the decision on that day. Additive and low-risk. CONFIRMATION: this tool runs immediately when the caller asks for it — it writes only their own record, and they can undo it from this same surface, so the request is taken as the instruction. You get an ordinary result, not a plan_token. Everything destructive, outbound or financial still proposes and waits.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "log_decision"
  }
}

Input Schema

Name	Required	Description	Default
`title`	Yes
`context`	No
`options`	No
`reasons`	No
`decision`	No
`review_date`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: a future review_date auto-schedules a reminder, the write is additive and undoable from the same surface, and the caller gets an ordinary result rather than a plan_token. Annotations only say readOnly=false and destructive=false; the description explains the consequence of each field and the confirmation model.

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

Conciseness3/5

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

Purpose is front-loaded and the field list is efficient. The CONFIRMATION block, however, runs long and leans on internal jargon ('plan_token', 'from this same surface') that costs more words than the policy it conveys.

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 mutation tool with no annotations detailing side effects, no output schema and no schema descriptions, the definition covers invocation, field formats, the reminder side-effect, reversibility and the confirmation stance. Remaining gaps are minor: expected content/length for the free-text fields, and what the 'ordinary result' actually contains.

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

Parameters3/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 carry the load. It enumerates all six fields, notes 'options' is a list and gives the YYYY-MM-DD format plus the reminder side-effect for 'review_date'. It adds no meaning for 'context', 'decision' or 'reasons' beyond their self-evident names, leaving half the parameters without guidance on expected content.

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: 'Record a decision in the caller's personal decision journal.' That clearly separates it from log_habit, log_time, and the read-side siblings like get_decision. It stops short of explicitly naming when to prefer it over e.g. decision_cards_list, but the journal framing is unambiguous.

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?

Gives concrete when-to-use context: call it when the caller asks to record a decision, and it executes immediately rather than proposing. It also draws a boundary against 'destructive, outbound or financial' actions that must wait for confirmation. It does not address sibling selection among the many other log_*/add_* tools.

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

All OrgLines tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?