Server Quality Checklist

Tool Scores

• get_trading_signalsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description bears full responsibility for behavioral disclosure. It explicitly states the tool never places orders and requires a PRO API key, revealing its read-only nature and authentication needs. This goes beyond basic descriptions but could mention rate limits or other operational details.

  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 concise, using only a few sentences to convey purpose, behavior, prerequisites, and examples. Every sentence adds value without redundancy or fluff. The structure is well-organized, with examples embedded naturally.

  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 (3 parameters, no output schema), the description provides sufficient context: it explains strategy contexts (TWO_BUCKET, SINGLE_BUCKET) and stake suggestion. It does not describe the exact output format, but the examples imply a list of signals. Overall, it is nearly complete for an informational 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 description coverage is 100%, so the baseline is 3. The description does not add further meaning beyond what the schema provides for the parameters; the schema already describes the account enum, bankroll range, and only_with_signals boolean. Thus the parameter semantics are adequately covered by the schema.

  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 retrieves actionable BUY/SELL signals with Kelly-criterion bet sizing for tweet-count markets. It provides concrete examples of strategy contexts (TWO_BUCKET, SINGLE_BUCKET) and explicitly distinguishes it from order-placing tools by stating it never places orders, 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 Guidelines4/5

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

  The description specifies a critical prerequisite (PRO API key) and the failure mode (HTTP 402) if missing. It also clarifies the tool is informational only and not financial advice. While it does not explicitly compare with sibling tools like get_predictions or analyze_portfolio, the unique focus on actionable signals with bet sizing provides implicit guidance.

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

• get_market_metadataA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits: states it is read-only, makes a single HTTPS request to polystrike.xyz, requires no API key, and explains the behavior of deltas during warm-up (null until ready). It also details the sources of the three counters.

  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?

  Description is concise (single paragraph) and front-loaded with the main verb and resource. Every sentence adds value, covering purpose, usage, return fields, and special conditions without redundant phrasing.

  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 no output schema, the description fully explains the return structure (event_id, title, three counters, deltas) and contextualizes deltas as null during warm-up. It also specifies the data source (Polystrike) and the tool's role in the workflow. All relevant aspects are covered.

  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% with a description for the 'account' parameter, including an enum. The description adds context about the tracked accounts (e.g., Elon Musk on X) and explains the return fields, which adds value for understanding output but not for parameter semantics beyond what the schema provides.

  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?

  Description clearly states it gets live metadata for Polymarket tweet-count markets of a tracked account, listing specific return fields (event_id, title, three counters, deltas). It distinguishes from sibling tools by recommending this as the first call to discover markets before using get_predictions or get_trading_signals.

  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?

  Explicitly says to call this first to discover active markets and event IDs, mentions free tier and no API key needed, and notes that deltas are null during warm-up. However, it does not explicitly state when not to use it or exclude alternatives beyond the recommendation.

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

• get_predictionsA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description must fully convey behavioral traits. It states 'Read-only' at the end, clearly indicating the tool does not modify data. It also reveals that the free tier returns a limited view while a PRO key unlocks additional fields. This is good coverage, though it lacks explicit statements about authorization or rate limits.

  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 three sentences long with no wasted words. The main purpose is front-loaded, and every sentence adds value: first sentence defines the core action, second sentence details tier behavior, third sentence provides usage guidance and read-only status.

  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 has only one parameter (fully described), no output schema, and no annotations, the description covers all necessary context: what it does, differences between free and PRO access, and when to use an alternative. It is complete enough for an agent to decide whether to invoke this 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% with a description for the only parameter 'account'. The tool description reiterates the enum values and their meanings ('elon' = Elon Musk on X, etc.), but this largely duplicates the schema. No additional semantic value is provided beyond what the schema already offers, so a baseline score 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?

  Clearly states the tool retrieves 'Monte Carlo forecast data for the active tweet-count markets of a tracked account.' The verb 'get' and specific resource 'Monte Carlo forecast data' make the purpose unmistakable. It also distinguishes itself from the sibling 'get_trading_signals' by contrasting market analysis vs. buy/sell recommendations.

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

  Usage Guidelines5/5

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

  Explicitly says to use this tool 'for market analysis' and for 'concrete buy/sell recommendations use get_trading_signals instead.' It also mentions tier differences (free vs PRO key), giving clear context for when to expect limited vs. full data.

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

• get_rebalancing_recommendationsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, description discloses read-only behavior, authentication requirement (HTTP 402 on failure), and filtering condition. Provides enough behavioral context for safe invocation, though rate limits or idempotency are not mentioned.

  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?

  Four sentences, each concise: purpose, filtering, scope, and auth/behavior. Front-loaded with key action and resource. No redundant or unclear phrasing.

  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?

  For a tool with 3 parameters and no output schema, description explains return type (actions with type and USD amounts), filtering logic, required auth, and read-only nature. Adequately covers all aspects for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

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

  Schema coverage is 100%, but description adds value by explaining bankroll is 'for Kelly position sizing' and threshold as 'minimum adjustment size in USD', providing context beyond the schema descriptions.

  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?

  Description specifies verb 'Get', resource 'rebalancing actions', context 'Polymarket wallet positions in active Elon tweet-count markets', and output type 'ADD_MORE or TRIM with USD amounts'. Distinguishes from siblings like get_trading_signals and analyze_portfolio by focusing on concrete actionable rebalancing.

  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?

  Clearly states when to use: for rebalancing in Elon markets, with threshold filtering. Mentions requirement for PRO API key. However, does not explicitly compare to alternatives like get_trading_signals for when one might prefer signals over actions.

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

• analyze_portfolioA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description must disclose all behavioral traits. It does so by stating the tool is read-only, requires authentication, and its domain (Elon markets only). It also mentions the expected-value assessment, though it could still elaborate on what the analysis includes (e.g., whether it returns numerical values, comparisons, etc.).

  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 extremely concise with two sentences, no filler. It front-loads the primary purpose in the first sentence, ensuring the agent immediately understands the tool's role.

  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 no output schema and simple parameters (2), the description covers the essentials: purpose, prerequisites, read-only nature, and scope. It does not describe the output format, but the context of 'expected-value assessment per position' provides a general idea. Slight gap for full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

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

  The schema already describes 100% of parameters, so the description's marginal value is modest. However, it adds context: 'bankroll' is explained as optional and used for Kelly sizing suggestions, which is not in the schema description. This adds meaningful semantics beyond the bare schema.

  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 verb 'analyze', the specific resource 'Polymarket wallet's open positions across active Elon tweet-count markets', and includes the scope 'Elon markets only'. This distinguishes it from sibling tools like get_predictions or get_trading_signals which have different purposes.

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

  Usage Guidelines5/5

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

  The description provides explicit conditions for use: requires a PRO API key (POLYSTRIKE_API_KEY) and will fail with HTTP 402 without it. It also clarifies that it is read-only and never modifies orders, helping the agent decide when to use this tool versus others that may place trades.

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

• get_crypto_metadataA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses free tier, no API key, and that the data array is empty when no crypto markets are tracked. Good transparency, though could mention any limits or exactly what 'basic market info' includes.

  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?

  Three sentences, each adding value: purpose, free access, empty data behavior and sibling reference. No wasted words, information front-loaded.

  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?

  Tool is simple (no params, no output schema). Description covers purpose, usage context, and empty result behavior adequately. Could be more detailed about output fields, but adequate for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

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

  No parameters in input schema, so baseline of 4 applies. Description adds context about what the tool returns but doesn't need to explain params.

  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 retrieves metadata for crypto prediction markets, specifies what is returned (market IDs and basic info), and distinguishes itself from sibling get_market_metadata. Verb+resource+scope are all explicit.

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

  Usage Guidelines5/5

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

  Provides explicit guidance: 'Free tier, no API key required' and directs users to an alternative tool for main tweet-count markets (get_market_metadata). Clear when to use and when not.

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

• check_healthA
  4.7/5.0
  Behavior4/5

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

  Discloses that it's free tier, no API key required, and returns a timestamp. Lacks details on possible rate limits or response structure, but covers key traits given no annotations.

  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, no unnecessary words, front-loaded with purpose and outcome.

  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?

  For a simple health check tool, the description adequately explains purpose, usage context, and return value without gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

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

  No parameters exist in the schema, so the description appropriately needs no parameter details; baseline 4 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?

  The description clearly states the tool checks API health and returns a status payload with timestamp, distinguishing it from sibling tools like get_predictions or get_market_metadata.

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

  Usage Guidelines5/5

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

  Explicitly advises using this tool to verify connectivity before assuming other tools fail, providing clear when-to-use guidance.

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

• get_recent_tweetsA
  4.8/5.0
  Behavior5/5

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

  The description explicitly states 'Read-only' and details free-tier limits (15 posts, pagination ignored) and PRO key requirements for higher limits and pagination. It also mentions metadata content. No contradictions with missing annotations.

  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 paragraph, starts with the main action, and every sentence adds value. No fluff, appropriate length for the complexity.

  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?

  Despite no output schema, the description explains output includes per-post metadata and its relevance to tweet-count markets. Tier differences are covered. Parameter descriptions in schema complement the description well. Complete for a read-only list tool.

  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?

  Schema coverage is 100%, but the description adds significant context: explains default limit 15, free-tier cap, PRO key for values >15, offset pagination, and clarifies account enum values. This goes well beyond the schema.

  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 retrieves the most recent captured posts for a tracked account, newest first, with per-post metadata. It distinguishes from siblings which focus on predictions, markets, and other analytical tasks.

  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 usage intent: 'understand posting pace and verify what is being counted.' It also explains tier differences (free vs. PRO) but does not explicitly mention when not to use the tool or name alternatives.

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