Jetpost is the user's inbox of notes. Whenever you make a note, your FIRST action is create_note with components: the component names you'll use, in reading order, repeats included, plus a short title. Send it immediately: before whoami, list_members, get_ui_spec, research or drafting, and with no content. The reader sees the draft with loading placeholders the moment it lands, and it returns note.id and ui_spec, the Markdown syntax for those components. Call create_note once per note. Then write it with add_components(id, markdown): the top of the note (what the reader needs first) in the first call so it appears within seconds, the rest in one more call with complete: true. A short note is a single call with complete: true. Always send complete: true on the last write; it clears the placeholders. Then stop, or share it with share_note. A component note has no separate text: change it with patch_component, never edit_note or append_to_note. Its top is Text/RichText blocks and its collapsible sections are Accordion blocks. Pass recipient_ids from list_members for the people who should see it in their inbox, or emails for someone who isn't on that list yet. Never guess an address. Omit recipients, or pass an empty list, when the note is personal and only the author should see it. A note is one document: a title and one body, written in markdown. get_note returns all of it. Write the note for two readers. A person reads it top to bottom and stops once they have what they need. An agent reads all of it, later, to pick up where this left off. Serve both by ordering things by who needs them, not by cutting. The top of the note is for the person. Someone who reads only that part should know what this is about, what was found or decided, and what they need to do, if anything, and by when. Lead with the point, then just enough of the why to trust it. No preamble, no restating the request, no "this note covers", and don't repeat the title as a heading. It should take under a
Discoverability
0 of 6 checks0/100
Client listings and public setup information.
mcp.json on main domain
No matching manifest was found at /mcp.json or /.well-known/mcp.json.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description82/100
The user's Jetpost account and the workspaces this connection can use, with their slugs, the user's role, and has_unread when a workspace has notes the user hasn't read (the app's switcher dot). lock is set when this connection is set to one workspace.
The description explains the capability, when to use it, and what to expect.
Inputs100/100
This tool declares no inputs, so argument descriptions are not needed.
No input fields.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "whoami",
"title": "Who am I",
"description": "The user's Jetpost account and the workspaces this connection can use, with their slugs, the user's role, and has_unread when a workspace has notes the user hasn't read (the app's switcher dot). lock is set when this connection is set to one workspace.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {}
},
"annotations": {
"title": "Who am I",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description90/100
Read or change the user's notification settings, as in the app's Settings › Notifications. note_emails: notes sent to them, and new messages in their chats, also come by email. message_sound: a quiet chime when someone writes in a note's chat while Jetpost is open in the background. With nothing passed it reads them; pass a field only when the user asks to change it. Open tabs pick up a change within about 30 seconds.
Describe the returned information so the agent knows whether it will answer the request.
Inputs88/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
note_emails
Turn note emails on or off.
Clear enough to supply this argument.
message_sound
Turn the chime for new messages on or off.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "notification_settings",
"title": "Notification settings",
"description": "Read or change the user's notification settings, as in the app's Settings › Notifications. note_emails: notes sent to them, and new messages in their chats, also come by email. message_sound: a quiet chime when someone writes in a note's chat while Jetpost is open in the background. With nothing passed it reads them; pass a field only when the user asks to change it. Open tabs pick up a change within about 30 seconds.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"note_emails": {
"type": "boolean",
"description": "Turn note emails on or off."
},
"message_sound": {
"type": "boolean",
"description": "Turn the chime for new messages on or off."
}
}
},
"annotations": {
"title": "Notification settings",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description88/100
Read or set where Jetpost wakes an agent when someone replies to one of its messages, as in the app's Settings › Agents. It's you (this connection) unless you pass agent. Jetpost POSTs the note's link and the message id, never what anyone wrote; the woken agent reads it with get_note (since "last_seen") and answers with add_comment reply_to. Pass url to set it: the kind comes from the URL (a Claude routine's API trigger /fire URL on api.anthropic.com, a Grok Bot routine's Webhook trigger on api2.cursor.sh, or any other HTTPS URL, which Jetpost signs the Standard Webhooks way and gives you the signing secret for once). Routines need token. With nothing passed it reads the settings: yours and each of the user's agents (when each last posted in a note, and how waking it is going). Pass test: true to send a test (the agent is asked to check in), remove: true to stop. When a Jetpost test asks you to check in, pass confirm with its code: the wake then follows you, the connection you post through. Tokens are kept sealed and never shown again.
Describe the returned information so the agent knows whether it will answer the request.
Inputs82/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
url
The URL to POST to. Saves it (and turns it back on).
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
token
A routine's trigger token or key. Kept when you change only the URL.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
kind
Only to override what the URL says it is.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
test
Send a test now (after saving, with url) and report what came back.
Clear enough to supply this argument.
remove
Stop waking the agent.
Clear enough to supply this argument.
confirm
The code from a Jetpost test: check in, so replies to your messages wake you.
Clear enough to supply this argument.
agent
Another of the user's agents, by id from agents, to read or change instead of you.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "wake_settings",
"title": "Wake settings",
"description": "Read or set where Jetpost wakes an agent when someone replies to one of its messages, as in the app's Settings › Agents. It's you (this connection) unless you pass agent. Jetpost POSTs the note's link and the message id, never what anyone wrote; the woken agent reads it with get_note (since \"last_seen\") and answers with add_comment reply_to. Pass url to set it: the kind comes from the URL (a Claude routine's API trigger /fire URL on api.anthropic.com, a Grok Bot routine's Webhook trigger on api2.cursor.sh, or any other HTTPS URL, which Jetpost signs the Standard Webhooks way and gives you the signing secret for once). Routines need token. With nothing passed it reads the settings: yours and each of the user's agents (when each last posted in a note, and how waking it is going). Pass test: true to send a test (the agent is asked to check in), remove: true to stop. When a Jetpost test asks you to check in, pass confirm with its code: the wake then follows you, the connection you post through. Tokens are kept sealed and never shown again.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"url": {
"type": "string",
"maxLength": 2000,
"description": "The URL to POST to. Saves it (and turns it back on)."
},
"kind": {
"enum": [
"claude_routine",
"grok_bot",
"webhook"
],
"type": "string",
"description": "Only to override what the URL says it is."
},
"test": {
"type": "boolean",
"description": "Send a test now (after saving, with url) and report what came back."
},
"agent": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
"description": "Another of the user's agents, by id from agents, to read or change instead of you."
},
"token": {
"type": "string",
"maxLength": 2000,
"description": "A routine's trigger token or key. Kept when you change only the URL."
},
"remove": {
"type": "boolean",
"description": "Stop waking the agent."
},
"confirm": {
"type": "string",
"maxLength": 40,
"description": "The code from a Jetpost test: check in, so replies to your messages wake you."
}
}
},
"annotations": {
"title": "Wake settings",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description86/100
List the people the user can share with in a workspace: the user, everyone in it (inside: true), and people they've shared notes with there. Their ids work as recipient_ids. party is who they count as for sharing outside the workspace: their company's domain, or "personal" for a personal address (each is its own party). ambiguous_name: true means someone else in the list has the same name; it comes with their email so you can ask the user which one. Pass id (a note) to list people for that note's workspace. Share with anyone else by email address.
Describe the returned information so the agent knows whether it will answer the request.
Inputs88/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_members",
"title": "List people",
"description": "List the people the user can share with in a workspace: the user, everyone in it (inside: true), and people they've shared notes with there. Their ids work as recipient_ids. party is who they count as for sharing outside the workspace: their company's domain, or \"personal\" for a personal address (each is its own party). ambiguous_name: true means someone else in the list has the same name; it comes with their email so you can ask the user which one. Pass id (a note) to list people for that note's workspace. Share with anyone else by email address.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "List people",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
Find notes the user can read in one workspace, by words in their title, text or chat, and by who and when. Each result is a pointer: title, author, when it last changed, and up to two snippets showing where it matched, with **matched words** in bold and a link straight to a matching chat message. Read the whole note with get_note. Words match as prefixes and every word must appear; "quoted phrases" match exactly, or matches either side, and -word leaves notes out. Leave query empty to list notes by the filters alone, newest first. Person filters take ids from list_members. Searching the user's personal workspace also finds notes shared with them from workspaces they aren't in. For what changed recently, use list_activity instead.
The description explains the capability, when to use it, and what to expect.
Inputs83/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
query
Words to find, e.g. pricing tiers, "annual plan" or pricing -draft. Empty lists notes by the filters alone.
Clear enough to supply this argument.
author_ids
Only notes written by these people.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
commented_by_ids
Only notes these people wrote in the chat of.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
edited_by_ids
Only notes these people (or their agents) edited.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
shared_with_ids
Only notes shared with all of these people.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
shared_with_me
true: only notes someone else wrote and shared with the user.
Explain what happens when this optional value is omitted.
unread
true: only notes that are new to the user (not opened yet, or marked unread). false: only ones they've opened.
Clear enough to supply this argument.
archived
true: only notes the user archived. false: leave them out. Omit for both.
Clear enough to supply this argument.
updated_after
Only notes changed at or after this date or time.
Explain what happens when this optional value is omitted.
updated_before
Only notes changed before this date or time.
Clear enough to supply this argument.
match_in
Where the words must match: the title, the body (the note's text), or comments (its chat). Default: all three.
Clear enough to supply this argument.
sort
relevance (default when there's a query) or recent.
Clear enough to supply this argument.
limit
How many notes, at most. Default 10.
Clear enough to supply this argument.
cursor
Pass next_cursor from the previous call for the next page.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "search_notes",
"title": "Search notes",
"description": "Find notes the user can read in one workspace, by words in their title, text or chat, and by who and when. Each result is a pointer: title, author, when it last changed, and up to two snippets showing where it matched, with **matched words** in bold and a link straight to a matching chat message. Read the whole note with get_note. Words match as prefixes and every word must appear; \"quoted phrases\" match exactly, or matches either side, and -word leaves notes out. Leave query empty to list notes by the filters alone, newest first. Person filters take ids from list_members. Searching the user's personal workspace also finds notes shared with them from workspaces they aren't in. For what changed recently, use list_activity instead.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"sort": {
"enum": [
"relevance",
"recent"
],
"type": "string",
"description": "relevance (default when there's a query) or recent."
},
"limit": {
"type": "integer",
"maximum": 25,
"minimum": 1,
"description": "How many notes, at most. Default 10."
},
"query": {
"type": "string",
"maxLength": 200,
"description": "Words to find, e.g. pricing tiers, \"annual plan\" or pricing -draft. Empty lists notes by the filters alone."
},
"cursor": {
"type": "string",
"pattern": "^\\d+$",
"description": "Pass next_cursor from the previous call for the next page."
},
"unread": {
"type": "boolean",
"description": "true: only notes that are new to the user (not opened yet, or marked unread). false: only ones they've opened."
},
"archived": {
"type": "boolean",
"description": "true: only notes the user archived. false: leave them out. Omit for both."
},
"match_in": {
"type": "array",
"items": {
"enum": [
"title",
"body",
"comments"
],
"type": "string"
},
"description": "Where the words must match: the title, the body (the note's text), or comments (its chat). Default: all three."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"author_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 20,
"description": "Only notes written by these people."
},
"edited_by_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 20,
"description": "Only notes these people (or their agents) edited."
},
"updated_after": {
"anyOf": [
{
"type": "string",
"format": "date",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
},
{
"type": "string",
"format": "date-time",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
}
],
"description": "Only notes changed at or after this date or time."
},
"shared_with_me": {
"type": "boolean",
"description": "true: only notes someone else wrote and shared with the user."
},
"updated_before": {
"anyOf": [
{
"type": "string",
"format": "date",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
},
{
"type": "string",
"format": "date-time",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
}
],
"description": "Only notes changed before this date or time."
},
"shared_with_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 20,
"description": "Only notes shared with all of these people."
},
"commented_by_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 20,
"description": "Only notes these people wrote in the chat of."
}
}
},
"annotations": {
"title": "Search notes",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
A note's history, newest first: each edit with who made it (a person or their agent), a word diff ([-removed-] {+added+}) and a one-line summary when its agent described it (else null), back to when it was created. Use it when the user asks what changed in a note or who changed it. Pass before (from next_before) for older changes. Pass summarize for one sentence on what the returned edits did together.
The description explains the capability, when to use it, and what to expect.
Inputs88/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
before
Only changes before this. Pass next_before from the previous call.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
summarize
Also return summary: one sentence on what these edits did overall.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_changes",
"title": "A note's history",
"description": "A note's history, newest first: each edit with who made it (a person or their agent), a word diff ([-removed-] {+added+}) and a one-line summary when its agent described it (else null), back to when it was created. Use it when the user asks what changed in a note or who changed it. Pass before (from next_before) for older changes. Pass summarize for one sentence on what the returned edits did together.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"before": {
"type": "string",
"maxLength": 100,
"minLength": 1,
"description": "Only changes before this. Pass next_before from the previous call."
},
"summarize": {
"type": "boolean",
"description": "Also return summary: one sentence on what these edits did overall."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "A note's history",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description99/100
What happened recently across the notes the user can read in one workspace, newest first: edits (with who made them, a word diff, [-removed-] {+added+}, and a one-line summary when its agent described it, else null), new notes, notes shared with the user or opened to the workspace or the link, chat messages (with message_id, and quote when one quotes a passage of the note), thumbs-ups, and requests to open the user's notes (access_requested, with the request's id for share_note's approve_request_ids or decline_request_ids). The user's own activity is included. Use it to answer "what changed since I last looked?" or to decide what's worth raising with the user. Reading it doesn't mark anything seen for the user. Pass since to get only newer events: "last_looked" for everything since the user last had Jetpost open in that workspace (to catch them up), or a time. Pass before (from next_before) for older ones. When checking on a schedule, pass after: the latest_event_id from your last check, so nothing is missed. The result includes last_looked_at, when the user last had Jetpost open in that workspace. Pass notifications: true for only what was addressed to the user by someone else: notes shared with them, messages on their notes (ones they wrote, are on, or wrote in the chat of), replies to their messages, thumbs-ups on them, edits to notes they're on, and pending requests to open their notes, each with unread.
The description explains the capability, when to use it, and what to expect.
Inputs79/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
since
"last_looked" for what’s new since the user last had Jetpost open, or a time, e.g. when you last checked.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
before
Only events before this. Pass next_before from the previous call for the next page.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
after
Only events logged after this one: latest_event_id from your last check.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
limit
How many events, at most. Default 50.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
notifications
true: the user's Notifications in that workspace instead of every event. Reading them doesn't mark them read.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_activity",
"title": "Recent activity",
"description": "What happened recently across the notes the user can read in one workspace, newest first: edits (with who made them, a word diff, [-removed-] {+added+}, and a one-line summary when its agent described it, else null), new notes, notes shared with the user or opened to the workspace or the link, chat messages (with message_id, and quote when one quotes a passage of the note), thumbs-ups, and requests to open the user's notes (access_requested, with the request's id for share_note's approve_request_ids or decline_request_ids). The user's own activity is included. Use it to answer \"what changed since I last looked?\" or to decide what's worth raising with the user. Reading it doesn't mark anything seen for the user. Pass since to get only newer events: \"last_looked\" for everything since the user last had Jetpost open in that workspace (to catch them up), or a time. Pass before (from next_before) for older ones. When checking on a schedule, pass after: the latest_event_id from your last check, so nothing is missed. The result includes last_looked_at, when the user last had Jetpost open in that workspace. Pass notifications: true for only what was addressed to the user by someone else: notes shared with them, messages on their notes (ones they wrote, are on, or wrote in the chat of), replies to their messages, thumbs-ups on them, edits to notes they're on, and pending requests to open their notes, each with unread.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"after": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
"description": "Only events logged after this one: latest_event_id from your last check."
},
"limit": {
"type": "integer",
"maximum": 100,
"minimum": 1,
"description": "How many events, at most. Default 50."
},
"since": {
"anyOf": [
{
"type": "string",
"const": "last_looked"
},
{
"type": "string",
"format": "date-time",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
}
],
"description": "\"last_looked\" for what’s new since the user last had Jetpost open, or a time, e.g. when you last checked."
},
"before": {
"type": "string",
"maxLength": 100,
"minLength": 1,
"description": "Only events before this. Pass next_before from the previous call for the next page."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"notifications": {
"type": "boolean",
"description": "true: the user's Notifications in that workspace instead of every event. Reading them doesn't mark them read."
}
}
},
"annotations": {
"title": "Recent activity",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description96/100
Read one note: its title, workspace, author (and agent, when an agent made it), recipients, and its full text as markdown. comments is the note's chat as people see it: one stream of messages, oldest first, each with an id (pass it to add_comment as reply_to to answer it), a url linking straight to it, its author, reply_to (the id of the message it answers, or null), quote (the passage of the note it's about, or null), applet (on a message about an applet, that applet's src, written while it was expanded), its markdown, and how many thumbs-ups it has. agent is set on messages an agent wrote for its person, and primary says whose thinking it was: the person's ("user") or the agent's own ("agent"). Pass a message's link as id (or its id as message_id) and the result also has message: the message the user opened, which is what they want to work on. For the note's author, access_requests lists people asking to open it (approve or decline with share_note). A note the user can't open answers no_access. Pass since "last_seen" to get only what changed since you last read this note: the new messages (with the ones they reply to), and the body as a word diff or "unchanged". Use it when you're woken by a reply. Reading the note marks it seen for you. With authorship, the result also has authorship: the note's text in order, in spans by who wrote them ("Kyle", "Kyle via Claude", "Kyle's agent", "Kyle with Claude" for an agent's writing that didn't say whose thinking it was, or unknown when nothing recorded it), as the app's "Show who wrote what" shows it.
The description explains the capability, when to use it, and what to expect.
Inputs80/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
message_id
Focus on this chat message: its id, or its link. A message link passed as id does this too.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
authorship
true adds authorship: who wrote which words. Use it when the user asks who wrote what, or what's theirs and what's an agent's.
Clear enough to supply this argument.
since
"last_seen": only what changed since you last read this note.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_note",
"title": "Read a note",
"description": "Read one note: its title, workspace, author (and agent, when an agent made it), recipients, and its full text as markdown. comments is the note's chat as people see it: one stream of messages, oldest first, each with an id (pass it to add_comment as reply_to to answer it), a url linking straight to it, its author, reply_to (the id of the message it answers, or null), quote (the passage of the note it's about, or null), applet (on a message about an applet, that applet's src, written while it was expanded), its markdown, and how many thumbs-ups it has. agent is set on messages an agent wrote for its person, and primary says whose thinking it was: the person's (\"user\") or the agent's own (\"agent\"). Pass a message's link as id (or its id as message_id) and the result also has message: the message the user opened, which is what they want to work on. For the note's author, access_requests lists people asking to open it (approve or decline with share_note). A note the user can't open answers no_access. Pass since \"last_seen\" to get only what changed since you last read this note: the new messages (with the ones they reply to), and the body as a word diff or \"unchanged\". Use it when you're woken by a reply. Reading the note marks it seen for you. With authorship, the result also has authorship: the note's text in order, in spans by who wrote them (\"Kyle\", \"Kyle via Claude\", \"Kyle's agent\", \"Kyle with Claude\" for an agent's writing that didn't say whose thinking it was, or unknown when nothing recorded it), as the app's \"Show who wrote what\" shows it.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"since": {
"type": "string",
"const": "last_seen",
"description": "\"last_seen\": only what changed since you last read this note."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"authorship": {
"type": "boolean",
"description": "true adds authorship: who wrote which words. Use it when the user asks who wrote what, or what's theirs and what's an agent's."
},
"message_id": {
"type": "string",
"minLength": 1,
"description": "Focus on this chat message: its id, or its link. A message link passed as id does this too."
}
}
},
"annotations": {
"title": "Read a note",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description93/100
Ask the author of a note the user can't open to let them in. If the note is open to anyone with the link, this opens it for the user right away. Otherwise the author gets an email and can approve it; the note shows up in the user's inbox once they do. Only when the user wants the note.
The description explains the capability, when to use it, and what to expect.
Inputs87/100
Input documentation gives an agent enough context to populate the arguments.
note
The note's link or its short id.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "request_access",
"title": "Ask for access",
"description": "Ask the author of a note the user can't open to let them in. If the note is open to anyone with the link, this opens it for the user right away. Otherwise the author gets an email and can approve it; the note shows up in the user's inbox once they do. Only when the user wants the note.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"note"
],
"properties": {
"note": {
"type": "string",
"maxLength": 2000,
"minLength": 1,
"description": "The note's link or its short id."
}
}
},
"annotations": {
"title": "Ask for access",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Send feedback about Jetpost to the people who build it: bugs, confusing behavior, missing features, ideas. Use it when the user asks you to send feedback, or when you hit a Jetpost problem worth reporting and the user agrees. Write it for a person: what happened, what you expected, and steps if it's a bug. It creates a note with the Jetpost team; their replies come back in that note's chat, and the user can reply by email.
Describe the returned information so the agent knows whether it will answer the request.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
message
The feedback, as markdown, written for a person.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
title
A short title. Without it, the first line of the message is used.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
about
What it's about, like the link of the note the user was working in.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "send_feedback",
"title": "Send feedback",
"description": "Send feedback about Jetpost to the people who build it: bugs, confusing behavior, missing features, ideas. Use it when the user asks you to send feedback, or when you hit a Jetpost problem worth reporting and the user agrees. Write it for a person: what happened, what you expected, and steps if it's a bug. It creates a note with the Jetpost team; their replies come back in that note's chat, and the user can reply by email.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"message"
],
"properties": {
"about": {
"type": "string",
"maxLength": 500,
"minLength": 1,
"description": "What it's about, like the link of the note the user was working in."
},
"title": {
"type": "string",
"maxLength": 120,
"minLength": 1,
"description": "A short title. Without it, the first line of the message is used."
},
"message": {
"type": "string",
"maxLength": 10000,
"minLength": 1,
"description": "The feedback, as markdown, written for a person."
}
}
},
"annotations": {
"title": "Send feedback",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description100/100
Upload an image from the user's computer for a note. Call once per image with its file name. It returns upload_url and headers; send the file with one HTTP PUT from a shell: curl -sS --fail-with-body -X PUT -T <file> '<upload_url>', adding each returned header with -H 'name: value'. The file goes to Jetpost's image storage (Vercel Blob, vercel.com/api/blob). PNG, JPEG, GIF, or WebP up to 20 MB. Then put the returned markdown, with short alt text describing the image, where it belongs in the note's content (create_note, edit_note, append_to_note); if you leave the alt text empty, Jetpost writes one. Only the user can open the image until you place it: then everyone who can read that note can. For an applet, use the returned url in its HTML (<img src>, CSS or JS) instead: everyone who can open the applet sees it. The upload address expires in 15 minutes. Needs a shell; if you can't run commands, ask the user to paste the image into the note instead.
The description explains the capability, when to use it, and what to expect.
Inputs96/100
Input documentation gives an agent enough context to populate the arguments.
filename
The image file's path or name, e.g. ./screenshot.png. Its extension sets the type.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "upload_image",
"title": "Upload an image",
"description": "Upload an image from the user's computer for a note. Call once per image with its file name. It returns upload_url and headers; send the file with one HTTP PUT from a shell: curl -sS --fail-with-body -X PUT -T <file> '<upload_url>', adding each returned header with -H 'name: value'. The file goes to Jetpost's image storage (Vercel Blob, vercel.com/api/blob). PNG, JPEG, GIF, or WebP up to 20 MB. Then put the returned markdown, with short alt text describing the image, where it belongs in the note's content (create_note, edit_note, append_to_note); if you leave the alt text empty, Jetpost writes one. Only the user can open the image until you place it: then everyone who can read that note can. For an applet, use the returned url in its HTML (<img src>, CSS or JS) instead: everyone who can open the applet sees it. The upload address expires in 15 minutes. Needs a shell; if you can't run commands, ask the user to paste the image into the note instead.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"filename"
],
"properties": {
"filename": {
"type": "string",
"minLength": 1,
"description": "The image file's path or name, e.g. ./screenshot.png. Its extension sets the type."
}
}
},
"annotations": {
"title": "Upload an image",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
Save an HTML page you made (a mockup, chart, prototype or report) as an applet: people see and use it live inside a note. It follows the same rules as a claude.ai Artifact, so an Artifact's HTML works here as is: one self-contained page, with or without the <!doctype>/<html> shell. Scripts inline or from cdnjs.cloudflare.com, cdn.jsdelivr.net/npm/, cdn.tailwindcss.com or code.jquery.com (pin exact versions); stylesheets inline or from Google Fonts; media and fonts as data: URIs. For images, upload each with upload_image and use the URL it returns, or the URL of an image already in a note you can read (in <img>, CSS or JS): everyone who can read the note sees them, and nobody else. No fetch or other requests, no other sites in iframes, no popups or new windows, and alert/confirm/print do nothing, so build those into the page. Sound starts only from a click. There is no Artifact runtime: window.claude.use(...) resolves null for every capability, so nothing a viewer does is saved; write pages that work without it. Up to 3 MB. It returns markdown: place it in the note's content (create_note, edit_note, append_to_note) where the applet belongs, usually as the only thing in a collapsible section titled with what the applet is, e.g. :::details / :::detailsSummary / <title> / ::: / :::detailsContent / <the markdown> / ::: / :::. Pick its size, a fixed height in the note: "compact" (240px) for a small, focused idea, or "tall" (600px) when it needs the room. Its height is the same at every width, and its width is the note's text column, from 343px on a phone to about 690px on a laptop, so build for the narrow width first: wrap or stack rather than cut text off, and don't rely on scrolling inside it. The idea has to fit that size; anything bigger belongs in Expanded, where the reader opens the applet over the note and the same page gets the extra room. To update an applet you made, pass replace with its URL: every note it's in shows the change at once, even where it's open, no note edit needed. Only the user can open it until you place it: then everyone who can read that note can.
The description explains the capability, when to use it, and what to expect.
Inputs83/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
html
The full HTML document.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
size
The applet's fixed height in the note: compact (240px) or tall (600px), at every width.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
replace
An applet URL from an earlier add_applet, to overwrite that applet in place.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "add_applet",
"title": "Add an applet",
"description": "Save an HTML page you made (a mockup, chart, prototype or report) as an applet: people see and use it live inside a note. It follows the same rules as a claude.ai Artifact, so an Artifact's HTML works here as is: one self-contained page, with or without the <!doctype>/<html> shell. Scripts inline or from cdnjs.cloudflare.com, cdn.jsdelivr.net/npm/, cdn.tailwindcss.com or code.jquery.com (pin exact versions); stylesheets inline or from Google Fonts; media and fonts as data: URIs. For images, upload each with upload_image and use the URL it returns, or the URL of an image already in a note you can read (in <img>, CSS or JS): everyone who can read the note sees them, and nobody else. No fetch or other requests, no other sites in iframes, no popups or new windows, and alert/confirm/print do nothing, so build those into the page. Sound starts only from a click. There is no Artifact runtime: window.claude.use(...) resolves null for every capability, so nothing a viewer does is saved; write pages that work without it. Up to 3 MB. It returns markdown: place it in the note's content (create_note, edit_note, append_to_note) where the applet belongs, usually as the only thing in a collapsible section titled with what the applet is, e.g. :::details / :::detailsSummary / <title> / ::: / :::detailsContent / <the markdown> / ::: / :::. Pick its size, a fixed height in the note: \"compact\" (240px) for a small, focused idea, or \"tall\" (600px) when it needs the room. Its height is the same at every width, and its width is the note's text column, from 343px on a phone to about 690px on a laptop, so build for the narrow width first: wrap or stack rather than cut text off, and don't rely on scrolling inside it. The idea has to fit that size; anything bigger belongs in Expanded, where the reader opens the applet over the note and the same page gets the extra room. To update an applet you made, pass replace with its URL: every note it's in shows the change at once, even where it's open, no note edit needed. Only the user can open it until you place it: then everyone who can read that note can.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"html",
"size"
],
"properties": {
"html": {
"type": "string",
"minLength": 1,
"description": "The full HTML document."
},
"size": {
"enum": [
"compact",
"tall"
],
"type": "string",
"description": "The applet's fixed height in the note: compact (240px) or tall (600px), at every width."
},
"replace": {
"type": "string",
"description": "An applet URL from an earlier add_applet, to overwrite that applet in place."
}
}
},
"annotations": {
"title": "Add an applet",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description80/100
Read the HTML of an applet in a note (its /api/applets/... URL, as in the note's :::applet line), to see what it shows or to change it with edit_applet. Works for any applet the user can open.
Describe the returned information so the agent knows whether it will answer the request.
Inputs93/100
Input documentation gives an agent enough context to populate the arguments.
url
The applet's URL from the note.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_applet",
"title": "Read an applet",
"description": "Read the HTML of an applet in a note (its /api/applets/... URL, as in the note's :::applet line), to see what it shows or to change it with edit_applet. Works for any applet the user can open.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"url"
],
"properties": {
"url": {
"type": "string",
"minLength": 1,
"description": "The applet's URL from the note."
}
}
},
"annotations": {
"title": "Read an applet",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description93/100
Change part of an applet you made: replaces old_text with new_text in its HTML, and every note it's in shows the change at once. Copy old_text exactly from get_applet; it must match exactly one place. new_text can be empty to delete. For a full rewrite, use add_applet with replace.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs92/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
url
The applet's URL from the note.
Clear enough to supply this argument.
old_text
Exact HTML currently in the applet, copied from get_applet.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
new_text
The replacement HTML. Empty deletes old_text.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "edit_applet",
"title": "Edit an applet",
"description": "Change part of an applet you made: replaces old_text with new_text in its HTML, and every note it's in shows the change at once. Copy old_text exactly from get_applet; it must match exactly one place. new_text can be empty to delete. For a full rewrite, use add_applet with replace.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"url",
"old_text",
"new_text"
],
"properties": {
"url": {
"type": "string",
"minLength": 1,
"description": "The applet's URL from the note."
},
"new_text": {
"type": "string",
"description": "The replacement HTML. Empty deletes old_text."
},
"old_text": {
"type": "string",
"minLength": 1,
"description": "Exact HTML currently in the applet, copied from get_applet."
}
}
},
"annotations": {
"title": "Edit an applet",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description69/100
The Markdown syntax, rules and an example for components create_note's ui_spec didn't cover, or for editing an existing note. Pass names to get just those. For Image and MediaHeader, assetId can be a direct public https image URL (no upload needed), or the full uploaded filename from upload_image's URL, including its extension (e.g. uuid.jpg; upload bytes first). External images load directly from their host, which must allow embedding. For Applet, appletId is the id in add_applet's url (/api/applets/<id>.html); the url works too.
Describe the returned information so the agent knows whether it will answer the request.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
names
Only these components, like ["Card", "Table"].
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_ui_spec",
"title": "Get the component list",
"description": "The Markdown syntax, rules and an example for components create_note's ui_spec didn't cover, or for editing an existing note. Pass names to get just those. For Image and MediaHeader, assetId can be a direct public https image URL (no upload needed), or the full uploaded filename from upload_image's URL, including its extension (e.g. uuid.jpg; upload bytes first). External images load directly from their host, which must allow embedding. For Applet, appletId is the id in add_applet's url (/api/applets/<id>.html); the url works too.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"names": {
"type": "array",
"items": {
"type": "string"
},
"maxItems": 60,
"description": "Only these components, like [\"Card\", \"Table\"]."
}
}
},
"annotations": {
"title": "Get the component list",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description81/100
A components note's outline: one line per component, indented under its parent. Pass components to get their current Markdown properties and child/slot IDs before replacing their properties with patch_component(markdown).
Describe the returned information so the agent knows whether it will answer the request.
Inputs83/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
components
Component ids to return in full.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_note_components",
"title": "Read a components note",
"description": "A components note's outline: one line per component, indented under its parent. Pass components to get their current Markdown properties and child/slot IDs before replacing their properties with patch_component(markdown).",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"components": {
"type": "array",
"items": {
"type": "string"
},
"maxItems": 50,
"description": "Component ids to return in full."
}
}
},
"annotations": {
"title": "Read a components note",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description87/100
Write a note's components as Markdown (ui_spec from create_note, or get_ui_spec, has the syntax). Readers watch each call land in place of the loading placeholders. Each call adds its top-level blocks to the end of the note in order, or under parent (and slot, for Tabs) and after a sibling. Set complete: true on your last call; id and complete: true alone also finishes. On a note that has text, the text is a Markdown block (id "text") inside the page Stack (id "page"); add yours before or after it, and change the text itself with edit_note. If any block is invalid nothing is added and the error says which line and why: fix that and send the call again.
The description explains the capability, when to use it, and what to expect.
Inputs89/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
markdown
Component Markdown: :::Type blocks, children nested inside their containers. Add #id only to a block you'll change or place things under later.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
title
Sets the note's title, when create_note didn't have a good one.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
parent
The container these go in. Omit for the end of the note.
Clear enough to supply this argument.
slot
With a Tabs parent: which tab.
Clear enough to supply this argument.
after
Put them after this sibling instead of at the end.
Clear enough to supply this argument.
components › items › id
Your id for it, readable and unique in the note, like "flights" or "wed-dinner": letters, digits, - and _.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
components › items › type
A component from get_ui_spec, like Heading, Text, Card, Table, Checkbox.
Clear enough to supply this argument.
components › items › props
Its props, exactly as get_ui_spec lists them.
Clear enough to supply this argument.
components › items › on
Button press or Form submit action, as get_ui_spec describes.
Clear enough to supply this argument.
components › items › parent
The container it goes in (Stack, Card, Section, Grid, Accordion, Tabs…). Omit for the root; the first component on an empty note becomes the root.
Clear enough to supply this argument.
components › items › slot
With a Tabs parent: which tab it goes in.
Clear enough to supply this argument.
components › items › after
Put it after this sibling instead of at the end.
Clear enough to supply this argument.
complete
true on the last write: the note is finished and its leftover placeholders go.
Clear enough to supply this argument.
source
Whose thinking this is: "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Clear enough to supply this argument.
intent
One line on what this edit does, like a commit message ("Added Q3 numbers to pricing"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Add components to a note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "add_components",
"title": "Add components to a note",
"description": "Write a note's components as Markdown (ui_spec from create_note, or get_ui_spec, has the syntax). Readers watch each call land in place of the loading placeholders. Each call adds its top-level blocks to the end of the note in order, or under parent (and slot, for Tabs) and after a sibling. Set complete: true on your last call; id and complete: true alone also finishes. On a note that has text, the text is a Markdown block (id \"text\") inside the page Stack (id \"page\"); add yours before or after it, and change the text itself with edit_note. If any block is invalid nothing is added and the error says which line and why: fix that and send the call again.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id",
"source"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"slot": {
"type": "string",
"description": "With a Tabs parent: which tab."
},
"after": {
"type": "string",
"description": "Put them after this sibling instead of at the end."
},
"title": {
"type": "string",
"maxLength": 500,
"minLength": 1,
"description": "Sets the note's title, when create_note didn't have a good one."
},
"intent": {
"type": "string",
"maxLength": 280,
"minLength": 1,
"description": "One line on what this edit does, like a commit message (\"Added Q3 numbers to pricing\"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one."
},
"parent": {
"type": "string",
"description": "The container these go in. Omit for the end of the note."
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"default": "agent",
"description": "Whose thinking this is: \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"complete": {
"type": "boolean",
"description": "true on the last write: the note is finished and its leftover placeholders go."
},
"markdown": {
"type": "string",
"maxLength": 200000,
"minLength": 1,
"description": "Component Markdown: :::Type blocks, children nested inside their containers. Add #id only to a block you'll change or place things under later."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"components": {
"type": "array",
"items": {
"type": "object",
"required": [
"id",
"type"
],
"properties": {
"id": {
"type": "string",
"maxLength": 64,
"minLength": 1,
"description": "Your id for it, readable and unique in the note, like \"flights\" or \"wed-dinner\": letters, digits, - and _."
},
"on": {
"type": "object",
"description": "Button press or Form submit action, as get_ui_spec describes.",
"propertyNames": {
"type": "string"
},
"additionalProperties": {}
},
"slot": {
"type": "string",
"description": "With a Tabs parent: which tab it goes in."
},
"type": {
"type": "string",
"minLength": 1,
"description": "A component from get_ui_spec, like Heading, Text, Card, Table, Checkbox."
},
"after": {
"type": "string",
"description": "Put it after this sibling instead of at the end."
},
"props": {
"type": "object",
"description": "Its props, exactly as get_ui_spec lists them.",
"propertyNames": {
"type": "string"
},
"additionalProperties": {}
},
"parent": {
"type": "string",
"description": "The container it goes in (Stack, Card, Section, Grid, Accordion, Tabs…). Omit for the root; the first component on an empty note becomes the root."
}
}
},
"maxItems": 20,
"minItems": 1,
"description": "Legacy component JSON. Prefer markdown."
}
}
},
"annotations": {
"title": "Add components to a note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description75/100
Replace one component's properties using a single :::Type Markdown block. Its type must match, and its ID, children and placement stay in place. Read it with get_note_components first. Supply the complete new properties; omitted optional fields reset to defaults. Do not include child components. Legacy props/on patches are also accepted.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs69/100
6 of 8 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
component
The component's id.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
markdown
One complete component block with its replacement properties, without child blocks.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
props
Not provided
Missing description. Explain what this value means and how to supply it.
on
Not provided
Missing description. Explain what this value means and how to supply it.
source
Whose thinking this is: "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Clear enough to supply this argument.
intent
One line on what this edit does, like a commit message ("Added Q3 numbers to pricing"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "patch_component",
"title": "Change a component",
"description": "Replace one component's properties using a single :::Type Markdown block. Its type must match, and its ID, children and placement stay in place. Read it with get_note_components first. Supply the complete new properties; omitted optional fields reset to defaults. Do not include child components. Legacy props/on patches are also accepted.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id",
"component",
"source"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"on": {
"anyOf": [
{
"type": "object",
"propertyNames": {
"type": "string"
},
"additionalProperties": {}
},
{
"type": "null"
}
]
},
"props": {
"type": "object",
"propertyNames": {
"type": "string"
},
"additionalProperties": {}
},
"intent": {
"type": "string",
"maxLength": 280,
"minLength": 1,
"description": "One line on what this edit does, like a commit message (\"Added Q3 numbers to pricing\"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one."
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"default": "agent",
"description": "Whose thinking this is: \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"markdown": {
"type": "string",
"maxLength": 200000,
"minLength": 1,
"description": "One complete component block with its replacement properties, without child blocks."
},
"component": {
"type": "string",
"minLength": 1,
"description": "The component's id."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Change a component",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description69/100
Move a component (and everything inside it) to another parent or position.
Describe the concrete operation and its scope instead of restating the tool name.
Inputs46/100
4 of 7 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
component
Not provided
Missing description. Explain what this value means and how to supply it.
parent
Omit for the root.
Explain the meaning of this value, not just its name.
slot
Not provided
Missing description. Explain what this value means and how to supply it.
after
Not provided
Missing description. Explain what this value means and how to supply it.
source
Whose thinking this is: "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "move_component",
"title": "Move a component",
"description": "Move a component (and everything inside it) to another parent or position.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id",
"component",
"source"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"slot": {
"type": "string"
},
"after": {
"type": "string"
},
"parent": {
"type": "string",
"description": "Omit for the root."
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"default": "agent",
"description": "Whose thinking this is: \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"component": {
"type": "string",
"minLength": 1
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Move a component",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description68/100
Remove a component and everything inside it.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs72/100
3 of 4 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
component
Not provided
Missing description. Explain what this value means and how to supply it.
source
Whose thinking this is: "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "remove_component",
"title": "Remove a component",
"description": "Remove a component and everything inside it.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id",
"component",
"source"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"default": "agent",
"description": "Whose thinking this is: \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"component": {
"type": "string",
"minLength": 1
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Remove a component",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description72/100
Set a value that components read or bind to (a checkbox, a selection, a number), by its JSON Pointer, like /shared/tickets. Everyone sees the change.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs55/100
3 of 5 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
path
Not provided
Missing description. Explain what this value means and how to supply it.
value
Not provided
Missing description. Explain what this value means and how to supply it.
source
Whose thinking this is: "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Set a value in a components note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "set_state",
"title": "Set a value in a components note",
"description": "Set a value that components read or bind to (a checkbox, a selection, a number), by its JSON Pointer, like /shared/tickets. Everyone sees the change.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id",
"path",
"value",
"source"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"path": {
"type": "string",
"minLength": 1
},
"value": {
"type": [
"string",
"number",
"boolean",
"null"
]
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"default": "agent",
"description": "Whose thinking this is: \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Set a value in a components note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description89/100
Making a note: call this FIRST, immediately, with only components (the names you'll use, in reading order, repeats included) and a short title. No content, and nothing else first. It creates a private draft the reader sees right away, with loading placeholders, and returns note.id and ui_spec, the Markdown syntax for those components. Then write it with add_components, complete: true on the last call. Call create_note once per note. For direct creation without a component plan, send a short title and the content, written for a person. Set primary to say whose thinking the content is; prefer writing down your person's own words and thinking over your version of it. Share it with recipient_ids from list_members, or with emails for anyone else. Omit both for a personal note only the author can see. The note is created first, then shared: if sharing needs the user's OK, the result says the note is private for now and sharing.needs_confirmation has the details; if sharing fails, sharing.error says why. Either way, use share_note next, not create_note again.
The description explains the capability, when to use it, and what to expect.
Inputs71/100
10 of 12 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
components
The component names you plan to use, in reading order, repeats included. A rough plan: the note may differ.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
title
A short, specific title. With components it's optional (Untitled until add_components sets one).
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
primary
Whose thinking the content is: "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments. This never changes ownership or permissions. Required for direct creation without a component plan; defaults to agent for a planned draft.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
format
"components" for a note you'll build from Jetpost's components: send no content, then build it with get_ui_spec and add_components. Any note can take components later too. Default "text".
Clear enough to supply this argument.
content
The note body as markdown. A collapsible section, a heading whose content opens on click, is `:::details`, then `:::detailsSummary` with the heading text and `:::`, then `:::detailsContent` with the blocks and `:::`, then `:::`, each on its own line with blank lines between.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
segments › items › text
Not provided
Missing description. Explain what this value means and how to supply it.
segments › items › source
Not provided
Missing description. Explain what this value means and how to supply it.
recipient_ids
User ids from list_members. Empty means only the author can see it.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
emails
Email addresses of people to share with who aren't in the people list yet. Anyone without a Jetpost account gets one waiting for them; set notify so they hear about it.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
access
What the people in recipient_ids can do: comment only (the default) or edit the text. Use edit only when editing access is intended.
Clear enough to supply this argument.
notify
Also email recipients who have note emails enabled and haven't been emailed this note yet. Only when the user says it's ready to send, not while drafting.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "create_note",
"title": "Create a note",
"description": "Making a note: call this FIRST, immediately, with only components (the names you'll use, in reading order, repeats included) and a short title. No content, and nothing else first. It creates a private draft the reader sees right away, with loading placeholders, and returns note.id and ui_spec, the Markdown syntax for those components. Then write it with add_components, complete: true on the last call. Call create_note once per note. For direct creation without a component plan, send a short title and the content, written for a person. Set primary to say whose thinking the content is; prefer writing down your person's own words and thinking over your version of it. Share it with recipient_ids from list_members, or with emails for anyone else. Omit both for a personal note only the author can see. The note is created first, then shared: if sharing needs the user's OK, the result says the note is private for now and sharing.needs_confirmation has the details; if sharing fails, sharing.error says why. Either way, use share_note next, not create_note again.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"title": {
"type": "string",
"maxLength": 500,
"minLength": 1,
"description": "A short, specific title. With components it's optional (Untitled until add_components sets one)."
},
"access": {
"enum": [
"edit",
"comment"
],
"type": "string",
"description": "What the people in recipient_ids can do: comment only (the default) or edit the text. Use edit only when editing access is intended."
},
"emails": {
"type": "array",
"items": {
"type": "string",
"format": "email",
"pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
},
"maxItems": 20,
"description": "Email addresses of people to share with who aren't in the people list yet. Anyone without a Jetpost account gets one waiting for them; set notify so they hear about it."
},
"format": {
"enum": [
"text",
"components"
],
"type": "string",
"description": "\"components\" for a note you'll build from Jetpost's components: send no content, then build it with get_ui_spec and add_components. Any note can take components later too. Default \"text\"."
},
"notify": {
"type": "boolean",
"description": "Also email recipients who have note emails enabled and haven't been emailed this note yet. Only when the user says it's ready to send, not while drafting."
},
"content": {
"type": "string",
"maxLength": 100000,
"description": "The note body as markdown. A collapsible section, a heading whose content opens on click, is `:::details`, then `:::detailsSummary` with the heading text and `:::`, then `:::detailsContent` with the blocks and `:::`, then `:::`, each on its own line with blank lines between."
},
"primary": {
"enum": [
"user",
"agent"
],
"type": "string",
"description": "Whose thinking the content is: \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments. This never changes ownership or permissions. Required for direct creation without a component plan; defaults to agent for a planned draft."
},
"segments": {
"type": "array",
"items": {
"type": "object",
"required": [
"text",
"source"
],
"properties": {
"text": {
"type": "string",
"maxLength": 100000
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string"
}
}
},
"maxItems": 200,
"minItems": 1,
"description": "Only when one write mixes your person's words and yours: the text as pieces in order, each with whose thinking it is, in place of content. They're joined exactly as given (put spaces and line breaks inside the pieces; a piece can end mid-sentence or mid-list), and people see each piece credited."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"components": {
"type": "array",
"items": {
"enum": [
"Heading",
"Text",
"Markdown",
"RichText",
"Link",
"List",
"Quote",
"CodeBlock",
"Divider",
"Badge",
"Stack",
"Prose",
"Section",
"FieldGroup",
"Grid",
"Card",
"Carousel",
"Tabs",
"Accordion",
"Callout",
"Table",
"Chart",
"Metric",
"Progress",
"Steps",
"Timeline",
"Button",
"Input",
"Textarea",
"Select",
"Checkbox",
"RadioGroup",
"Slider",
"DatePicker",
"Toggle",
"Form",
"MediaHeader",
"Image",
"Map",
"Video",
"File",
"Icon",
"Applet",
"Mention",
"NoteLink"
],
"type": "string"
},
"maxItems": 500,
"minItems": 1,
"description": "The component names you plan to use, in reading order, repeats included. A rough plan: the note may differ."
},
"recipient_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 100,
"description": "User ids from list_members. Empty means only the author can see it."
}
}
},
"annotations": {
"title": "Create a note",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description94/100
Tidy the user's own inbox: archive notes or bring them back, and mark them read or unread. Pass archived, read, or both. Only the user's inbox changes: the notes, their chats and everyone else's inbox stay as they are. Marking read never tells the author the user saw it. Archived notes stay searchable (search_notes archived: true). Works on any note the user can read. Every note is checked first, so if one fails, nothing changes. Do this only when the user asks.
The description explains the capability, when to use it, and what to expect.
Inputs81/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
ids
The notes: links, short ids or ids.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
archived
true archives them; false brings them back to the inbox.
Explain what happens when this optional value is omitted.
read
true marks them read (no longer new); false marks them unread. Their messages and notifications are unaffected.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations100/100
All four behavior hints are declared.
{
"title": "Archive or mark notes read",
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "mark_notes",
"title": "Archive or mark notes read",
"description": "Tidy the user's own inbox: archive notes or bring them back, and mark them read or unread. Pass archived, read, or both. Only the user's inbox changes: the notes, their chats and everyone else's inbox stay as they are. Marking read never tells the author the user saw it. Archived notes stay searchable (search_notes archived: true). Works on any note the user can read. Every note is checked first, so if one fails, nothing changes. Do this only when the user asks.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"ids"
],
"properties": {
"ids": {
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"maxItems": 100,
"minItems": 1,
"description": "The notes: links, short ids or ids."
},
"read": {
"type": "boolean",
"description": "true marks them read (no longer new); false marks them unread. Their messages and notifications are unaffected."
},
"archived": {
"type": "boolean",
"description": "true archives them; false brings them back to the inbox."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Archive or mark notes read",
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description96/100
Add people to one of the user's notes, take people off, open it to everyone in its workspace or to anyone with the link, answer requests to open it, email people, or a mix. Only the note's author can share it. recipient_ids are added to the people already on it (from list_members); they see the note in their inbox right away. access sets what those people can do, including people already on it. general_access sets who else can open it: only_people_added, everyone_at_workspace (a team workspace's members) or anyone_with_link (anyone signed in who has the link); general_access_role is what they can do. approve_request_ids and decline_request_ids answer access requests from get_note or list_activity; approving adds the person and emails them the note. With notify, everyone on the note who has note emails enabled and hasn't been emailed it yet gets an email from the user, sent via Jetpost. Use notify alone to email people already on a note once it's ready. Sharing with a second, different outside party, or opening the note wider, needs the user's OK: the result is needs_confirmation with a message to show them. Pass confirm only after they say yes.
Describe the returned information so the agent knows whether it will answer the request.
Inputs98/100
Explain what happens when this optional value is omitted.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
recipient_ids
People to add, from list_members. Anyone already on the note stays.
Clear enough to supply this argument.
emails
Email addresses of people to share with who aren't in the people list yet. Anyone without a Jetpost account gets one waiting for them; set notify so they hear about it.
Clear enough to supply this argument.
remove_ids
People to take off the note, from its recipients.
Clear enough to supply this argument.
access
What the people in recipient_ids can do: comment only (the default) or edit the text. Use edit only when editing access is intended.
Clear enough to supply this argument.
general_access
Who else can open the note, besides the people on it.
Explain what happens when this optional value is omitted.
general_access_role
What people who open it through general_access can do. Default comment.
Clear enough to supply this argument.
approve_request_ids
Access requests to approve, from get_note's access_requests or list_activity, including ones dismissed earlier.
Clear enough to supply this argument.
decline_request_ids
Access requests to decline. Nobody is told.
Clear enough to supply this argument.
notify
Also email recipients who have note emails enabled and haven't been emailed this note yet. Only when the user says it's ready to send, not while drafting.
Clear enough to supply this argument.
confirm
The token from needs_confirmation, only after the user said yes to its message.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "share_note",
"title": "Share a note",
"description": "Add people to one of the user's notes, take people off, open it to everyone in its workspace or to anyone with the link, answer requests to open it, email people, or a mix. Only the note's author can share it. recipient_ids are added to the people already on it (from list_members); they see the note in their inbox right away. access sets what those people can do, including people already on it. general_access sets who else can open it: only_people_added, everyone_at_workspace (a team workspace's members) or anyone_with_link (anyone signed in who has the link); general_access_role is what they can do. approve_request_ids and decline_request_ids answer access requests from get_note or list_activity; approving adds the person and emails them the note. With notify, everyone on the note who has note emails enabled and hasn't been emailed it yet gets an email from the user, sent via Jetpost. Use notify alone to email people already on a note once it's ready. Sharing with a second, different outside party, or opening the note wider, needs the user's OK: the result is needs_confirmation with a message to show them. Pass confirm only after they say yes.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"access": {
"enum": [
"edit",
"comment"
],
"type": "string",
"description": "What the people in recipient_ids can do: comment only (the default) or edit the text. Use edit only when editing access is intended."
},
"emails": {
"type": "array",
"items": {
"type": "string",
"format": "email",
"pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
},
"maxItems": 20,
"description": "Email addresses of people to share with who aren't in the people list yet. Anyone without a Jetpost account gets one waiting for them; set notify so they hear about it."
},
"notify": {
"type": "boolean",
"description": "Also email recipients who have note emails enabled and haven't been emailed this note yet. Only when the user says it's ready to send, not while drafting."
},
"confirm": {
"type": "string",
"maxLength": 100,
"minLength": 1,
"description": "The token from needs_confirmation, only after the user said yes to its message."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
},
"remove_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 100,
"description": "People to take off the note, from its recipients."
},
"recipient_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 100,
"description": "People to add, from list_members. Anyone already on the note stays."
},
"general_access": {
"enum": [
"only_people_added",
"everyone_at_workspace",
"anyone_with_link"
],
"type": "string",
"description": "Who else can open the note, besides the people on it."
},
"approve_request_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 50,
"description": "Access requests to approve, from get_note's access_requests or list_activity, including ones dismissed earlier."
},
"decline_request_ids": {
"type": "array",
"items": {
"type": "string",
"format": "uuid",
"pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
},
"maxItems": 50,
"description": "Access requests to decline. Nobody is told."
},
"general_access_role": {
"enum": [
"comment",
"edit"
],
"type": "string",
"description": "What people who open it through general_access can do. Default comment."
}
}
},
"annotations": {
"title": "Share a note",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description79/100
Add markdown to the end of a note, without touching what's already there. Works on any note the user can edit, not only their own. Set source to say whose thinking it is, or pass segments when it mixes theirs and yours.
The description explains the capability, when to use it, and what to expect.
Inputs54/100
5 of 7 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
markdown
Markdown to add at the end of the note.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
segments › items › text
Not provided
Missing description. Explain what this value means and how to supply it.
segments › items › source
Not provided
Missing description. Explain what this value means and how to supply it.
source
Required with markdown: whose thinking it is. "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
intent
One line on what this edit does, like a commit message ("Added Q3 numbers to pricing"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Add to a note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "append_to_note",
"title": "Add to a note",
"description": "Add markdown to the end of a note, without touching what's already there. Works on any note the user can edit, not only their own. Set source to say whose thinking it is, or pass segments when it mixes theirs and yours.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"intent": {
"type": "string",
"maxLength": 280,
"minLength": 1,
"description": "One line on what this edit does, like a commit message (\"Added Q3 numbers to pricing\"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one."
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"description": "Required with markdown: whose thinking it is. \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"markdown": {
"type": "string",
"minLength": 1,
"description": "Markdown to add at the end of the note."
},
"segments": {
"type": "array",
"items": {
"type": "object",
"required": [
"text",
"source"
],
"properties": {
"text": {
"type": "string",
"maxLength": 100000
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string"
}
}
},
"maxItems": 200,
"minItems": 1,
"description": "Only when one write mixes your person's words and yours: the text as pieces in order, each with whose thinking it is, in place of markdown. They're joined exactly as given (put spaces and line breaks inside the pieces; a piece can end mid-sentence or mid-list), and people see each piece credited."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Add to a note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description90/100
Change part of a note: replaces old_text with new_text. Works on any note the user can edit, not only their own. Copy old_text exactly from the note's current markdown (call get_note first). It must match exactly one place, so include enough surrounding text. new_text can be empty to delete. If the note changed since you read it, you get an error: re-read it and retry. Set source to say whose thinking new_text is, or pass segments when it mixes theirs and yours. The author can also change the title; pass it on its own or with a text change.
The description explains the capability, when to use it, and what to expect.
Inputs69/100
7 of 9 inputs have descriptions. Add descriptions to the missing inputs, including where to obtain IDs and how to supply values.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Clear enough to supply this argument.
old_text
Exact text currently in the note, copied from get_note.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
new_text
The replacement markdown. Empty deletes old_text.
Clear enough to supply this argument.
segments › items › text
Not provided
Missing description. Explain what this value means and how to supply it.
segments › items › source
Not provided
Missing description. Explain what this value means and how to supply it.
title
A new title. Author only.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
source
Required with new_text: whose thinking it is. "user" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is "agent": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use "agent". When one write mixes both, use segments.
Clear enough to supply this argument.
intent
One line on what this edit does, like a commit message ("Added Q3 numbers to pricing"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "edit_note",
"title": "Edit a note",
"description": "Change part of a note: replaces old_text with new_text. Works on any note the user can edit, not only their own. Copy old_text exactly from the note's current markdown (call get_note first). It must match exactly one place, so include enough surrounding text. new_text can be empty to delete. If the note changed since you read it, you get an error: re-read it and retry. Set source to say whose thinking new_text is, or pass segments when it mixes theirs and yours. The author can also change the title; pass it on its own or with a text change.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"title": {
"type": "string",
"maxLength": 500,
"minLength": 1,
"description": "A new title. Author only."
},
"intent": {
"type": "string",
"maxLength": 280,
"minLength": 1,
"description": "One line on what this edit does, like a commit message (\"Added Q3 numbers to pricing\"). When the edit is worth telling people about, their notification shows it. Optional: without it, Jetpost writes one."
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string",
"description": "Required with new_text: whose thinking it is. \"user\" only for what your person said or asked for in this conversation, in their words or tidied. Everything else is \"agent\": framing, headings, structure, conclusions, anything you inferred or took from other notes. People see the difference, so never pass your ideas off as theirs; when unsure, use \"agent\". When one write mixes both, use segments."
},
"new_text": {
"type": "string",
"description": "The replacement markdown. Empty deletes old_text."
},
"old_text": {
"type": "string",
"minLength": 1,
"description": "Exact text currently in the note, copied from get_note."
},
"segments": {
"type": "array",
"items": {
"type": "object",
"required": [
"text",
"source"
],
"properties": {
"text": {
"type": "string",
"maxLength": 100000
},
"source": {
"enum": [
"user",
"agent"
],
"type": "string"
}
}
},
"maxItems": 200,
"minItems": 1,
"description": "Only when one write mixes your person's words and yours: the text as pieces in order, each with whose thinking it is, in place of new_text. They're joined exactly as given (put spaces and line breaks inside the pieces; a piece can end mid-sentence or mid-list), and people see each piece credited."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Edit a note",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description87/100
Post a message in a note's chat as the user, marked as written by you. Set primary to say whose thinking it is: "user" when you're posting what your person said or asked you to say, "agent" when the observations or suggestions are your own (e.g. they asked you to read the note and comment). People see the difference, so be honest about it. A message is about the whole note, about a passage when you pass quote, about an applet in the note when you pass applet, or answers another message when you pass reply_to (its id from get_note, or its link); passing a message link as id does the same. A reply quotes the message it answers. When your point answers a particular message, reply to it. Keep it short: one point per message, a sentence or two, no reports. Anyone who can read the note can write in its chat.
The description explains the capability, when to use it, and what to expect.
Inputs79/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
id
The note: its link, its short id from the link (like xv5muc8b2l), or its id.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
markdown
The message. Bold, italic, code and links are kept. Images from upload_image go at the end, each as its markdown on its own line; chat shows them as pictures.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
reply_to
Answer this message: its id from get_note, or its link.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
quote
The exact passage from the note this message is about. Not with reply_to.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
applet
An applet in the note this message is about: its src (/api/applets/<id>.html) or link. Not with quote or reply_to.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
primary
Whose thinking this is: "user" for your person's words, "agent" for your own.
Clear enough to supply this argument.
workspace
Which workspace: its slug, its name, or "personal". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Write in a note's chat",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "add_comment",
"title": "Write in a note's chat",
"description": "Post a message in a note's chat as the user, marked as written by you. Set primary to say whose thinking it is: \"user\" when you're posting what your person said or asked you to say, \"agent\" when the observations or suggestions are your own (e.g. they asked you to read the note and comment). People see the difference, so be honest about it. A message is about the whole note, about a passage when you pass quote, about an applet in the note when you pass applet, or answers another message when you pass reply_to (its id from get_note, or its link); passing a message link as id does the same. A reply quotes the message it answers. When your point answers a particular message, reply to it. Keep it short: one point per message, a sentence or two, no reports. Anyone who can read the note can write in its chat.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"id",
"markdown",
"primary"
],
"properties": {
"id": {
"type": "string",
"minLength": 1,
"description": "The note: its link, its short id from the link (like xv5muc8b2l), or its id."
},
"quote": {
"type": "string",
"maxLength": 1000,
"minLength": 1,
"description": "The exact passage from the note this message is about. Not with reply_to."
},
"applet": {
"type": "string",
"maxLength": 500,
"minLength": 1,
"description": "An applet in the note this message is about: its src (/api/applets/<id>.html) or link. Not with quote or reply_to."
},
"primary": {
"enum": [
"user",
"agent"
],
"type": "string",
"description": "Whose thinking this is: \"user\" for your person's words, \"agent\" for your own."
},
"markdown": {
"type": "string",
"maxLength": 10000,
"minLength": 1,
"description": "The message. Bold, italic, code and links are kept. Images from upload_image go at the end, each as its markdown on its own line; chat shows them as pictures."
},
"reply_to": {
"type": "string",
"minLength": 1,
"description": "Answer this message: its id from get_note, or its link."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "Which workspace: its slug, its name, or \"personal\". Needed when the user is in more than one, except for create_note, which picks the likeliest from the title when omitted. With a note, the note's own workspace: pass it once the user has said which workspace this conversation is about."
}
}
},
"annotations": {
"title": "Write in a note's chat",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description81/100
Create a team workspace, with the user as its admin. Invite people with invite_to_workspace. Only when the user asks for one.
The description explains the capability, when to use it, and what to expect.
Inputs96/100
Input documentation gives an agent enough context to populate the arguments.
name
The team's name, like "Acme".
Clear enough to supply this argument.
slug
The short name used in links and the workspace argument, like "acme". Made from the name when omitted.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Create a team workspace",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "create_workspace",
"title": "Create a team workspace",
"description": "Create a team workspace, with the user as its admin. Invite people with invite_to_workspace. Only when the user asks for one.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"maxLength": 100,
"minLength": 1,
"description": "The team's name, like \"Acme\"."
},
"slug": {
"type": "string",
"maxLength": 100,
"minLength": 1,
"description": "The short name used in links and the workspace argument, like \"acme\". Made from the name when omitted."
}
}
},
"annotations": {
"title": "Create a team workspace",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "join_workspace",
"title": "Join a workspace",
"description": "Join a team workspace with an invite link (…/join/…) or an email invitation's link (…/invite/…), as the user. Only when the user asks you to.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"link"
],
"properties": {
"link": {
"type": "string",
"maxLength": 2000,
"minLength": 1,
"description": "The invite link or invitation link, or the token or invitation id in it."
}
}
},
"annotations": {
"title": "Join a workspace",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description89/100
Invite people to a team workspace by email; each gets an invitation to accept. Admins only. Joining a team lets people see its members and every note opened to everyone there, never anyone's private notes.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
workspace
The workspace: its slug, its name, or its id.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
emails
Email addresses to invite.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
role
member (the default) or admin.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Invite to a workspace",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "invite_to_workspace",
"title": "Invite to a workspace",
"description": "Invite people to a team workspace by email; each gets an invitation to accept. Admins only. Joining a team lets people see its members and every note opened to everyone there, never anyone's private notes.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"workspace",
"emails"
],
"properties": {
"role": {
"enum": [
"member",
"admin"
],
"type": "string",
"description": "member (the default) or admin."
},
"emails": {
"type": "array",
"items": {
"type": "string",
"format": "email",
"pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
},
"maxItems": 50,
"minItems": 1,
"description": "Email addresses to invite."
},
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "The workspace: its slug, its name, or its id."
}
}
},
"annotations": {
"title": "Invite to a workspace",
"readOnlyHint": false,
"openWorldHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description90/100
A team workspace's invite link, with how many people joined through it and whether it expired: anyone signed in who has it can join. Null when there isn't one. Admins only.
Describe the returned information so the agent knows whether it will answer the request.
Inputs88/100
Input documentation gives an agent enough context to populate the arguments.
workspace
The workspace: its slug, its name, or its id.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_invite_link",
"title": "Get the invite link",
"description": "A team workspace's invite link, with how many people joined through it and whether it expired: anyone signed in who has it can join. Null when there isn't one. Admins only.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"workspace"
],
"properties": {
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "The workspace: its slug, its name, or its id."
}
}
},
"annotations": {
"title": "Get the invite link",
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description87/100
Make a new invite link for a team workspace. The old link, if any, stops working. Admins only.
Describe the returned information so the agent knows whether it will answer the request.
Inputs50/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
workspace
The workspace: its slug, its name, or its id.
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Make a new invite link",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "reset_invite_link",
"title": "Make a new invite link",
"description": "Make a new invite link for a team workspace. The old link, if any, stops working. Admins only.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"workspace"
],
"properties": {
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "The workspace: its slug, its name, or its id."
}
}
},
"annotations": {
"title": "Make a new invite link",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description91/100
Turn off a team workspace's invite link, so nobody new can join through it. Admins only.
Explain mutations, irreversible effects, or prerequisites that matter before calling this tool.
Inputs83/100
Input documentation gives an agent enough context to populate the arguments.
workspace
The workspace: its slug, its name, or its id.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"title": "Turn off the invite link",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "turn_off_invite_link",
"title": "Turn off the invite link",
"description": "Turn off a team workspace's invite link, so nobody new can join through it. Admins only.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"workspace"
],
"properties": {
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "The workspace: its slug, its name, or its id."
}
}
},
"annotations": {
"title": "Turn off the invite link",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description82/100
A workspace's details: the user's role and member count, and for admins its members, pending invitations (with ids), the invite link and former_member_notes (shared notes whose author left).
The description explains the capability, when to use it, and what to expect.
Inputs85/100
Input documentation gives an agent enough context to populate the arguments.
workspace
The workspace: its slug, its name, or its id.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "leave_workspace",
"title": "Leave a workspace",
"description": "Take the user out of a team workspace. They lose its notes, including their own, and need a new invitation to come back.",
"inputSchema": {
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"workspace"
],
"properties": {
"workspace": {
"type": "string",
"maxLength": 200,
"minLength": 1,
"description": "The workspace: its slug, its name, or its id."
}
}
},
"annotations": {
"title": "Leave a workspace",
"readOnlyHint": false,
"openWorldHint": false,
"destructiveHint": true
}
}
Loading score analytics…
Put your MCP to the test
A few tasks worth trying with this server, chosen from its reviewed tools. These have not been run.
01Search notesFind notes the user can read in one workspace, by words in their title, text or chat, and by who and when.
02Get profileThe signed-in user's Jetpost account: id and name.
03Recent activityWhat happened recently across the notes the user can read in one workspace, newest first: edits (with who made them, a word diff, [-removed-] {+added+}, and…
04Who am IThe user's Jetpost account and the workspaces this connection can use, with their slugs, the user's role, and has_unread when a workspace has notes the user…
05A note's historyA note's history, newest first: each edit with who made it (a person or their agent), a word diff ([-removed-] {+added+}) and a one-line summary when its age…
Want to run these tasks against your MCP server with us?
Jetpost setup, tools, quality score, publishing readiness, and alternatives.
How do I add Jetpost to Claude, ChatGPT, or Cursor?
Add Jetpost to Claude, ChatGPT, or Cursor by connecting its remote MCP URL in each client's MCP settings. In Claude, add a custom connector. In ChatGPT, add an MCP app. In Cursor, add an MCP server under Settings. The MCP URL is https://www.jetpost.com/mcp.
Is Jetpost MCP ready for ChatGPT and Claude?
As of October 30, 2026, Jetpost scores 96/100 on Manufact's MCP publishing checklist. The scan meets ChatGPT publishing checks and meets Claude publishing checks. Passing these checks does not guarantee marketplace approval.
How clear is Jetpost's MCP tool documentation?
As of October 30, 2026, Jetpost scores 77/100 in Manufact's review of tool titles, descriptions, input and output schemas, and behavior annotations. The review covers 42 of 42 discovered tools. The quality score measures documentation clarity; runtime behavior and marketplace readiness require separate checks.
What are the best alternatives to Jetpost?
As of October 30, 2026, alternatives to Jetpost in productivity on the Manufact MCP leaderboard include Turkish Airlines, Notion MCP, FidelicAI: Hire AI Agents, Linear, and Checkatrade.
How can Jetpost improve its MCP documentation?
move_component is the lowest-scoring reviewed tool at 64/100. No output schema is declared. Add one for structured results so clients can interpret returned fields. Open its review for feedback and a copyable fix prompt, then rerun the documentation review after updating your tool metadata.
Not your MCP?
Review any public or OAuth MCP server for protocol compatibility, tool documentation, and ChatGPT and Claude publishing readiness. No account required.
Cursor
Grok Bot
Grok
Muse