Skip to main content
Glama
Sign In
MEME

MEME

by renniyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Your generation history

get_history

Retrieve your rendered memes newest first, using an optional limit, to review and track your meme creation history.

Instructions

Your own rendered memes, newest first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden: it discloses scope (own items only) and ordering (newest first), and implies a read operation. It does not say whether deleted or unrendered generations appear, what a default page size is, or how results are truncated, which are meaningful gaps for a history feed.

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?

A single short sentence with the resource and the ordering front-loaded; nothing is padded or redundant.

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?

For a simple read-only history tool with no output schema, the description conveys what is returned and in what order, but leaves the limit/pagination semantics and the boundary against list_memes unresolved. It is minimally adequate rather than complete.

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

Parameters2/5

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

The single parameter (limit, 1-100) has 0% schema description coverage, so the description must explain it, but it says nothing about what limit controls, its default, or maximum. For a one-parameter tool this is a modest but real omission.

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

Purpose4/5

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

"Your own rendered memes, newest first" names the resource (rendered memes), the scope (yours only), and the ordering, which lets an agent distinguish it from broader catalog tools like list_memes or list_favorites. It stops short of explicitly naming a sibling it is not, so it is clear but not maximally differentiated.

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?

The description gives no when-to-use statement, no conditions, and no alternatives; the only implicit guidance is the word "your", which hints at personal scope. An agent must infer from sibling names alone whether to call this versus list_memes or list_favorites.

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

Deploy Server

Other Tools