Skip to main content
Glama

Get a runnable check

ihumane_get_check
Read-only

Returns a check to run on your own work. Browser checks run on the RENDERED page (browser console or a browser tool's evaluate/execute): 'spacing': text touching lines, uneven padding. 'contrast': text and field edges too faint against their real background, in light and dark mode. 'affordance' (Pro): controls that look like something they aren't, link underlines, back-link direction. 'stability' (Pro): controls that move or resize when used. 'copy' (Pro): vague labels, 'click here' links, placeholder-only fields, missing alt text, errors with no next step, machine-voice words. Code check, run with Node in the project: 'tidy': leftovers in your change (debug logs, .only in tests, empty catches, likely secrets, new TODOs, commented-out code, very long functions). 'wayfinding' (UX design): Pages that don't say where you are or give a way back: no clear heading or a generic page title, menus with no current item, a breadcrumb that links to itself, a deep page with no way up, a step with no Back or way out, and dead ends. 'images' (Graphics and images): Images shown larger than the file (blurry), files far wider than their slot, stretched images, broken images, images with no width and height, missing or useless alt text, icon-only buttons with no name, heavy files, and icons in one row with different sizes, strokes or styles. 'diffmap' (Code review): The shape of a change before you review it: size, a reading order, and what to look at closely (code changed with no test, migrations, data deletes, risky paths, removed exports still in use, new dependencies, imports of packages the project doesn't have, tests that mock what they test). 'layout' (Front-end build): Sideways scrolling and the element causing it, text cut off by a fixed height, tap targets that are too small at touch widths, stretched or oversized images, clickable divs with no role, fields with no label or the wrong type, and skipped heading levels. 'trust' (QA and testing): Tests you can't trust: tests that check a constant or assert nothing, tests that only check a fake was called, checks that pass for almost any result, snapshot-only tests, fixed waits, retries that hide flaky tests, end-to-end tests that find elements by CSS class or position, and the real clock or random numbers inside a check.

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": {
      "name": "<name>"
    },
    "name": "ihumane_get_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesWhich check to get

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / enum
      Previous value: -[
      -  "spacing",
      -  "contrast",
      -  "affordance",
      -  "stability",
      -  "tidy",
      -  "copy"
      -]New value: +[
      +  "spacing",
      +  "contrast",
      +  "affordance",
      +  "stability",
      +  "tidy",
      +  "copy",
      +  "wayfinding",
      +  "images",
      +  "diffmap",
      +  "layout",
      +  "trust"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / name / enum
      Previous value: -[
      -  "spacing",
      -  "affordance",
      -  "stability",
      -  "copy"
      -]New value: +[
      +  "spacing",
      +  "contrast",
      +  "affordance",
      +  "stability",
      +  "tidy",
      +  "copy"
      +]
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context beyond that: checks are intended to be run on your own work, browser checks require a rendered page or browser console/evaluate, code checks use Node, and several checks are marked Pro. It still omits auth or rate-limit details, but those are minor for this read-only lookup.

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?

The purpose is front-loaded in the first sentence, and the length is largely justified by the need to explain eleven enum values. The structure is dense and run-on, with no bullets or clear section breaks, but the content is relevant and not repetitive.

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 one-parameter lookup tool with no output schema, the description is largely complete: it explains all check categories, execution environments, and Pro status. It does not describe the exact return format or selection guidance relative to sibling tools, but the annotations and schema already cover core safety and parameter details.

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

Parameters5/5

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

Schema coverage is 100% and the single parameter is an enum, but the description goes much further by explaining what each enum value actually detects. For example, it maps 'spacing' to text touching lines and uneven padding, and 'diffmap' to change size, reading order, and review risks. This adds substantial meaning beyond the schema.

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 states a specific action and resource: 'Returns a check to run on your own work,' and it enumerates the check domains available. It does not explicitly differentiate this tool from siblings such as ihumane_get_rules or the various start tools, so it is clear but not fully sibling-distinguishing.

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

Usage Guidelines3/5

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

The description gives operational context for using the returned checks, notably that browser checks run on the rendered page and code checks run with Node in the project. However, it does not say when to call this tool instead of related tools or provide exclusions, so usage guidance is implied rather than explicit.

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.

Resources