Skip to main content
Glama
Sign In

Maplith

by com.maplith
OverviewDiscussionsAdmin

Draft a playbook

draft_playbook

Record optional person-stated time, or draft a playbook for a workspace admin to approve on Rules & know-how › Playbooks; nothing is in use until then, and you cannot approve, edit or delete it. part steps: write the steps of a playbook Maplith wrote without them, from helpdesk conversations you read or steps your human states; get_task_context names the playbook_id where its note says the steps are not written yet. Never write message text, names or values: a draft with a value Maplith recognises is turned away. part time: ask once and record only a person’s stated manual minutes or skip, using their person-bound OAuth connection; a key not linked to a person (one you were handed, not your human's OAuth sign-in) saves and reads nothing, so skip the question there. Read status first and never estimate. part whole: a new playbook for a signal kind nothing handles yet, drawn from the signals you name, instead of handing each one to a person; refused for a kind that is covered or has a draft waiting, and then plan the signal with take_signal (plan: true, due in 7 days). A rejected or deleted whole proposal holds its workspace and kind for 90 days. A draft and its licence allow nothing until approval. Needs: a key that acts and sees the whole map; the whole part only in Maplith's own workspace.

Input Schema

NameRequiredDescriptionDefault
partYestime: optional person-stated manual time for a playbook (playbook_id, time_mode). steps: the steps of a playbook Maplith wrote without them (playbook_id, steps, handoff, completion?). whole: a new playbook for a signal kind nothing handles (signal_kind, title, purpose, problem, value, trigger, steps, completion, exceptions?, licence?, signal_ids).
stepsNoBoth parts: the steps, in order, one plain sentence each.
titleNowhole: a title in plain words.
valueNowhole: the expected benefit supported by the evidence; never invent savings.
handoffNosteps: when a person takes over.
licenceNowhole: [{signal_kind, operations: ['hq.<op>'], max_per_day, close}], the operations it may take per day and whether it may close the signal.
problemNowhole: the recurring problem it removes.
purposeNowhole: exactly what it does.
triggerNowhole: when it applies.
time_modeNotime: status first; ask claims the one question. answer or skip records the person’s explicit response.
completionNoHow anyone can tell it is done (required for whole).
exceptionsNowhole: when not to follow it.
signal_idsNowhole: the signals it was drawn from.
time_basisNoperson_stated: the person explicitly gave these minutes or chose to skip; never an estimate.
playbook_idNosteps or time: the playbook, as get_task_context names it, or the id after playbook: in a search result.
signal_kindNowhole: the kind, as list_signals names it.
manual_minutesNotime answer: only the person’s stated minutes, at most two decimal places.
time_statement_idNotime: latest statement token from status; null before the first answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / playbook_id / description
      Previous value: -"steps or time: the playbook, as get_task_context names it."New value: +"steps or time: the playbook, as get_task_context names it, or the id after playbook: in a search result."
  2. Changed7 schema fields changed
    • addedInput schema / properties / manual_minutes
      Added value: +{
+  "description": "time answer: only the person’s stated minutes, at most two decimal places.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}
    • changedInput schema / properties / part / description
      Previous value: -"steps: the steps of a playbook Maplith wrote without them (playbook_id, steps, handoff, completion?). whole: a new playbook for a signal kind nothing handles (signal_kind, title, purpose, problem, value, trigger, steps, completion, exceptions?, licence?, signal_ids)."New value: +"time: optional person-stated manual time for a playbook (playbook_id, time_mode). steps: the steps of a playbook Maplith wrote without them (playbook_id, steps, handoff, completion?). whole: a new playbook for a signal kind nothing handles (signal_kind, title, purpose, problem, value, trigger, steps, completion, exceptions?, licence?, signal_ids)."
    • changedInput schema / properties / part / enum
      Previous value: -[
-  "whole",
-  "steps"
-]New value: +[
+  "whole",
+  "steps",
+  "time"
+]
    • changedInput schema / properties / playbook_id / description
      Previous value: -"steps: the playbook, as get_task_context names it."New value: +"steps or time: the playbook, as get_task_context names it."
    • addedInput schema / properties / time_basis
      Added value: +{
+  "description": "person_stated: the person explicitly gave these minutes or chose to skip; never an estimate.",
+  "enum": [
+    "person_stated"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / time_mode
      Added value: +{
+  "description": "time: status first; ask claims the one question. answer or skip records the person’s explicit response.",
+  "enum": [
+    "status",
+    "ask",
+    "answer",
+    "skip"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / time_statement_id
      Added value: +{
+  "description": "time: latest statement token from status; null before the first answer.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the approval gate and that drafts are inert ('A draft and its licence allow nothing until approval'), a 90-day hold on the workspace and kind after rejection/deletion, value-validation rejection ('turned away'), and auth requirements ('a key that acts and sees the whole map'). These are substantive consequences not implied by readOnlyHint/destructiveHint/idempotentHint, so this exceeds the bar annotations set.

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?

The 'part steps / part time / part whole' labels impose useful structure and the sentences are information-dense rather than padded. However, the prose is telegraphic and the opening sentence bundles scope, venue, approval state and a restriction together, forcing a re-read; some of that belongs after the mode breakdown.

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 an 18-parameter, three-mode mutation tool with no output schema, the description covers the approval lifecycle, the prerequisites, the per-mode data sourcing, and the fallback tool. The remaining gap is what the call returns (a draft identifier?), which an agent needs in order to follow up, and there is no output schema to fill that in.

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 still adds real meaning, notably that manual_minutes must be a person's explicit statement and never an estimate, that playbook_id can come from get_task_context or from a search result's playbook: token, and that time_statement_id is the latest status token. It does not resolve every parameter pair for the 'whole' part, which keeps it from 5.

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 names the concrete verb/resource and splits it into three named sub-operations ('part time', 'part steps', 'part whole'), each with its own object (person-stated minutes, a written playbook's steps, a brand-new playbook). It also frames the outcome ('draft a playbook for a workspace admin to approve ... nothing is in use until then'), so an agent knows this is a proposal-creation tool, not a publish tool. It stops short of 5 because the opening sentence is so compressed that the core purpose is hard to extract on a first read.

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 gives explicit when-to-use rules per mode ('status first and never estimate', get_task_context names the playbook_id where steps are not written yet) and explicit exclusions ('refused for a kind that is covered or has a draft waiting, and then plan the signal with take_signal (plan: true, due in 7 days)'). It also names the skip condition for the time question when the key is not linked to a person, which is exactly the kind of routing guidance an agent needs before calling.

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

All Maplith 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