Skip to main content
Glama

Like Paper

like_paper

Like a paper — a 'more like this' calibration signal that tunes the user's For You feed toward similar work. INSERT-only and idempotent (liking twice is a no-op, never un-likes). Distinct from save_paper: like expresses taste for ranking; save bookmarks for later reading. Requires SF_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
arxiv_idYesarXiv ID of the paper to like.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNoTrue when the operation succeeded.
watchNoThe created/affected watch, when applicable.
actionNoMachine label: saved | no_change | removed | liked | created | updated | deleted.
messageNoHuman-readable summary of the outcome.
arxiv_idNo
collectionNoThe created/affected collection, when applicable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations only showing readOnlyHint=false and destructiveHint=false, the description discloses meaningful behavior: INSERT-only, idempotent, never un-likes, and requires SF_API_KEY. This goes beyond the annotations and gives the agent a clear model of side effects.

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

Conciseness5/5

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

Three tight sentences deliver purpose, behavior, sibling distinction, and authentication requirement with no filler. The most important functional trait is front-loaded, and every sentence contributes useful, non-redundant 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?

For a single-parameter mutation tool with an output schema and annotations present, the description covers everything an agent needs: what it does, how it behaves, how it differs from save_paper, and the API key requirement. Nothing essential is missing.

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 coverage is 100%, so the schema already documents arxiv_id as 'arXiv ID of the paper to like.' The description adds no new parameter-level detail, but none is needed given the single self-explanatory parameter; baseline 3 is appropriate.

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?

Description opens with 'Like a paper' and explains the purpose: a 'more like this' calibration signal that tunes the For You feed. It explicitly distinguishes itself from save_paper, so an agent can immediately tell what this tool does and what it does not do.

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

Usage Guidelines5/5

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

States when to use this tool versus save_paper: 'like expresses taste for ranking; save bookmarks for later reading.' It also explains key constraints—INSERT-only and idempotent—so the agent knows calling it repeatedly is safe and will not un-like.

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.