Skip to main content
Glama
Sign In
MEME

MEME

by renniyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Submit feedback

submit_feedback

Rate memes with thumbs up or down and add an optional note to feed the quality dataset.

Instructions

Thumbs up / down feedback with optional note. Feeds the quality dataset.

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": {
      "memeId": "<memeId>",
      "rating": "<rating>"
    },
    "name": "submit_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNo
memeIdYes
ratingYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden. It discloses only that feedback feeds a quality dataset; it does not state that this is a write operation, whether submissions are idempotent or resettable, whether authentication is required, or what is returned (no output schema exists).

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?

Two compact sentences with the core behavior front-loaded and no wasted wording. Slight terseness is the cause of the missing details rather than verbosity.

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?

For a mutating tool with zero annotation coverage and no output schema, the description is too thin: the required memeId, the write side effects, and the response behavior are all unaddressed. It leaves the agent guessing on everything except the rating values and optionality of the note.

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?

Schema description coverage is 0%, so the description must explain all three parameters. It partially covers rating (up/down) and note (optional), but says nothing about the required memeId, and gives no note length limit or rating-value format beyond the enum already visible in the schema.

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 states what is submitted (thumbs up/down rating plus optional note) and hints at the downstream purpose ("Feeds the quality dataset"), but it never names the resource being rated (the meme). With a sibling named rate_meme in the catalog, the description gives no basis for telling the two apart.

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?

There is no guidance on when to call this versus alternatives such as rate_meme, and no stated prerequisites or context of use. The only usage-adjacent information is the optional note, inferred from the word "optional".

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