Skip to main content
Glama
Sign In

ShareNotes

by dev.sharenotes
OverviewDiscussionsAdmin

Create a ShareNotes link

create_note

Publish text as a note on sharenotes.dev and get back a short, human-readable link (like https://sharenotes.dev/blue-fox-42) to give to a person. Use it when the user wants to share text, code, logs or instructions with someone else, or move text to another device. Anyone with the link can read the note, and notes are stored on the server, not end-to-end encrypted — never use it for passwords, API keys or other secrets. The note expires after 7 days unless you set expiresIn. Set burnAfterRead for a note that is destroyed the first time a person opens it, or maxViews (2–100) for one destroyed after that many opens. Returns the link and the expiry time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>"
    },
    "name": "create_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoOptional short title shown above the note.
contentYesThe text to publish. Plain text or Markdown. Up to 10 MB.
maxViewsNoDelete the note after this many opens (implies burnAfterRead). Link previews and reloads by someone who already opened it do not count.
expiresInNoHow long the note lives. Defaults to 7d.
burnAfterReadNoIf true, the note is deleted the first time someone opens the link. Link previews in chat apps do not count.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / maxViews
      Added value: +{
+  "description": "Delete the note after this many opens (implies burnAfterRead). Link previews and reloads by someone who already opened it do not count.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that the link is publicly readable, that content is server-side and not end-to-end encrypted, the 7-day default lifetime, and the destruction semantics of burnAfterRead and maxViews. Those visibility and persistence facts are exactly what annotations (write, open-world, non-idempotent, non-destructive) cannot convey, and none of them are contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the link format, then safety, then the optional destruction controls — a sensible order with no filler sentences. It runs long for a five-parameter tool and repeats some schema-stated defaults, but every sentence contributes either usage or safety information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by stating exactly what comes back ('the link and the expiry time'). Combined with the security warning and the expiry/one-time-read explanation, an agent has everything needed to call this safely and report the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, and the description mostly restates the schema's own hints about expiresIn defaults and burnAfterRead. It does add a conflicting detail: it advertises maxViews as '2–100' while the schema permits minimum 1, which could make an agent wrongly reject a valid value of 1.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Publish text as a note on sharenotes.dev') and states the concrete outcome, including the shape of the returned link ('https://sharenotes.dev/blue-fox-42'). That output description alone distinguishes it from the read_note sibling without requiring the schema to be opened.

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

Usage Guidelines4/5

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

Gives explicit positive triggers ('share text, code, logs or instructions with someone else, or move text to another device') and a hard exclusion ('never use it for passwords, API keys or other secrets'). It never names read_note as the counterpart for retrieving a note, so the routing half of the guidance is left implicit.

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

All ShareNotes toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources