BountyVerdict Agent Decision Tools
Server Details
Read-only GitHub bounty, agent harness, Actions failure, flake, and MCP tool-drift decisions.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Mimirs402/bountyverdict
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose, and descriptions explicitly reference complementary tools (e.g., classify_github_actions_flake and diagnose_github_actions_run). Agents can easily differentiate.
All tool names follow a consistent verb_noun pattern using snake_case, with verbs like audit, check, classify, diagnose, rank. No mixing of conventions.
6 tools is well-scoped for the domain of bounty verdict and MCP decision support. Each tool covers a necessary function without excess.
The surface covers all core operations: auditing, single/multi-bounty checking, drift detection, flake classification, and run diagnosis. No obvious gaps for the stated read-only analytical purpose.
Available Tools
6 toolsaudit_agent_harnessAudit coding-agent repository instructionsARead-onlyIdempotentInspect
First unsigned call with real input cannot charge; it returns a free $0 selection preview and exact quote. Only an authorized signed retry costs $0.03 USDC on Base. Use before assigning a coding agent to a public GitHub repository to audit its instruction stack at an immutable commit. This does not diagnose CI. Read-only; never invent arguments. Sample: https://bountyverdict-agent-production.mimirslab.workers.dev/api/harness/sample.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | Canonical public GitHub repository URL, for example https://github.com/owner/repository. No subpath, query string, fragment, or non-GitHub host. |
Output Schema
| Name | Required | Description |
|---|---|---|
| score | Yes | |
| product | Yes | |
| summary | Yes | |
| verdict | Yes | |
| version | Yes | |
| findings | Yes | |
| checked_at | Yes | |
| repository | Yes | |
| service_reuse | Yes | |
| recommendations | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive, but description adds crucial details: the free preview with exact quote, the $0.03 USDC cost for a signed retry, and a sample URL. It also includes a warning 'never invent arguments'. These go beyond annotations.
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 concise with no superfluous information. Key points are front-loaded: cost model, use case, limitations, and sample link. Every sentence adds value.
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?
Given the single parameter, rich annotations, and output schema, the description covers all necessary aspects: purpose, usage boundaries, behavioral traits, and parameter constraints. It is fully sufficient for an agent to select and invoke the tool correctly.
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 coverage is 100% with comprehensive description for repo_url parameter. The description does not add new semantics beyond what is in the schema, particularly regarding the immutable commit aspect, but the schema already covers format and constraints adequately.
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 title 'Audit coding-agent repository instructions' and description clearly state the tool audits the instruction stack of a public GitHub repository. It distinguishes from sibling tools like diagnose_github_actions_run and classify_github_actions_flake by specifying it does not diagnose CI.
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?
Explicitly states when to use ('before assigning a coding agent to a public GitHub repository') and what it does not do ('This does not diagnose CI'). Also provides exact cost and charging model, giving clear context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_github_bountyCheck GitHub bounty claimability riskARead-onlyIdempotentInspect
First unsigned call with real input cannot charge; it returns a free $0 selection preview and exact quote. Only an authorized signed retry costs $0.05 USDC on Base. Use before coding one public GitHub bounty issue to get an evidence-linked AVOID, CAUTION, or VIABLE claimability verdict. For 2-10 candidates use rank_github_bounties. Read-only; never invent arguments. Sample: https://bountyverdict-agent-production.mimirslab.workers.dev/api/sample.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_url | Yes | Canonical public GitHub issue URL, for example https://github.com/owner/repository/issues/123. No query string, fragment, pull request, or non-GitHub host. |
Output Schema
| Name | Required | Description |
|---|---|---|
| issue | Yes | |
| score | Yes | |
| product | Yes | |
| signals | Yes | |
| summary | Yes | |
| verdict | Yes | |
| version | Yes | |
| checked_at | Yes | |
| service_reuse | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: first unsigned call is free and returns a preview/quote, only signed retry costs $0.05. Aligns with readOnlyHint and idempotentHint. No contradictions.
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?
Multiple sentences covering purpose, pricing, alternatives, and constraints. Pricing info is front-loaded but not critical; overall concise for the information provided.
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?
Covers key aspects: safety (read-only), cost model, result types, and sample link. Given one parameter and existing output schema, description is sufficiently complete.
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 coverage is 100% and description reinforces that issue_url must be a public GitHub bounty issue (not just any issue), adding context beyond the schema's canonical URL format.
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?
Description clearly states the tool checks claimability risk for a single GitHub bounty issue, returning AVOID, CAUTION, or VIABLE verdict. However, the mention of 'selection preview' and 'exact quote' causes slight confusion about the primary output.
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?
Explicitly says 'Use before coding one public GitHub bounty issue' and directs users to rank_github_bounties for 2-10 candidates. Also advises 'never invent arguments' and notes the read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_mcp_tool_driftCheck whether an MCP tools update is breakingARead-onlyIdempotentInspect
First unsigned call with real input cannot charge; it returns a free $0 selection preview and exact quote. Only an authorized signed retry costs $0.02 USDC on Base. Use before accepting an MCP tools/list update to compare complete baseline and current snapshots for breaking schema or safety-hint changes. It never fetches or invokes tools. Read-only; never invent or truncate snapshot arguments. Workflow: https://mimirs402.github.io/bountyverdict/skills/check-mcp-tool-drift/SKILL.md.
| Name | Required | Description | Default |
|---|---|---|---|
| current | Yes | Complete candidate tools/list snapshot. | |
| subject | Yes | Caller-chosen identity for the MCP server being compared; ownership is not verified. | |
| baseline | Yes | Complete previously accepted tools/list snapshot. | |
| contract_version | Yes | ||
| annotation_source_trust | Yes | Whether the caller recognizes the annotation source. Annotations never become runtime-behavior proof. |
Output Schema
| Name | Required | Description |
|---|---|---|
| trust | Yes | |
| action | Yes | |
| hashes | Yes | |
| service | Yes | |
| summary | Yes | |
| verdict | Yes | |
| findings | Yes | |
| service_reuse | Yes | |
| ruleset_version | Yes | |
| contract_version | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds critical behavioral context beyond annotations: read-only, never fetches or invokes tools, first call is free preview, only signed retry costs. No contradiction with annotations.
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?
Single paragraph that is concise yet informative, front-loading the core purpose and including a useful workflow link. No redundancy.
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 tool with 5 required parameters, high schema coverage, and output schema, the description fully explains the operation, use case, and constraints. The workflow link provides further detail.
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 coverage is 80%, and description adds value by explaining the free preview and signed retry workflow, plus the comparison intent. The description supplements the schema well.
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?
Clearly defines the tool as comparing two snapshots of an MCP tools/list to detect breaking changes. Distinguishes from unrelated sibling tools about GitHub 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?
Explicitly states when to use: before accepting a tools/list update. Does not state when not to use, but sibling tools are unrelated, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
classify_github_actions_flakeDecide whether to retry failed GitHub ActionsARead-onlyIdempotentInspect
First unsigned call with real input cannot charge; it returns a free $0 selection preview and exact quote. Only an authorized signed retry costs $0.07 USDC on Base. Use to decide whether one completed failed GitHub Actions run should be retried once or fixed, using attempt and historical fingerprints. For root cause use diagnose_github_actions_run. Read-only; never invent arguments. Sample: https://bountyverdict-agent-production.mimirslab.workers.dev/api/flake/sample.
| Name | Required | Description | Default |
|---|---|---|---|
| attempt | No | Optional exact workflow run attempt number, starting at 1. Omit to use the run URL's latest available completed attempt. | |
| run_url | Yes | Canonical public GitHub Actions run URL, for example https://github.com/owner/repository/actions/runs/123456. No job URL, query string, fragment, or non-GitHub host. |
Output Schema
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| product | Yes | |
| summary | Yes | |
| verdict | Yes | |
| version | Yes | |
| decision | Yes | |
| checked_at | Yes | |
| service_reuse | Yes | |
| failure_signatures | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds 'Read-only; never invent arguments' and discloses cost structure (free preview vs $0.07 signed retry), which provides beyond-annotation context. No contradictions.
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?
Three sentences plus a sample URL, no wasted words. Front-loads the key cost and free preview detail, states purpose, and points to alternative. Ideal conciseness for an agent.
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?
Given the tool's complexity (flake classification, cost, output schema), the description covers decision context, prerequisites (run URL), alternatives, and behavioral constraints. Annotations and schema cover safety and parameters. The sample URL aids understanding. Complete for agent use.
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 coverage is 100% with descriptions for both parameters. The description mentions 'using attempt and historical fingerprints' but does not add significant new meaning to parameter details beyond what the schema provides. Context about the free preview and decision logic is not parameter-specific.
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 decides whether to retry a failed GitHub Actions run, contrasting with 'diagnose_github_actions_run' for root cause analysis. The verb 'classify' and resource 'GitHub Actions flake' are specific and distinguish it from siblings.
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?
Explicitly says when to use: 'decide whether one completed failed GitHub Actions run should be retried once or fixed'. Also provides when not to use: 'For root cause use diagnose_github_actions_run'. Mentions pricing and sample URL for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diagnose_github_actions_runFind why a GitHub Actions run failedARead-onlyIdempotentInspect
First unsigned call with real input cannot charge; it returns a free $0 selection preview and exact quote. Only an authorized signed retry costs $0.04 USDC on Base. Use to find why one public GitHub Actions run failed and get redacted evidence plus concrete next actions. For retry-once versus fix use classify_github_actions_flake. Read-only; never invent arguments. Sample: https://bountyverdict-agent-production.mimirslab.workers.dev/api/run/sample.
| Name | Required | Description | Default |
|---|---|---|---|
| run_url | Yes | Canonical public GitHub Actions run URL, for example https://github.com/owner/repository/actions/runs/123456. No job URL, query string, fragment, or non-GitHub host. |
Output Schema
| Name | Required | Description |
|---|---|---|
| run | Yes | |
| product | Yes | |
| summary | Yes | |
| verdict | Yes | |
| version | Yes | |
| diagnosis | Yes | |
| checked_at | Yes | |
| next_actions | Yes | |
| retryability | Yes | |
| service_reuse | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: the free preview for unsigned calls, the $0.04 fee for authorized signed retry, and that output includes 'redacted evidence plus concrete next actions'. No contradiction with annotations.
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 informative but slightly verbose, front-loading pricing model which could be secondary. However, it efficiently covers all necessary dimensions: purpose, alternatives, constraints, and sample. Minor redundancy but overall well-structured.
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?
Given the tool's complexity, rich annotations, and presence of output schema (not shown but mentioned), the description provides sufficient context: it explains output content, sample URL, pricing model, and constraints. No gaps for an effective agent invocation.
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 100%, with run_url fully documented via pattern and description. The description does not add substantial parameter-level details beyond the schema, though it implies the parameter is the run URL. Baseline of 3 is appropriate.
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: 'Use to find why one public GitHub Actions run failed and get redacted evidence plus concrete next actions.' It uses specific verb ('find') and resource (GitHub Actions run), and distinguishes from sibling tool by explicitly mentioning when to use classify_github_actions_flake instead.
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 explicit usage guidance, including when not to use this tool ('For retry-once versus fix use classify_github_actions_flake') and behavioral constraints ('Read-only; never invent arguments'). It also explains the pricing model for first call vs. retry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_github_bountiesChoose the best GitHub bountyARead-onlyIdempotentInspect
First unsigned call with real input cannot charge; it returns a free $0 selection preview and exact quote. Only an authorized signed retry costs $0.40 USDC on Base. Use to choose the best candidate from 2-10 public GitHub bounty issues with full verdicts, evidence, ranking, and partial failures. For one issue use check_github_bounty. Read-only; never invent arguments. Sample: https://bountyverdict-agent-production.mimirslab.workers.dev/api/portfolio/sample.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_urls | Yes | Two to ten distinct canonical public GitHub issue URLs. Duplicate issue URLs are rejected before payment. |
Output Schema
| Name | Required | Description |
|---|---|---|
| counts | Yes | |
| ranked | Yes | |
| product | Yes | |
| version | Yes | |
| failures | Yes | |
| checked_at | Yes | |
| service_reuse | Yes | |
| best_candidate | Yes | |
| recommendation | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: the free preview on first unsigned call, the $0.40 charge only on authorized signed retry, and the instruction to never invent arguments. No contradictions with annotations.
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 very concise: three sentences covering cost model, usage distinction, input constraints, and a sample URL. Every sentence adds value and avoids wordiness.
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?
The description covers input constraints, cost model, sibling distinction, and read-only behavior. While it mentions 'full verdicts, evidence, ranking' as output, the presence of an output schema makes detailed output description unnecessary. Overall, it is complete for a tool with this complexity.
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 coverage is 100% for the single parameter issue_urls, with pattern and description provided. The description adds meaning by stating that duplicate URLs are rejected before payment and reaffirms the 2-10 range, which is also in the schema.
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: to choose the best candidate from 2-10 GitHub bounty issues with ranking and evidence. It also explicitly distinguishes from the sibling tool check_github_bounty for single issues.
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 explicit when-to-use and when-not-to-use guidance: it states the free preview for unsigned calls, the cost for signed retries, and that for a single issue one should use check_github_bounty. It also mentions the required count range (2-10).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!