Server Quality Checklist

Tool Scores

• get_marketA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It lists the returned fields (question, condition_id, token ids, etc.), which is helpful, but it does not explicitly state the operation is read-only, nor does it describe error behavior, response format, or side effects. Some behavioral detail is present, but it lacks completeness.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, dense sentence that effectively communicates the tool's purpose and output fields. It is front-loaded with the main action and resource, and every word contributes value.

  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 tool with one parameter and no output schema, the description provides a thorough enumeration of the resolved fields, giving the agent a clear expectation of the result. It could be improved by noting potential errors (like invalid or unknown slugs) or the format of the response, but the essential context is covered well.

  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?

  The schema already provides 100% coverage for the single parameter, describing it as 'Full polymarket.com market URL, or the bare market slug.' The tool description essentially repeats this without adding new semantics like examples, format constraints, or edge cases. Baseline of 3 applies because the schema does the heavy lifting.

  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?

  The description clearly states the tool's action ('Resolve') and resource ('polymarket.com market URL or bare slug'), and enumerates the specific output fields. This makes it unambiguous and distinct from sibling tools like search_markets or get_order_book.

  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 implies the tool is used when you already have a market URL or slug and need resolved metadata. However, it does not explicitly state when to prefer it over alternatives or provide any exclusion criteria. No alternative references are mentioned.

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

• get_price_historyA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. It discloses that the tool returns a series plus a summary, which gives some insight into the output, but it does not explicitly mention read-only behavior, rate limits, or other potential side effects. The word 'get' implies a safe read operation, but the description alone does not fully cover transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately conveys the core purpose and output structure. No wasted words.

  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?

  The tool is relatively simple, with schema covering all parameters. The description provides a high-level summary of the return value (series + summary), which is sufficient for an agent to understand the tool's function. However, without an output schema, a bit more detail on the return format could be helpful, but it is not critical for this simple tool.

  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%, so the baseline is 3. The description does not add significant detail beyond the schema; it mentions 'one outcome token' which maps to token_id, but does not enrich understanding of fidelity or interval.

  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?

  The description clearly identifies the tool as retrieving a historical price series for a single outcome token, including a summary of key statistics. This distinguishes it from sibling tools like get_quote (current price) and get_order_book (order book data).

  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 implies how to use the tool (for historical price data) but does not explicitly state when to choose it over alternatives or provide any exclusion criteria. The context is clear but there is no explicit guidance.

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

• search_marketsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses key behavioral details: it uses the site's real search backend, returns a flat list (flattening parent events), and includes specific fields (best bid/ask, spread, token IDs). It also warns about the no-op endpoint. Missing details like auth/rate limits are minor for a read-only search tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose. The parenthetical about the no-op endpoint is useful and the output details are compact. Every sentence earns its place; no filler.

  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?

  Given the tool's moderate complexity, no output schema, and absence of annotations, the description is fairly complete: it explains what the tool does, why it is reliable (real backend), and what the return shape looks like. It could mention ordering or pagination, but the limit parameter partially covers that. It adequately supports selection and invocation.

  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?

  The schema already covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, mostly re-emphasizing keyword search. Limit and include_closed are not elaborated, but the schema handles them adequately.

  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?

  The description uses a specific verb ('Search') and resource ('Polymarket markets'), clearly distinguishing this from sibling tools that retrieve specific market data or order books. It also states the output ('flat list of markets with best bid/ask, spread and outcome/token ids'), making the purpose unambiguous.

  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 implies usage for keyword-based market discovery but does not explicitly state when to prefer this tool over alternatives like get_market or get_quote. It does mention a useful distinction (Gamma's own /markets?search= is a no-op) that guides usage, but no explicit when/when-not guidance.

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

• get_order_bookA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It uses the verb 'Fetch', indicating a read-only operation, and details the output structure (levels, cumulative size, notional). It does not mention error conditions or permission requirements, but for a simple fetch this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences. The first front-loads the core behavior and output details; the second adds minor context about centrality. Both are concise and non-redundant. No unnecessary flourish.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple two-parameter tool with no output schema or annotations, the description covers the essential behavior: return contents and the token scoping. Combined with the schema, this gives sufficient context 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it mentions 'top N levels' which aligns with the depth parameter, and 'one outcome token' echoes the token_id description. No additional semantic value is provided beyond what the schema already states.

  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?

  The description clearly states the tool fetches a live order book for one outcome token, enumerating specific return elements (best bid/ask, mid, spread, top N levels). This distinguishes it from siblings like get_quote or get_price_history, which are not about order book depth.

  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?

  The description provides clear context that this is the order book tool and even calls itself 'the central tool of this server', implying it is the primary choice for order book data. It does not explicitly name alternatives or exclusions, but the context is sufficient for a typical use case.

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

• get_quoteA
  4.3/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. It discloses the tool is 'cheap' and performs 'one book fetch', indicating performance characteristics, and specifies exactly which fields are returned (best_bid, best_ask, mid, spread) and that there is no depth. It lacks details on error handling or auth, but for a simple quote tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficiently structured sentence that front-loads the purpose ('Cheap price check'), then specifies the token scope and available fields. Every phrase earns its place with no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (1 parameter, no output schema), the description covers what it does, what it returns, and how it works ('one book fetch'). It also hints at its limitation (no depth), making it sufficient for tool selection even with sibling tools present.

  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?

  The schema already fully describes token_id as 'CLOB token id for one specific outcome.' The description reinforces this with 'one outcome token' but adds no new syntax or format details. With 100% schema coverage, the baseline of 3 is appropriate.

  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?

  The description clearly states the tool performs a 'cheap price check for one outcome token' with specific fields (best_bid, best_ask, mid, spread), distinguishing it from siblings like get_order_book which would provide depth.

  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 provides clear context by saying 'no depth' and 'only', implying it's for quick checks when full order book depth is unnecessary. However, it does not explicitly name alternatives like get_order_book, so it offers a clear context with an implicit exclusion rather than explicit alternatives.

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