Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_meta_render_card

Render a card as an MCP-application UI surface, returning plaintext for CLI clients and HTML for web clients. Use it as a template to ship real UI surfaces instead of markdown.

Instructions

Render a card as an MCP-application UI surface. Returns both a plaintext summary (for CLI / legacy clients) and an HTML body (for web-based clients that opt into the ui content type — Claude Desktop, ChatGPT, web harnesses). Use this as a template for any domain tool that wants to ship a real surface instead of pasting markdown — wire uiResult(...) from core/helpers.ts.

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

Input Schema

NameRequiredDescriptionDefault
bodyNoMarkdown body. A small renderer turns it into HTML.
itemsNoOptional list rendered as a <ul>.
titleYesCard title shown as <h2>.
accentNoAccent color name. Default: blue.

Output Schema

NameRequiredDescriptionDefault
bytesYes
mimeTypeYes
renderedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden and does disclose the notable behavior: the tool returns a dual payload, plaintext summary for legacy clients and an HTML body only for clients that opt into the `ui` content type, with named examples. It does not state whether the operation is side-effect free or whether rendering has limits/rate constraints, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core behavior is front-loaded and stated efficiently in the first sentence. The second sentence, however, mixes in implementation instructions (wiring `uiResult(...)` from `core/helpers.ts`) that do not help an agent select or invoke the tool, so not every sentence earns its place for the intended audience.

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 rendering tool with an output schema and 100% parameter coverage, the definition supplies the key missing piece: the client-dependent output behavior. What remains absent is guidance on when to choose this renderer versus sibling card tools, which is a modest gap given the otherwise complete picture.

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 description coverage is 100%, so title, body, items, and accent are already fully documented in the schema (including the accent enum and default). The description adds no additional meaning about parameter behavior or interactions, so the baseline 3 applies.

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 first sentence names a specific verb and resource: 'Render a card as an MCP-application UI surface.' It is immediately clear what the tool produces. It does not differentiate itself from the closely named sibling kernel_today_card, so it falls short of a 5.

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 implies the usage context ('for CLI / legacy clients' vs 'web-based clients that opt into the ui content type'), but it never states when an agent should call this instead of another card-producing tool. The remaining guidance ('use this as a template... wire uiResult(...) from core/helpers.ts') addresses tool developers implementing new tools rather than an agent deciding to invoke this one.

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