Skip to main content
Glama
Sign In

Umtri

by io.umtri
OverviewDiscussionsAdmin

Report a bug on a ground

create_bug

Creates a new bug (issue eroding the target). target.kind = "node" or "api" requires target.id of an existing node/api in the ground. target.kind = "ground" attaches the bug to the project itself (no id). score = change risk on a 0–8 scale (8 = riskiest). It blends functional impact with fix difficulty (a harder fix is likelier to break things, so it ranks higher within a tier). 0: no risk — idea / memo. 1: no risk — copy / wording edit. 2: no functional error, but may change usability. 3: minor functional issue possible — simple fix. 4: minor — complex fix. 5: significant functional issue possible — simple fix. 6: significant — complex fix. 7: critical functional issue possible — simple fix. 8: critical — complex fix. Defaults to 4. Urgency is intentionally NOT part of this score. status defaults to "open". solution is the fix, and it belongs to agents — the app gives people no way to edit it, so a human's own proposed fix arrives in description instead. At report time solution holds the plan, and by the time the bug is resolved it should describe what was actually applied. Same field — overwrite it as understanding changes; project_events keeps the diff. Write what remains as "- [ ] item" lines so the app can render them as cards and later moves cost one small op (update_bug patch:{solutionItem}). Leave it empty rather than guessing. For a node/api bug, the response auto-attaches impact (the affected blast radius from the target): reachedCount, the reached nodes with hop distance and the connection each was reached through, other active bugs sitting in that radius, and a coverage note. Use it to scope what else to check/QA. If the target has no recorded connections the radius is empty — that means nothing is recorded, not that nothing is affected (record edges/apis). Requires a write-scope token. See umtri://rules/vocabulary for bug semantics.

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": {
      "slug": "<slug>",
      "title": "<title>",
      "target": "<target>"
    },
    "name": "create_bug"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesGround slug.
scoreNoChange risk 0–8 (8 = riskiest: critical impact × complex fix). Defaults to 4. See tool description for the rubric.
titleYesShort summary of the bug. Required.
statusNoDefaults to "open".
targetYesBug target. Use {kind:"ground"} when the bug is about the project as a whole.
solutionNoHow to fix it. At report time this is the plan/idea; update it to what was actually applied when you resolve. Markdown allowed. Omit if you do not know yet.
descriptionNoLonger details on what is wrong (markdown allowed).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the write-scope token requirement, that the response auto-attaches impact data for node/api targets, that solution is agent-owned and audited via project_events, and that an empty radius means unrecorded rather than unaffected. These are non-obvious behaviors an agent could not infer from the schema.

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?

Purpose is front-loaded in the first sentence, but the rest is one dense block mixing the score rubric, return-value behavior, solution lifecycle, and conventions with no structure. There is some waste, such as restating the score default of 4 and the status default that the schema already declares.

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 7-parameter tool with a nested target object and no output schema, the description covers everything an agent needs: target semantics, scoring, field ownership, auth scope, and the shape of the auto-attached impact response including the reachedCount/blast-radius concept and the empty-radius caveat.

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%, so the baseline is 3, but the description adds substantial meaning beyond it. The 0–8 score rubric is fully explained with the rationale (functional impact blended with fix difficulty) and an explicit note that urgency is excluded, and the solution field's formatting contract ("- [ ] item" lines rendered as cards) is documented nowhere in the schema.

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?

Opens with a specific verb and resource ("Creates a new bug") and immediately defines what a bug is ("issue eroding the target"). It goes further by spelling out the three target kinds and what each attaches to, which cleanly separates this from update_bug/delete_bug and from the create_node/create_api siblings.

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?

Gives concrete selection guidance: which target.kind to choose, when to populate solution versus leaving it empty, and when to overwrite it. It also flags the write-scope token prerequisite and points to umtri://rules/vocabulary. What it lacks is an explicit statement of when to use update_bug instead of creating a new bug.

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