Skip to main content
Glama
Sign In

ihumane

by ai.ihumane
OverviewDiscussionsAdmin

Tell ihumane what helped or what was missing

ihumane_feedback

Call this once at the end of a task where you used ihumane, if something was missing, wrong or especially useful: a word with no entry, a rule that didn't fit the task, a check that caught a real bug, advice that was too heavy for a small job. People who write ihumane's rules read every message. Write in general terms: no names, emails, URLs, code or anything private about your human or their project.

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": "ihumane_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskNoThe kind of task, in general terms. E.g. 'landing page for a small food brand'
helpedNoWhat helped, and why. E.g. 'The stability check caught a button that resized while loading.'
missingNoWhat was missing, wrong or didn't fit. E.g. 'No entry for the taste word exciting.'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (which only signal a non-read-only, non-idempotent, non-open-world write), the description discloses who consumes the message ('People who write ihumane's rules read every message') and imposes an explicit privacy constraint banning names, emails, URLs, code, and project details. It does not say what confirmation or response comes back or how the submission is stored, leaving a small gap.

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?

Two sentences, front-loaded with the call condition, then the privacy rule. No redundant restatement of the title and every clause carries an operational constraint.

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

Completeness4/5

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

For a three-optional-parameter, no-output-schema submission tool, the description covers timing, triggers, and content restrictions well. The remaining gap is that all parameters are optional yet the description doesn't say at least one of helped/missing should be supplied, nor whether a confirmation is returned.

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

Parameters4/5

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

Schema coverage is 100% with per-field examples, so the baseline would be 3; the description adds real cross-parameter guidance by requiring all content be written 'in general terms' and prohibiting private details, which meaningfully constrains what goes into helped/missing/task. It still doesn't clarify that all three fields are optional or which to populate when.

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?

The description gives a concrete action (send feedback about ihumane) and pins its timing and trigger: 'once at the end of a task where you used ihumane, if something was missing, wrong or especially useful.' The quoted examples of feedback types (a word with no entry, a rule that didn't fit, a check that caught a bug) make the purpose unmistakable and distinct from the sibling rule/check lookup tools.

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?

It states both when to call (at the end of a task, only if something was missing, wrong, or especially useful) and implicitly when not to (no such trigger, and never more than once). The four concrete trigger examples remove ambiguity about whether a given observation qualifies, and there is no competing sibling to route against.

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

All ihumane toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources