Skip to main content
Glama

get_contest

Read-onlyIdempotent

Fetch the state of an encrypted contest for a specific bounty job: entry count, close time, review deadline, entries (encrypted CIDs), and challenges. Only the poster can decrypt entries.

Instructions

Get the state of an encrypted contest: entry count, close time, review deadline, the entries (encrypted CIDs and who sent them) and any challenges to a rejection. Only the poster holding the private key can read entries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdYesOn-chain job id of the bounty, a decimal integer such as "48". Find ids with list_open_bounties or get_my_bounties.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.2

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful context beyond that: entries are encrypted, viewing them requires the poster's private key, and entries include encrypted CIDs plus sender info. That is real behavioral value.

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?

A single efficient sentence that front-loads the action and then lists the meaningful return contents. No filler, though the trailing access-restriction clause is slightly tacked on.

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 read-only, one-parameter tool with an annotation-declared safety profile, the description covers what state is returned and the key access constraint. Without an output schema the field list is helpful, though it stops short of explaining null/empty states or error conditions.

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 100% and the jobId description already tells the agent the pattern, format, and how to find ids via list_open_bounties/get_my_bounties. The description adds nothing about jobId, so the baseline 3 applies.

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?

States a specific verb and resource ('Get the state of an encrypted contest') and enumerates the returned fields (entry count, close time, review deadline, entries, challenges). This clearly distinguishes it from siblings like get_bounty or decrypt_contest_entry.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes that 'Only the poster holding the private key can read entries,' which implies who should use it, but it doesn't name alternatives or say when not to use it. No sibling routing like get_bounty vs get_contest.

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