Skip to main content
Glama
Sign In

Moose Tracker

by app.moosetracker
OverviewDiscussionsAdmin

Send feedback

feedback

Sends a note to the Moose Tracker team about a bug, a confusing tool, or a missing feature. Up to 20000 characters per call; longer reports can be split into parts. Schema 3b8fe45c.

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

Input Schema

NameRequiredDescriptionDefault
mtlNoOptional: the song or sound involved, only if relevant
refNoOptional label shared by every part of one long report; parts with the same ref count as one submission
partNoWhich part this is (1 based)
typeYes
partsNoHow many parts in all
messageYesWhat happened or what is needed; no personal details. Up to 20000 characters; longer reports go in parts (ref, part, parts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / description
      Previous value: -"Schema 9b20e675"New value: +"Schema 3b8fe45c"
  2. Changed1 schema field changed
    • changedInput schema / description
      Previous value: -"Schema 415a8741"New value: +"Schema 9b20e675"
  3. Changed1 schema field changed
    • changedInput schema / description
      Previous value: -"Schema d568427c"New value: +"Schema 415a8741"
  4. Changed1 schema field changed
    • changedInput schema / description
      Previous value: -"Schema 90ddc268"New value: +"Schema d568427c"
  5. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"Schema 90ddc268"
  6. First observed

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already establish that this is a non-destructive, non-idempotent, closed-world write, so the description only needs to add context, and it does: the 20000-character ceiling and the multi-part submission mechanism are genuine behavioral facts an agent needs. It says nothing about rate limits, whether a submission can be retracted or edited, or what comes back after sending, which matters since no output schema exists.

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?

Two tightly written sentences front-load the purpose and then the size constraint, with no filler. The trailing 'Schema 3b8fe45c.' is an internal artifact that occupies space without informing an agent.

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 six-parameter submission tool whose schema is well documented and whose annotations cover safety, the description supplies the essential extras: what the tool is for, the size limit, and the paging mechanism. The remaining gap is post-submission behavior, which is unclear because there is no output schema.

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 coverage is 83%, so the schema already explains mtl, ref, part, parts, and message; the baseline of 3 applies. The description reinforces the message-length limit and the split-into-parts pattern, but it adds no format or semantics for type, mtl, or the ref/part/parts relationship beyond what the schema states.

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 description gives a concrete verb and resource: it sends a note to the Moose Tracker team, and it enumerates the acceptable subjects (bug, confusing tool, missing feature). That is enough to distinguish it from the unrelated siblings (assets, convert, render, song), though it never names or contrasts them explicitly.

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?

It clearly states the situations that warrant a call, in terms of a bug, a confusing tool, or a missing feature, and it adds a practical cue that oversized reports should be split into parts. It does not state any when-not-to-use condition or an alternative channel for support requests, so the guidance is solid but not exhaustive.

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

All Moose Tracker 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