Skip to main content
Glama

Premiss

Save a research note

save_research_note
Idempotent

Save a NEW private note in the connected workspace, with optional exact owned strategy/run evidence references. The note is user-authored content. Does not publish or send it anywhere.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
titleYes
run_idNo
revisionNo
request_keyYesIdempotency UUID identifying one requested write and its unchanged arguments.
strategy_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
savedYes
titleYes
app_urlYes
note_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and idempotentHint=true with destructiveHint=false, so the bar is lower; the description adds genuine context that the note is private, user-authored, and not published or transmitted. It does not, however, explain the idempotency/request_key or revision behavior beyond the annotation.

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?

Three short sentences, front-loaded with the action and scope, and every sentence carries information. 'The note is user-authored content' is mildly redundant but reinforces the privacy framing.

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

Completeness3/5

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

With annotations covering safety/idempotency and an output schema covering the response, the remaining burden is parameter meaning. The description handles the evidence-reference parameters but is silent on the required idempotency key and revision parameter, leaving gaps for a 6-param write tool.

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 only 17% (just request_key), so the description must compensate. It usefully clarifies that strategy_id/run_id are optional 'exact owned' evidence references, but leaves the required request_key and the revision parameter unexplained, and adds nothing about title/note beyond the schema constraints.

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+resource (save a research note), states the scope (NEW, private, in the connected workspace) and the optional evidence-linking capability. It is clearly distinguishable from sibling tools like list_research or update_strategy without opening any schema.

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

Usage Guidelines3/5

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

Implies usage (capturing user-authored research) and gives one exclusion via 'Does not publish or send it anywhere,' but never names an alternative tool or states when to prefer saving a note versus, say, updating a strategy. Guidance is implied rather than explicit.

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.

Resources