Skip to main content
Glama
Sign In

Umtri

by io.umtri
OverviewDiscussionsAdmin

Send feedback about Umtri itself

send_feedback

Files a suggestion or a defect report about Umtri the product — this MCP server, its tools, the app, the docs. This is NOT for issues in the user's own project: those are bugs on a ground (create_bug). Call this ONLY when the human explicitly asks to leave feedback ("건의해줘", "report this to Umtri"). Do not file feedback on your own initiative — an inbox filled by agents stops being read. kind: "bug" = something in Umtri is broken or wrong; "improvement" = a suggestion / wish (default). source: where it surfaced — the ground slug you were working in, the tool name that felt wrong, the screen. It is free text and is not validated, but it is what makes a report actionable later. One-way: this files the report, and there is no reading it back — do not promise the human a status thread. Requires a write-scope token.

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

Input Schema

NameRequiredDescriptionDefault
bodyNoDetails — what you expected, what happened, why it matters (markdown allowed).
kindNo"bug" for something broken in Umtri, "improvement" for a suggestion. Defaults to "improvement".
titleYesOne-line summary. Required.
sourceNoWhere it came up: ground slug, tool name, or screen.

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?

With no annotations supplied, the description carries the full burden and does so: it discloses the write-scope token requirement, that the operation is one-way with no read-back, and that the human must not be promised a status thread. It also explains why the 'source' field matters (report actionability) and warns against autonomous filing — behavioral context well beyond a bare 'send' verb.

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 the purpose and the create_bug exclusion before any parameter talk, and nearly every sentence carries a constraint or a warning. It runs long for a 4-parameter tool and the bilingual quote plus repeated field explanations add some bulk, but there is little pure filler.

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 write tool with no annotations and no output schema, everything an agent needs is present: authority requirement, irreversibility, human-consent gate, field semantics, and correct sibling routing. No output schema exists, but the one-way nature is explicitly stated so the absence of a return contract is not a gap.

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; the description nonetheless adds meaning the schema lacks, notably that source is free text and unvalidated yet is what makes a report actionable later, and it reinforces the default of kind='improvement'. It largely restates the kind/source enums already documented, so it is an increment rather than a replacement.

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?

States a concrete verb+resource ('Files a suggestion or a defect report about Umtri the product') and enumerates the scope (this MCP server, its tools, the app, the docs). It explicitly carves out the near-miss sibling by name: project issues belong to create_bug, not here. An agent can distinguish this from create_bug/list_feedback without opening any schema.

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?

Gives an explicit trigger ('ONLY when the human explicitly asks'), a quoted example utterance, an explicit prohibition ('Do not file feedback on your own initiative'), and the alternative tool for the adjacent case (create_bug). When-to-use, when-not-to-use, and the routing alternative are all present.

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

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