Skip to main content
Glama
Beever-AI

Beever Atlas

Official

find_decisions

Retrieve structured decision records from a channel, including rationale and rejected alternatives. Understand what the team decided and why.

Instructions

List the DECISIONS recorded in one channel, each with its rationale and rejected alternatives. Call it to answer "what did the team decide and why" when you want the structured decision record, not free-text facts. Returns a bare LIST and collapses missing-auth, access-denied, and internal errors into an EMPTY LIST — so [] means either no decisions OR no access; it never returns a structured error object and never raises.

Disambiguation among the decision tools: use find_decisions for the current decision RECORDS in one channel (with rationale + alternatives_rejected). Use trace_decision_history to follow how one decision SUPERSEDED earlier ones over time (a graph timeline). Prefer find_decisions over find_facts(fact_type='decision') because only this tool enriches each result with rationale and alternatives.

Prerequisites: a channel_id from list_channels.

Returns (instant, read-only): a LIST (not a dict) of decisions sorted by decided_at descending, each {fact_id, decision (first sentence), decided_by, decided_at (YYYY-MM-DD), rationale (null if not yet extracted), alternatives_rejected, page_slug (empty if no host page yet)}. No side effects.

Error handling: on missing auth, access denial, or internal error this tool returns an EMPTY LIST [] rather than an error object (it never raises). An empty list therefore means either no decisions or no access — confirm access with list_channels if unexpected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channel_idYesChannel id. Get it from list_channels (e.g. 'ch-eng'). Required.
sinceNoOptional ISO-8601 date prefix (e.g. '2026-04-01'); keeps only decisions on or after this date. Omit for all dates. Default null.
authorNoOptional exact-match author name (e.g. 'Alice Chen'). Omit for any author. Default null.
limitNoMax decisions to return, 1-100 (out-of-range values are clamped). Default 50.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations given, so description fully covers behavior: read-only, no side effects, error handling (returns empty list on errors, never raises), return format with field descriptions.

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?

Well-structured with clear paragraphs (purpose, disambiguation, prerequisites, return format, error handling). Front-loaded. Slightly long but fully justified by tool 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?

Given 4 parameters, output schema, and 27 siblings, description thoroughly covers return shape, error behavior, prerequisites, and comparison with alternatives.

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%; description adds minimal extra meaning beyond schema (reinforces types and defaults). 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?

Description clearly states verb and resource ('list the DECISIONS recorded in one channel') and differentiates from siblings by naming trace_decision_history and find_facts, including specific disambiguation.

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 when-to-use ('answer what did the team decide and why'), when-not-to-use (via sibling disambiguation), and prerequisite ('channel_id from list_channels').

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Beever-AI/beever-atlas'

If you have feedback or need assistance with the MCP directory API, please join our Discord server