Skip to main content
Glama

What Matters

by com.blackdogranch

add_item

Add an item immediately, without review. Normally use this ONLY when the user has just asked for it in conversation — they are the human in the loop at that moment, so set initiated: "human". Anything found by scanning on a schedule belongs in put_proposal instead, with ONE exception: something genuinely urgent that cannot wait for review may be added with initiated: "auto" and priority: "high", which immediately notifies the user's phone. That interruption is the point — reserve it for things that truly cannot wait, because routine "urgent" adds teach the user to ignore the one signal that means look now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dueNoYYYY-MM-DD.
noteNoProse context, markdown. A URL belongs in `links`, not here.
linksNoUp to 3 named links — the thread, the document, the ticket. Prefer these over pasting a URL into the note.
titleYesThe thing to do.
sourceNoWho it involves or where it came from — "Dana", "Tuesday's standup".
channelNoWhere it came from, which is what makes an item legible days later. self = the user thought of it themselves, no external trigger. teams = a Teams message or chat. email = an email thread. meeting = raised in or arising from a meeting. other = anywhere else. Describe the ORIGIN, not who added it — an item you add from an email is still email.
flaggedNoTrue marks the task as urgent — needing the user’s attention now. Set it only when the user asked for the flag, or something genuinely cannot wait; it changes no ordering and no due date.
sectionYesWhich list it belongs in. action = something the user owes someone or themselves. waiting = something owed TO them; they are blocked and the next move is not theirs. note = worth knowing, no action attached. Pick waiting over action whenever the ball is in someone else's court — the distinction is the whole point of the two lists.
priorityNo
initiatedYesWho set this add in motion. "human" = the user asked for it in this conversation — whoever is talking to you, not one specific person. "auto" = you are adding it on your own initiative with no direct instruction. Be truthful: "auto" combined with priority "high" interrupts the user's phone.
source_idNoThe stable id of whatever this came from — a Teams message id, an Outlook internetMessageId, a calendar event id. Set it whenever you have one: it is how the app recognises the same thing again, across runs and after rewording.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does well by disclosing the side effect of auto+high (phone notification) and the rationale for reserving it. It does not mention auth, rate limits, or return behavior, but for an add operation, the key behavioral traits are covered.

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 a single focused paragraph, front-loaded with the core action, and every sentence adds essential context. No fluff or repetition.

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 tool with 11 parameters and no output schema, the description nails the most critical behavioral nuances (human vs. auto, review vs. no review). It does not explain return values, but the primary purpose is clear and the schema covers parameter semantics, so it is nearly complete.

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?

The schema covers 91% of parameters, so baseline is 3. The description adds meaning beyond the schema by explaining the strategic use of initiated and priority together (e.g., 'auto' with 'high' triggers a phone interruption), which is not evident from enum values alone.

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 opens with a specific verb and resource: 'Add an item immediately, without review.' It clearly distinguishes this tool from the sibling put_proposal by contrasting immediate addition versus scheduled review, making the purpose unambiguous.

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 explicitly states when to use this tool: 'ONLY when the user has just asked for it in conversation.' It also gives a clear alternative: 'Anything found by scanning on a schedule belongs in put_proposal instead,' plus an exception for urgent cases. This is precise when/when-not guidance.

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

All What Matters toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct resource (items, focus, rules, proposals) with clear action verbs, and the descriptions explicitly delineate when to use add_item vs put_proposal and warn against using manage_focus/manage_rule outside conversation, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (add_item, complete_item, get_document, manage_focus, manage_rule, put_proposal), with verbs conveying the action and nouns the target.

Tool Count5/5

Six tools is well-scoped for this server: core item operations (add, complete, read), auxiliary resource management (focus, rules), and a proposal mechanism. Each tool has a distinct, non-redundant purpose.

Completeness3/5

The surface covers item creation, status changes, and reads, plus focus and rule management, but lacks direct item deletion or content editing; dismissal is mentioned in get_document but no tool performs it, requiring workarounds via proposals.

Resources