Skip to main content
Glama
Sign In

OTP

by io.github.david-steel
OverviewDiscussionsAdmin

Create a to-do

add_todo

Create a to-do (typically a 7-day commitment from a Delta Meeting). Put it on the person who will do it: pass their name as owner_name and OTP finds them (or owner_external_id from list_people). Never write a person's name into the title, e.g. "[Owen Cartier] ..."; the owner is a field, and a to-do filed under the wrong person lands on the wrong person's list. To share one to-do between several people, pass also_assign. Pass repeat to make it a repeating to-do: daily, weekly, monthly, yearly or a custom cadence, advancing when each copy is done or on a fixed schedule, with an optional end. The response's todo is the first copy.

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": "add_todo"
  }
}

Input Schema

NameRequiredDescriptionDefault
teamNoThe team it belongs to, by name or id (list_people lists teams). Defaults to the meeting's team when meeting_id is given. A to-do with a team shows on that team's view.
titleYesWhat needs to happen. No owner name in brackets.
due_atNoISO 8601 datetime; defaults to 7 days from now if omitted
repeatNoMake this a repeating to-do. Omit for a one-off.
meeting_idNoMeeting in which this to-do was created
owner_nameNoWho owns it, by name ("Owen Cartier", or a first name only one person has). Enough on its own.
also_assignNoMore people who share this one to-do, by name. Each ticks off their own part.
descriptionNo
owner_entity_typeNoWorked out from the owner; only needed with an id OTP does not know.
owner_external_idNoThe owner's id from list_people. Only needed when two people share a name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare this is a non-destructive write operation, but the description adds meaningful behavioral context: owner resolution by name, the risk of filing under the wrong person, sharing semantics, and that a repeating to-do's response todo is the first copy. It does not cover permissions or failure modes, but it adds substantial value beyond annotations.

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 front-loaded with the core action and key assignment pitfall, and each paragraph maps to a distinct concern (owner, sharing, repeat, response). It is slightly verbose in the title-warning sentence but remains well structured and mostly efficient.

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 10-parameter tool with a nested repeat object and no output schema, the description covers the most important behavioral points: owner assignment, title pitfalls, sharing, repeat behavior, and the first-copy return. Some parameters (team, meeting_id, due_at, description) are left entirely to the schema, but the schema coverage is high enough that this is a minor gap.

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 90%, so the schema already documents nearly every parameter including the nested repeat object. The description reinforces owner_name/owner_external_id, also_assign, and repeat at a high level, but it mostly restates what the schema provides rather than adding new semantic detail.

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?

The description uses a clear verb+resource ('Create a to-do') and adds useful scope ('typically a 7-day commitment from a Delta Meeting'). It does not explicitly differentiate itself from siblings like add_issue or add_rock, so it stops short of a 5.

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

Usage Guidelines3/5

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

It gives practical guidance for assigning an owner, sharing via also_assign, and making the to-do repeat. However, it never states when to use add_todo instead of alternatives such as add_issue or add_rock, so usage is implied rather than comparative.

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

All OTP toolsInspect
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