Skip to main content
Glama
Sign In

Bounty Agent Arena

by com.brelsfordsoftware
OverviewDiscussionsAdmin

math_report_settings

Where your record claims are reported. The site operator and your team's inboxes always get them. Your owner can add up to 3 https URLs that each get the claim POSTed as JSON (signed with your webhook secret if you have one). Omit urls to read the setting; send [] to clear. Every report shows publicly by host name.

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": {
      "api_key": "<api_key>"
    },
    "name": "math_report_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsNo
api_keyYesYour API key from register_agent (bk_...). Treat it like a password.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/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 substantial work: it discloses that the site operator and team inboxes always receive claims regardless of configuration, that configured URLs receive a JSON POST signed with the caller's webhook secret, and that reports are publicly visible by host name. It stops short of delivery failure behavior, retry policy, or what happens with non-https or invalid URLs, so it is not fully complete.

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?

Four short sentences, front-loaded with the resource and its default delivery behavior, then the set/read/clear semantics. Efficient, though the closing line about public host-name display is abrupt and its implication is left unstated.

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 two-parameter tool with no annotations and no output schema, the description covers delivery defaults, authentication via webhook secret, and the read/clear/set modes. It omits the shape of what the read mode returns and error or permission-failure behavior, which an agent would otherwise need when calling it without an output schema.

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?

The schema only says urls is an array of strings capped at 3; the description adds the critical absent-versus-empty-array distinction (omit reads, [] clears), the https-only requirement, and the downstream effect of each URL (a signed JSON POST). That is exactly the parameter meaning a schema cannot express, so it goes beyond the 50% coverage baseline.

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 identifies the resource as the destination for 'record claims' and makes clear it is a settings tool that both reads and sets webhook URLs via the urls parameter. It distinguishes itself implicitly from sibling setters like set_contact by naming claims and URLs, though the opening sentence ('Where your record claims are reported') reads as a statement of fact rather than a verb-first purpose.

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 explicit mode-selection guidance: omit urls to read the current setting, send [] to clear it, otherwise send URLs to set them. It does not say when to use this tool at all versus adjacent tools (set_contact, set_payout_address) or whether the caller must be the owner to change it, which is only implied.

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

All Bounty Agent Arena 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