Write pages into your notes vault, search them, and publish one as a shareable link.
Scored across 6 tools
Each tool has a clearly distinct role: reading, searching, writing whole pages, editing parts of pages, publishing, and checking account permissions. The descriptions explicitly separate write_page from edit_page and search_pages from read_page, so misselection is unlikely.
All six tools use a consistent snake_case verb_noun pattern: read_page, write_page, edit_page, search_pages, publish_page, get_account. The singular/plural distinction between page and pages is natural and predictable.
Six tools are well-scoped for a page-vault server, covering the essential lifecycle without excessive surface area. Each tool earns its place and there is no obvious redundancy.
The set covers create/update, read, partial edit, search/list, publish/unpublish, and account inspection. The main gap is the absence of any delete or archive operation for pages, which leaves part of the page lifecycle uncovered.
Change part of a page without sending the whole thing back. Append or prepend Markdown, or replace an exact piece of text with find and replace. Read the page first when using find: what you match against is the Markdown read_page returns. The text you match must appear exactly once, so include enough of the surrounding lines to make it unique. The previous version is kept for 14 days and the owner can restore it.
| Name | Required | Description | Default |
|---|---|---|---|
| find | No | Exact text to replace, as it appears in the page's Markdown. Must occur exactly once. | |
| icon | No | Optional. Set the page's icon: one emoji. | |
| cover | No | Optional. Set the page's cover, the banner across its top. One of: brush (one ink brush stroke on paper), blue-hour (blue mountains under a moon), contours (a contour map on paper), flow (dark flowing lines with amber threads), mist (grey ridges in mist), sundown (amber ridges at sunset), garden (a raked sand garden with stones), stars (constellations on a night sky), enso (an ink circle on paper), ridges (white ridgelines on black), doodles (small doodles on paper), doodles-night (the same doodles on black), boxes (white cubes, a few in black and amber), stitch (indigo cloth with white stitching), dawn (a soft gradient, sky blue to peach), dusk (a deep gradient, blue to violet and red). Or "none" for no cover. A picture the owner uploaded is never replaced. | |
| title | No | Optional. Rename the page. | |
| append | No | Markdown to add at the end of the page. | |
| prepend | No | Markdown to add at the start of the page. | |
| project | No | The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project. | |
| replace | No | What to put in its place. An empty string deletes the matched text. | |
| documentId | No | The page to change. | |
| externalId | No | The key the page was filed under, instead of its id. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Where the owner reads it, signed in. |
| icon | No | The emoji beside the title. |
| cover | No | The banner across the top of the page, by name. "uploaded" when it is a picture the owner put there. |
| title | Yes | |
| access | No | Who can open the shareable link: anyone who has it, or only somebody who also has the passcode. |
| created | No | |
| passcode | No | The passcode the link needs, when access is passcode. Give it to the user exactly as written, alongside the link. |
| warnings | No | |
| publicUrl | No | The shareable link, when the page is published. |
| documentId | Yes | |
| isPublished | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-destructive mutation, and the description adds genuinely new context: a 14-day version history and owner-initiated restore. The exact-once matching constraint is also framed behaviorally. It does not state what happens on a failed or ambiguous match (atomicity, whether other fields are still applied), which matters for a mutation with ten optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the core capability and followed by the operational caveats in priority order. No filler, and the read_page dependency is stated before the uniqueness rule that depends on it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The content-editing path is well covered and an output schema handles return values, but the description never mentions the metadata operations (title, icon, cover) or project filing that account for five of the ten parameters. An agent relying on the prose alone would not know it can rename a page or set its icon here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented, making 3 the baseline. The description adds real value for find (uniqueness, Markdown source-of-truth) but says nothing about icon, cover, title, project, or externalId beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (change part of a page) and enumerates the three content modes: append, prepend, and find/replace. The phrase 'without sending the whole thing back' implicitly contrasts it with write_page, but the sibling is never named. It also omits that this tool can set a page's title, icon, and cover, so the stated purpose is narrower than the actual tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to read_page first when using find and explains why: the match target is the Markdown read_page returns. It also gives a concrete usage rule for uniqueness ('include enough of the surrounding lines'), which is the main failure mode. It stops short of saying when to prefer this over write_page, or when to choose append/prepend instead of find/replace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the user's plan allows, how much of it is used, and what this connection is permitted to do. Useful for telling the user why a write was refused.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| site | No | |
| scopes | Yes | |
| documents | Yes | |
| published | Yes | |
| maxDocuments | Yes | |
| maxPublished | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds scope context (it inspects plan/usage/permissions) and a diagnostic purpose, but no auth requirements or refresh/caching behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the diagnostic use case is placed after the content summary. It reads slightly as an output inventory rather than a lead verb, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema, and full annotation coverage, the description only needs to convey intent and scope, which it does. A brief note on how it relates to the page-write siblings would have made it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to carry; the baseline of 4 applies. Nothing in the description misleads about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (account/plan) and enumerates the three things it reports: plan allowances, current usage, and connection permissions. It is clearly about account-level state and thus distinguishable from the page-oriented siblings (read_page, search_pages, etc.), though it never uses a direct verb like 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete trigger for calling it: diagnosing why a write was refused. That is a useful 'when to use' cue, but no explicit when-not-to-use or named alternative is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put a page on the open web and get a link the user can send to someone, or take it back down by passing publish: false. With access: "passcode" the link opens only for somebody who also types the passcode this returns - use it whenever the user wants the page shared but not open to anyone who finds the link. A connected app can only do this for pages it wrote itself; a page the user made in the app has to be published by them. Published pages are not indexed by search engines unless their owner separately allows it in the app, and taking a page down clears that consent rather than remembering it.
| Name | Required | Description | Default |
|---|---|---|---|
| access | No | Optional. "passcode" puts the page on the web behind a six-character passcode, returned in the result, which the user sends along with the link. "anyone" opens it to anyone with the link. Omit to keep the page at the level it has - a page behind a passcode is never opened up unless you send "anyone", and only do that when the user asks. | |
| project | No | The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project. | |
| publish | Yes | True puts it on the web, false takes it down. | |
| documentId | No | The page to publish or unpublish. | |
| externalId | No | The key the page was filed under, if you do not have its id. | |
| newPasscode | No | Optional. True replaces the passcode with a new one, so the old one stops working everywhere. Only for a page behind a passcode. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Where the owner reads it, signed in. |
| icon | No | The emoji beside the title. |
| cover | No | The banner across the top of the page, by name. "uploaded" when it is a picture the owner put there. |
| title | Yes | |
| access | No | Who can open the shareable link: anyone who has it, or only somebody who also has the passcode. |
| created | No | |
| passcode | No | The passcode the link needs, when access is passcode. Give it to the user exactly as written, alongside the link. |
| warnings | No | |
| publicUrl | No | The shareable link, when the page is published. |
| documentId | Yes | |
| isPublished | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that unpublishing clears search-index consent rather than remembering it, that published pages are not indexed unless the owner separately allows it, and that the passcode is returned in the result. These are real behavioral consequences an agent could not infer from destructiveHint/openWorldHint alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action and its inverse are front-loaded in the first sentence, and every sentence carries information. It is a single dense paragraph with long nested clauses and a fairly niche trailing note on indexing, which costs a little readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with an output schema, the description covers the permission constraint, access-mode semantics, the passcode-in-result behavior, and the reversibility/consent implications of unpublishing. An agent has everything needed to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds decision-level meaning the schema lacks: passcode is intended for share-but-not-public scenarios, and access should not be raised to "anyone" unless the user asks. The remaining semantics (externalId, project, newPasscode) are left almost entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus the outcome ("Put a page on the open web and get a link") and covers the inverse operation ("take it back down by passing publish: false"). It is clearly distinguishable from siblings like write_page/edit_page since this is about web exposure and access control, not content mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit decision guidance for the access parameter ("use it whenever the user wants the page shared but not open to anyone who finds the link") and an explicit when-not constraint ("A connected app can only do this for pages it wrote itself"). It also states a guardrail against silent escalation of access levels, covering both when and when-not to act.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page back out of the vault, by the documentId an earlier call returned or by the externalId it was filed under. Returns the page as Markdown, which is what to change and send back when editing it, along with its title and its links.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project. | |
| documentId | No | The page's id. | |
| externalId | No | The key the page was filed under. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Where the owner reads it, signed in. |
| icon | No | The emoji beside the title. |
| text | Yes | The same page as plain text. |
| cover | No | The banner across the top of the page, by name. "uploaded" when it is a picture the owner put there. |
| title | Yes | |
| access | No | Who can open the shareable link: anyone who has it, or only somebody who also has the passcode. |
| project | No | The project the key is filed under, lowercased. |
| markdown | Yes | The page as Markdown. Edit this and send it back, or match against it with edit_page. |
| passcode | No | The passcode the link needs, when access is passcode. Give it to the user exactly as written, alongside the link. |
| createdAt | No | |
| publicUrl | No | The shareable link, when the page is published. |
| updatedAt | No | |
| documentId | Yes | |
| externalId | No | |
| isPublished | Yes | |
| markdownWarnings | No | Parts of the page Markdown cannot carry, which a write would drop. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real context beyond that: the content is returned as Markdown suitable for round-tripping into an edit, plus title and links. It does not discuss pagination or size limits for very large pages, which is the one behavioral detail left open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and scope, then the return shape and its purpose. No restatement of the title and nothing that does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description need not enumerate return fields, and it still summarizes them usefully. It also compensates for the fact that no parameter is marked required by framing lookup as 'by documentId ... or by externalId', implying at least one identifier. The omission of the project parameter's role is the remaining small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds provenance the schema does not: documentId is the value 'an earlier call returned' and externalId is 'the key it was filed under'. That tells an agent where to source each value and that either identifier path is acceptable, which is genuine added meaning. The project parameter is not touched in the description, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read one page back out of the vault') and immediately constrains scope to a single page retrieved by documentId or externalId, which implicitly separates it from search_pages. It also names the downstream action (editing) that routes the agent to edit_page, so the tool is distinguishable from siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says clearly when to reach for it: after an earlier call has produced an id, and when the intent is to inspect-then-edit ('what to change and send back when editing it'). It does not explicitly exclude the alternative case — e.g. 'use search_pages if you do not yet have an id' — so the when-not guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pages already in the vault by words in their title or body. Use this before writing when you are not sure whether a page for this artifact exists. Called with no query it lists the newest pages instead, which is how to see what a vault holds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results at most. Defaults to 10. | |
| query | No | What to look for. Omit to list the newest pages. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: an empty query silently switches to a newest-first listing, which is a mode change an agent must know about. No pagination or result-ordering detail beyond that, but the output schema covers returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the primary action, then the usage trigger, then the degenerate-input behavior. Every sentence carries distinct information with no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile, 100% schema coverage on both parameters, and an output schema handling return values, the description leaves nothing an agent needs unanswered. The one non-obvious behavior (empty query mode) is explicitly called out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the meaning of an omitted query ("lists the newest pages instead, which is how to see what a vault holds") rather than just restating the schema's default. The limit parameter is left to the schema, which documents it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Find pages already in the vault by words in their title or body"), which is clearly a search rather than a fetch or write. It doesn't explicitly name the nearest sibling (read_page) to contrast with, so it falls just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this before writing when you are not sure whether a page for this artifact exists" gives a concrete trigger condition tied to the write_page/edit_page siblings. It also documents the zero-argument mode, though it never explicitly says when to prefer read_page instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a Markdown document into the user's vault as a page, creating it or updating an existing one. This replaces the whole page, so use edit_page instead to change part of one. Returns the page and a link to it. Set externalId to a stable key for this artifact, such as the source file's path in the repository, so that writing it again updates the same page rather than adding a second copy. The previous version is kept for 14 days and the owner can restore it.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | One emoji, shown beside the title in the sidebar and above it on the page. Always choose one that fits the document - a map for a plan, a scale for a decision, a handshake for a handoff, a microscope for research - even when the user did not ask. A new page sent without one gets a guess from its title; an existing page keeps the icon it has. | |
| cover | No | The banner across the top of the page, by name. Choose one that suits the document when you create a page. One of: brush (one ink brush stroke on paper), blue-hour (blue mountains under a moon), contours (a contour map on paper), flow (dark flowing lines with amber threads), mist (grey ridges in mist), sundown (amber ridges at sunset), garden (a raked sand garden with stones), stars (constellations on a night sky), enso (an ink circle on paper), ridges (white ridgelines on black), doodles (small doodles on paper), doodles-night (the same doodles on black), boxes (white cubes, a few in black and amber), stitch (indigo cloth with white stitching), dawn (a soft gradient, sky blue to peach), dusk (a deep gradient, blue to violet and red). Or "none" for no cover. A new page sent without one gets a banner picked from its title; an existing page keeps the cover it has, and a picture the owner uploaded is never replaced. | |
| title | No | Optional. Defaults to a title in the Markdown's frontmatter, else its leading level-one heading. With neither, a new page is called Untitled and an existing page keeps the title it has. | |
| access | No | Optional. "passcode" puts the page on the web behind a six-character passcode, returned in the result, which the user sends along with the link. "anyone" opens it to anyone with the link. Omit to keep the page at the level it has - a page behind a passcode is never opened up unless you send "anyone", and only do that when the user asks. | |
| project | No | The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project. | |
| publish | No | Optional. True also puts the page on the web and returns publicUrl. Omit to leave the page's current visibility alone. A connected app can set this on a page it wrote, not on one the user made in the app. | |
| markdown | Yes | The page body, in Markdown. Headings, lists, tables, task lists, quotes, code blocks, links, images and dividers are kept. Anything else degrades to its own text and is named in warnings. | |
| documentId | No | Optional. Update this exact page, using an id an earlier call returned. Takes precedence over externalId. | |
| externalId | No | A stable key for this artifact, unique within its project. Strongly recommended: without it, writing the same document twice leaves two pages. | |
| newPasscode | No | Optional. True replaces the passcode with a new one, so the old one stops working everywhere. Only for a page behind a passcode. | |
| parentDocument | No | Optional. File a new page underneath this one. Ignored when updating. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Where the owner reads it, signed in. |
| icon | No | The emoji beside the title. |
| cover | No | The banner across the top of the page, by name. "uploaded" when it is a picture the owner put there. |
| title | Yes | |
| access | No | Who can open the shareable link: anyone who has it, or only somebody who also has the passcode. |
| created | No | |
| passcode | No | The passcode the link needs, when access is passcode. Give it to the user exactly as written, alongside the link. |
| warnings | No | |
| publicUrl | No | The shareable link, when the page is published. |
| documentId | Yes | |
| isPublished | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that the whole page is replaced but the prior version is retained for 14 days and restorable, that a passcode is returned in the result, that markdown constructs degrade into warnings, and that a user-uploaded cover is never replaced. However, the replacement semantics sit uncomfortably beside destructiveHint=false; the description mitigates this with the restore window but never explicitly reconciles the two.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then the edit_page exclusion, then the return value and the externalId rule, so the highest-value information arrives first. Five dense sentences with no filler, though the externalId sentence overlaps the schema text and could have been trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the description still notes the return value and link, and annotations cover the safety profile, so coverage is largely adequate for an 11-parameter mutation tool. The remaining gap is the tension between whole-page replacement and destructiveHint=false, which an agent calling this destructively would want resolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter already carries a rich description, so the schema does the heavy lifting; baseline is 3. The prose adds one useful example (externalId as the source file path in the repository) but otherwise repeats what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("File a Markdown document into the user's vault as a page") plus the scope of the operation (create-or-update). It also names the sibling it is not ("use edit_page instead to change part of one"), so an agent can route between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-not with the alternative named (whole-page replacement vs. edit_page), and adds conditional guidance for the risky parameters: only send "anyone" when the user asks, and leave access/publish out to preserve current visibility. The externalId advice (use the source file path so rewrites update rather than duplicate) is actionable usage guidance, not just a restatement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
edit_page1 field changedInput schema / properties / projectAdded value: +{
+ "description": "The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.",
+ "type": "string"
+}publish_page1 field changedInput schema / properties / projectAdded value: +{
+ "description": "The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.",
+ "type": "string"
+}read_page2 fields changedInput schema / properties / projectAdded value: +{
+ "description": "The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.",
+ "type": "string"
+}Output schema / properties / projectAdded value: +{
+ "description": "The project the key is filed under, lowercased.",
+ "type": [
+ "string",
+ "null"
+ ]
+}search_pages1 field changedOutput schema / properties / results / items / properties / projectAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}write_page2 fields changedInput schema / properties / externalId / descriptionPrevious value: -"A stable key for this artifact, unique within the vault. Strongly recommended: without it, writing the same document twice leaves two pages."New value: +"A stable key for this artifact, unique within its project. Strongly recommended: without it, writing the same document twice leaves two pages."Input schema / properties / projectAdded value: +{
+ "description": "The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.",
+ "type": "string"
+}edit_pageget_accountpublish_pageread_pagesearch_pageswrite_pageEncrypted Markdown notes and team knowledge base. Search, read and write notes in vaults you allow.
Search workspace knowledge, save ideas, update notes, organize folders, and share public links.
Publish pages your agent writes to a private, shareable URL, then read, comment on and update them.
Cloud notes and AI workspace: search your notes and save AI answers as editable, shareable docs.
Add one secure layer between your agents and this server.
