Skip to main content
Glama
tribeunal

Tribeunal Decision-Making Platform

Official
by tribeunal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Search cases

tribeunal_search_cases
Read-onlyIdempotent

Search Tribeunal cases by keyword, status, type, or tags. Returns basic case info (id, title, description); use get_case for full details.

Instructions

Find existing cases by keyword, status, type or tags — a lighter-weight search than get_case: results carry only id, uuid, title, description, visibility and image, not state, sides, votes or deadline, so fetch a hit's full detail with tribeunal_get_case. query matches title or description (case-insensitive substring); status "open" also includes jury_selection. Private cases surface only when you own them, sit on their jury, or are an admin. Paginated newest-first: page (default 1), limit (default 20, max 100). To start a new case instead of searching, use tribeunal_create_case.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number; defaults to 1.
tagsNoCase must carry at least one of these tag names.
typeNocase, advice or poll.
limitNoResults per page; defaults to 20, hard-capped at 100.
queryNoMatches case title or description, case-insensitive substring.
statusNoExact state filter; "open" also includes jury_selection (a case still assembling its jury); "closed" is the closed state alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.0.0
    • changedInput schema / properties / limit / description
      Previous value: -"Number of results per page"New value: +"Results per page; defaults to 20, hard-capped at 100."
    • changedInput schema / properties / page / description
      Previous value: -"Page number for pagination"New value: +"1-based page number; defaults to 1."
    • changedInput schema / properties / query / description
      Previous value: -"Search query for case title or description"New value: +"Matches case title or description, case-insensitive substring."
    • changedInput schema / properties / status / description
      Previous value: -"Case status filter (open = accepting votes, jury_selection = still assembling its jury)"New value: +"Exact state filter; \"open\" also includes jury_selection (a case still assembling its jury); \"closed\" is the closed state alone."
    • changedInput schema / properties / tags / description
      Previous value: -"Filter by tags"New value: +"Case must carry at least one of these tag names."
    • changedInput schema / properties / type / description
      Previous value: -"Case type filter"New value: +"case, advice or poll."
  2. First observedv1.13.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already signal read-only and idempotent behavior, so the description doesn't need to repeat that. However, it adds valuable context: the lightweight result set, the status quirk (open includes jury_selection), and the private case visibility rules, which go beyond the schema and 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 efficient and front-loaded: the first sentence states the core purpose and distinctiveness, followed by key behavioral details and parameter clarifications. Every sentence adds value without redundancy, making it highly concise for the amount of information covered.

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 moderate complexity (6 optional params, no output schema), the description covers all essential aspects: what it returns (and what it doesn't), how parameters behave, pagination, and visibility rules. With no output schema, this description sufficiently informs the agent of the result shape and limitations.

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?

Since schema description coverage is 100%, the baseline is 3. The tool description adds extra meaning by explaining that 'query' matches title or description, 'status open' includes jury_selection, and that results are paginated with specific defaults, which enriches the schema but is not entirely necessary. This marginal addition justifies a 4.

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 searches for existing cases by keyword, status, type, or tags, distinguishing it from get_case and create_case. It specifies the resource (cases) and the search dimensions, making it easy for an agent to know what this tool does.

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 explicitly contrasts with tribeunal_get_case for full detail and tribeunal_create_case for new cases, providing clear when-to-use guidance. It also clarifies scope (private cases) and pagination defaults, so the agent knows exactly when and how to use this tool.

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

Deploy Server

Other Tools