Skip to main content
Glama
Sign In

krobot

by io.github.Kromatic-Innovation
OverviewDiscussionsAdmin

Send feedback

feedback

Send a bug report, feature request or comment about Krobot to the Kromatic team by email when the user asks you to.

Needs a free Kromatic account. Just call it: if the user is not signed in, their AI app shows the Kromatic sign-in screen and then this same call goes through; do not refuse or ask them to sign in first. If the app cannot show a sign-in screen, the call returns a "Sign in to use feedback" error; tell the user this step needs a free Kromatic account. Also needs the user's real email address as sender_email: ask for it, never invent one. They receive a copy. Returns a confirmation, or a delivery error.

Next: tell the user it was sent, or report the error. For questions about the content itself, use search_resources instead.

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": {
      "feedback_type": "<feedback_type>",
      "message": "<message>",
      "sender_email": "<sender_email>"
    },
    "name": "feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageYesYour feedback or request. Be as specific as possible.
sender_nameNoThe user's name (optional).
sender_emailYesThe user's real email address (ask them; never invent one). They receive a copy of the message.
feedback_typeYesThe kind of feedback: 'feedback' for general comments, 'feature_request' for new capabilities, 'bug' for issues.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-idempotent, open-world, non-destructive call; the description goes well beyond that by disclosing the free-account requirement, the sign-in interception flow, the exact error string returned, the side effect that the user receives a copy, and the success/error return shape. That is precisely the context annotations cannot carry.

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?

Front-loaded with purpose and trigger, then auth flow, then next steps — a sensible order with no filler sentences. It is somewhat long and repeats the sender_email 'ask, never invent' point from the schema, costing a point on tightness.

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 mutation tool with no output schema, it covers prerequisites, failure modes with literal error text, side effects, and the follow-up the agent must perform. Nothing needed to invoke it correctly or recover from failure is missing.

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 baseline is 3; the description adds genuine semantics for sender_email by mandating it be asked for and never invented, and noting the user gets a copy. It adds nothing about feedback_type or message length limits beyond the schema, so it is not a full 5.

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 opening sentence names a specific verb and resource (send a bug report, feature request, or comment about Krobot by email to the Kromatic team) and explicitly bounds the trigger to user request. It also names the sibling search_resources as the tool for content questions, so the agent can separate this from read-oriented siblings without inspecting schemas.

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 exactly when to use it ('when the user asks you to'), explicitly forbids the common failure mode ('do not refuse or ask them to sign in first'), describes the fallback when sign-in is unavailable, and routes content questions to search_resources. Alternatives and exclusions are both present.

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

All krobot 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