Skip to main content
Glama

klyo games: publish HTML5 browser games

by pl.klyo
OverviewDiscussionsAdmin

Write the creator's profile card (owner's own AI)

klyo_creator_card
Destructive

The developer's profile card on games.klyo.pl: “about me” and the tagline under the name. YOU WRITE: the owner's assistant, on the owner's own AI plan; klyo runs no model. Without o_mnie and haslo we return the current card, the released games (the only material you may write from) and the rules. With them, we save through the same check as the studio; an omitted field stays unchanged. Saving changes the developer's public page immediately and replaces the previous text, so FIRST show the text to the owner and save only with their consent. Do not invent facts about the person.

Examples: • Write my developer profile card on klyo • Improve the tagline under my name on my developer page • What is in my profile card on games.klyo.pl now?

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hasloNoOne sentence up to 80 characters per language with no full stop; may have <pl>...</pl><en>...</en>, each version counted on its own. Omit to leave it as it is.
o_mnieNo“About me” in the first person; two versions in tags <pl>…</pl><en>…</en>. Omit to only read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / haslo / description
      Previous value: -"One sentence up to 80 characters with no full stop; may have <pl>…</pl><en>…</en>. Omit to leave it as it is."New value: +"One sentence up to 80 characters per language with no full stop; may have <pl>...</pl><en>...</en>, each version counted on its own. Omit to leave it as it is."
    • changedInput schema / properties / haslo / maxLength
      Previous value: -90New value: +400
  2. Changed2 schema fields changed
    • changedInput schema / properties / haslo / description
      Previous value: -"Jedno zdanie do 80 znaków bez kropki; może mieć <pl>…</pl><en>…</en>. Pomiń, żeby zostało, jak jest."New value: +"One sentence up to 80 characters with no full stop; may have <pl>…</pl><en>…</en>. Omit to leave it as it is."
    • changedInput schema / properties / o_mnie / description
      Previous value: -"„O mnie” w pierwszej osobie; dwie wersje w znacznikach <pl>…</pl><en>…</en>. Pomiń, żeby tylko odczytać."New value: +"“About me” in the first person; two versions in tags <pl>…</pl><en>…</en>. Omit to only read."
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses the immediate public replacement of the previous text, the read-only fallback, the consent requirement, and the 'do not invent facts' constraint. This is consistent with destructiveHint=true and adds meaningful behavioral context.

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?

The description is dense and front-loaded: purpose, then mode behavior, then safety constraint, then examples. Every sentence adds operational or policy value; there is little wasted text.

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

Completeness5/5

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

For a 2-parameter tool with no output schema, the description is complete: it explains what is returned in read mode, what happens on save, what the only allowed source material is, and what constraints apply. An agent has enough to select and invoke it correctly.

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%, so the baseline is 3, but the description adds important semantics: omitting both parameters means read-only, omitting one preserves its current value, and saving goes through the same check as the studio. These are not evident from the schema alone.

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 identifies a specific resource ('the developer's profile card on games.klyo.pl') and the concrete actions: read or write the 'about me' text and tagline. The 'YOU WRITE' context and profile-card scope clearly separate it from the game-management sibling tools.

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 gives explicit conditions: without `o_mnie` and `haslo` it reads; with them it saves, and an omitted field stays unchanged. It also adds a strong usage rule: show the owner the text first and save only with consent. It doesn't explicitly name alternatives, but no sibling tool covers the profile card.

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

All klyo games: publish HTML5 browser games toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources