Skip to main content
Glama

Read a private note's history

get_my_note_history
Read-onlyIdempotent

Every version of one of your sealed notes. Returns: The versions.

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": {
      "campaign": "<campaign>",
      "note": "<note>"
    },
    "name": "get_my_note_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteYesThe note's id.
campaignYesThe campaign, by its slug (what its link says) or its id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds only the implicit privacy scoping ('your sealed notes') and the fact that all versions are returned rather than one; it says nothing about ordering, pagination, or whether version content/author is included, which is the remaining behavioral gap.

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

Conciseness3/5

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

It is short and front-loads the resource, but the second sentence 'Returns: The versions.' is circular and conveys no information, so one of the two sentences does not earn its place.

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

Completeness2/5

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

There is no output schema, so the description is the only place to explain what a 'version' contains (content snapshot, timestamps, pagination, ordering). 'Returns: The versions.' supplies none of this, leaving an agent unable to anticipate the response for a history-style read.

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% and both parameters (note id, campaign slug-or-id) are fully documented in the schema. The description adds no meaning beyond that, so baseline 3 applies.

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

Purpose3/5

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

The description identifies the resource (version history of a note) and 'Every version of one of your sealed notes' distinguishes it from the sibling update_my_note and list_my_notes. But the verb is only implied by the tool name/title, and the phrase 'sealed notes' is unexplained jargon, so the purpose reads as vague rather than crisp.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_my_notes (to find a note) or get_wiki_page_history (the analogous history tool for wiki pages). The agent must infer the call context entirely.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.