source_reportReport that a maintained source appears broken or stale. Reports are monitoring signals and do not create bounties.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | ||
| source_id | Yes | Public source id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by stating reports are monitoring signals and do not create bounties, but it does not disclose other important behaviors such as whether the report is reversible, what happens after submission, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose and followed by a valuable clarification. Every sentence earns its place and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core purpose and a key behavioral nuance. However, it lacks guidance on composing the 'reason' parameter and does not describe the expected outcome or side effects, leaving some gaps for an agent to act reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only source_id has a description). The tool description does not mention parameters at all, so it fails to compensate for the gap left by the undocumented 'reason' parameter. The agent is left to infer what 'reason' should contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reporting that a maintained source appears broken or stale. It uses a specific verb (Report) and resource (source problem), and distinguishes itself from related tools like request_source or bounty_post by clarifying that reports are monitoring signals and do not create bounties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a maintained source is broken or stale. It also implicitly excludes bounty creation by stating reports do not create bounties. However, it does not explicitly name alternative tools or provide a when-not-to-use list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, but a few could be confused: 'needs_intake' and 'request_source' both accept natural language requests, and 'bounty_self_gate' vs 'check_received_work' both involve checking work against criteria. Overall, detailed descriptions help differentiate them.
Naming is inconsistent: some tools use verb_noun ('get_source', 'list_sources') while others use noun_verb ('bounty_get', 'capability_call'). There are also oddities like 'agent_register' and 'bounty_counter'. The mixed conventions are still readable but not predictable.
With 26 tools, the server exceeds the recommended 3-15 range and feels heavy. Many tools are specific, but the sheer number may overwhelm agents, and some could potentially be consolidated (e.g., subscription tools).
The domain is broad (bounties, capabilities, sources) and most core workflows are covered, but there are notable gaps: no explicit tool to accept a bounty submission, no unsubscribe or management for subscriptions, and no way to remove or deprecate a capability. These missing lifecycle operations could cause agent workarounds.