Skip to main content
Glama
zoombulous

humor-mcp

by zoombulous

taste_profile

Review liked versus disliked humor samples to calibrate your writing register before producing content, with per-rater score distributions for targeted audience alignment.

Instructions

What this corpus's human rater actually liked versus disliked, with the score distribution. Use this to calibrate register before writing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNohow many examples per side (capped at 200)
kindNojoke / pun / candidate / slate_winner / eval / utterance / word
raterNorestrict to one rater's judgements
include_hiddenNoinclude packs the corpus owner marked off-rubric — their licence is fine, they were judged unrepresentative
include_restrictedNoinclude packs whose LICENCE bars redistribution (local reference only)
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't disclose how results are returned, the meaning of the 'liked vs disliked' structure, sorting, pagination, or what happens with edge cases like an rater with no judgements. For a tool without annotations, this is a thin behavioral disclosure.

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 tight sentences that front-load the primary purpose and then give actionable guidance on when to use it. No wasted words or redundant detail. Could arguably add a note on return format but remains efficiently concise.

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?

The tool has 5 optional parameters and no output schema, so the description carries the burden for return semantics. The description explains the conceptual purpose well but leaves the actual output structure (what a 'score distribution' looks like, how liked vs disliked items are presented) unspecified. Adequate but with a notable gap given the absence of an output schema.

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% and all five parameters have inline descriptions in the schema, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already documents; the schema's 'kind' and 'rater' descriptions are serviceable. The description doesn't compensate further but isn't required to at this coverage level.

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?

The description clearly states the tool shows what the corpus rater liked vs disliked with a score distribution, using a specific verb ('calibrate') plus resource ('register'). It distinguishes itself from siblings by its focus on the rater's taste profile versus other tools like search_humor or breakdown. However, it doesn't explicitly compare against sibling distinctions beyond the implicit calibration framing.

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

Usage Guidelines4/5

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

The description explicitly frames this as a calibration tool before writing ('Use this to calibrate register before writing'), which gives clear context for when to invoke it. It doesn't name specific alternatives or exclusions, but the calibration-when-before-writing guidance plus sibling names like top_rated and breakdown provide implied differentiation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zoombulous/humor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server