Beever Atlas

Official

by Beever-AI

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with descriptions that explicitly contrast similar tools (e.g., find_facts vs. search_channel_facts vs. ask_channel, or read_wiki_page vs. read_wiki_module). Overlapping functionality is minimal and well-documented.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_channels, find_facts, read_provenance). There is no mixing of naming conventions, making the set predictable.
Tool Count4/5
28 tools is on the higher end but appropriate for the server's complex domain (knowledge management with multiple search modes, wiki operations, decision tracking, etc.). The count feels slightly heavy but each tool earns its place.
Completeness5/5
The tool set covers the full lifecycle: channel discovery, multiple retrieval methods, wiki management (both legacy and redesigned), decision history, tensions, experts, media search, relationship graphs, job tracking, and sync. Obvious gaps (e.g., fact deletion) are intentionally omitted as read-only. The deprecated tool is a minor blemish.
Average 4.8/5 across 28 of 28 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 32 of 34 community issues answered or closed in the last 6 months
- 92 commits in the last 12 weeks
- Last stable release on May 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the burden. It discloses the tool is instant, read-only, has no side effects, returns empty arrays when backend is unavailable (always safe), and lists specific error modes. This is comprehensive behavioral coverage.
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?
The description is well-structured into clear sections (purpose, disambiguation, usage, returns, error modes) and all sentences are informative. While slightly lengthy, it earns its length with valuable detail. A minor reduction could improve conciseness.
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 complexity (graph output) and lack of annotations, the description provides thorough context including output format (Cytoscape-format), behavior on unavailable backend, and error scenarios. Output schema exists, but the description still adds valuable detail about edge/node structure.
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?
Only one parameter (channel_id) with 100% schema description coverage. The description adds minor context (mentioning source list_channels) but does not significantly enhance understanding beyond the schema. Baseline 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 returns a wiki page-link graph as a node/edge map. It distinguishes from the knowledge graph (use search_relationships) and other wiki tools like read_wiki_page. The verb 'return' and resource 'wiki page-link graph' are specific and unambiguous.
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 describes when to use the tool (visualizing/navigating wiki structure, finding clusters) and when not to (reading page content, querying entity relationships, with alternatives named). It also lists 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Returns (instant, read-only): ... No side effects.' and describes error modes as dicts with examples. It also clarifies that content can be null if the page hasn't been generated, which is crucial behavioral context. Since no annotations are provided, the description fully compensates.
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?
The description is well-structured with clear sections (disambiguation, when to use/not use, prerequisites, return format, error modes). While slightly verbose, each sentence adds value and the structure aids comprehension.
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 lacking annotations and having a complex context with sibling tools, the description is complete. It covers purpose, usage boundaries, return format (with output schema referenced), error modes, and prerequisites. The null content behavior is explicitly documented, leaving no significant gaps.
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 input schema already describes both parameters with thorough descriptions (channel_id required, page_type enum with defaults). The description adds minimal additional meaning beyond restating the enum values and default. With 100% schema coverage, a 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?
The description clearly states the verb 'Fetch' and specifies the resource: 'one pre-compiled wiki page from the LEGACY fixed-page set (overview, faq, decisions, people, glossary, activity, topics)'. It explicitly lists the seven fixed page types, distinguishing this tool from sibling tools like read_wiki_page which handles slug-keyed wiki pages.
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 guidance: use for 'a quick structured summary of a known aspect of a channel without running the QA pipeline', and not to use when needing a specific answer (use ask_channel) or non-fixed wiki topic (use read_wiki_page). It also mentions the prerequisite channel_id from list_channels, and notes that content is null if page not generated (run refresh_wiki first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior beyond annotations (none provided): read-only operation ('writes nothing'), potential long runtime when run_coherence_check=true, and error modes. No contradictions.
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 front-loaded purpose, usage, params, return, and errors. Each section serves a purpose, though slightly lengthy. Minor redundancy with schema descriptions.
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?
Outlines return format with example structure, lists error modes, and prerequisites. Sufficient for an agent to understand what to expect and how to handle outcomes.
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 rephrases parameter info but adds little new meaning. For run_coherence_check, the description echoes the schema's cost/latency note. 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?
Clearly states 'Audit a channel's wiki for health problems' with specific verb and resource. Differentiates from siblings by explicitly mentioning not to use for routine reading (use read_wiki_page/list_wiki_pages).
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 (validating wiki quality, diagnosing wrong answers) and when-not-to-use (routine reading, heavier linting). Includes prerequisite (channel_id) and best practice (run_coherence_check=false to avoid cost).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it's instant, read-only, no side effects, and specifies the return format (including example) and error modes. This covers all necessary behavioral traits for safe invocation.
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?
The description is well-structured with clear sections (purpose, when to use, prerequisites, returns, errors). It is comprehensive but slightly lengthy; however, every sentence adds value, so it earns a 4.
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 output schema exists and the description includes a return format example, error modes, and prerequisites, the description is fully complete. It provides all necessary context for an agent to use the tool correctly without missing information.
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 baseline is 3. The description does not add significant meaning beyond what the schema already provides for each parameter. It repeats the prerequisite context for channel_id but does not enhance parameter understanding further.
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 function: 'Find messages that SHARED a file, image, PDF, or link in one channel.' It distinguishes itself from sibling tools by specifying what it does (media attachment search) versus general knowledge search, and uses specific verbs and resources.
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 provides 'When to use' (locating shared files/images/links) and 'When NOT to use' (general fact/knowledge search, with named alternatives like search_channel_facts or ask_channel). Also mentions 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, no side effects, return format, error modes, prerequisites, and clamping behavior. No annotations provided so description carries full burden.
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?
Well-structured with clear sections (When to use, When NOT to use, Prerequisites, Returns, Error modes). Front-loaded with main purpose, no wasted words.
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?
Complete for a read-only listing tool: explains return format, errors, prerequisites, parameter constraints. Output schema exists, so return description is sufficient.
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 mentions defaults and clamping, but schema already provides similar detail. Baseline 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 'List the most RECENT facts from one channel' with specific verb and resource, and distinguishes from siblings in usage guidelines.
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?
Explicit when-to-use examples ('what's been discussed...') and when-not-to-use with alternative tool names (search_channel_facts, ask_channel).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavioral traits: read-only, instant, returns a list (not dict), no side effects. It also explains error handling (returns empty list on errors) and contextualizes empty results as normal for most channels.
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 well-structured with clear sections for purpose, usage, prerequisites, notes, return format, and error handling. Every sentence adds value without redundancy.
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 presence of an output schema and full schema coverage, the description still adds value by detailing return structure, error behavior, and normal empty results. It is complete for a tool of this complexity.
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 baseline is 3. The description does not add new meaning beyond what the schema already provides for the parameters. The prerequisite mention is usage guidance, not parameter semantics.
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 lists unresolved tensions in a channel, with specific verb and resource. It distinguishes from sibling tools like find_decisions and find_facts, providing clear differentiation.
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 provides when to use (surfacing open conflicts) and when not to use (settled decisions, fact lookup). Also notes prerequisite channel_id from list_channels, offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes return format, instant and read-only nature, no side effects, and details error modes including privacy-preserving behavior for cross-tenant access. Exceptionally transparent.
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?
Well-structured with clear sections for purpose, when-to-use, prerequisites, return format, and errors. Every sentence is informative with no redundancy.
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 low complexity, description provides full coverage: purpose, usage guidelines, prerequisites, return format with details, error modes, and behavioral traits. Very complete.
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?
Single parameter fact_id is well-described in schema. Description adds value by specifying that fact_id comes from other tools' fact_id field and listing example tools, which aids correct invocation.
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 'Trace ONE fact back to the original chat message it was extracted from' with a specific verb and resource. It distinguishes from siblings like find_facts and trace_decision_history by focusing on provenance of a single fact.
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 states when to use: 'confirming a fact's source, building a citation, or auditing provenance' and lists prerequisites (fact_id from specific tools). Missing explicit when-not, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully carries the burden. It discloses read-only nature, no side effects, return structure, error modes (authentication, access denial), and that internal failures return empty facts rather than erroring. Complete 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 well-organized into distinct sections (purpose, when/not to use, prerequisites, returns, error modes). Every sentence adds value; no redundancy or fluff. Ideal length for an actionable tool description.
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 output schema exists, the description correctly limits return value explanation to a sample structure. Covers prerequisites, error handling, and behavioral nuances. Completely addresses the tool's complexity.
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 baseline is 3. The description adds minimal parameter semantics beyond the schema (e.g., restates channel_id from list_channels). No additional constraints or format details. Adequate but not exceptional.
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 explicitly states the tool finds 'SPECIFIC facts in ONE channel by hybrid (BM25 + vector) search' and returns raw ranked rows. It clearly distinguishes from siblings like ask_channel and search_memory by scope and output type.
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 clear when-to-use ('targeted lookup of facts in a known channel') and when-not-to-use for synthesized answers (ask_channel), unknown channels (search_memory), or substring match (find_facts). Explicitly lists alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it returns a bare LIST, collapses errors into an empty list, is read-only with no side effects, sorts by importance then recency, and details the return fields. It also explains the implication of empty results.
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?
The description is well-structured with logical sections, front-loading the core function. It is thorough but slightly verbose; however, every sentence adds value, earning a 4.
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 output schema is implicit (description includes return fields), and the input schema is fully covered, the description provides complete behavioral context: sorting, error handling, return format, and prerequisites. It leaves no 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?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by clarifying query as a literal substring, listing fact_type options, explaining limit clamping, and providing examples. This 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 finds facts by literal substring matching in a channel, and distinguishes it from semantic search (search_channel_facts), synthesized answers (ask_channel), and decision lookup (find_decisions). It is specific about the deterministic, case-insensitive behavior.
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 tells when to use (exact-keyword scans) and when not to (semantic queries, use search_channel_facts), and lists prerequisites (channel_id from list_channels). It also explains error handling (empty list on no match or access issues).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details behavior: read-only, instant, no side effects. Explains return format with all fields, status enumeration, progress range, and error modes with exact error strings. Discloses information disclosure design (job_not_found hides cross-principal info).
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 sections (WHEN TO USE, PREREQUISITES, LATENCY, RETURNS, ERROR MODES). Uses formatting for emphasis. Slightly long but every sentence earns its place. Could merge some lines for brevity, but overall effective.
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?
Output schema exists, but description still fully documents return fields, status values, and error cases. Covers polling guidance, prerequisites, and behavioral nuances. No gaps remain for a complex polling tool.
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% and schema alone describes job_id as required string. The description adds context: its origin from trigger_sync/refresh_wiki and an example prefix 'job_', which helps the agent understand where to get the value. Value-add beyond schema justifies 4 rather than baseline 3.
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 it checks background job progress/result, explicitly names trigger_sync and refresh_wiki as the tools that produce job_ids, distinguishing it from sibling tools like ask_channel or find_decisions.
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: poll after trigger_sync/refresh_wiki. Includes polling cadence (2-3s, back off), prerequisites (valid job_id, owned by caller), and states what it does NOT do (answers channel questions). Even mentions an equivalent alternative (reading atlas resource).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: ownership-filtered results, read-only instant latency, error modes (authentication_missing), and important caveats about selected_channel_count and last_synced_at to prevent misinterpretation.
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 sections: purpose, usage, output fields, caveats, errors. All sentences add value, though could be slightly more compact.
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?
Thorough coverage: return format, field descriptions, caveats, error handling, and usage flow. No gaps given the tool simplicity (no params, explicit output schema described).
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, so the description adds no parameter info. Baseline 4 as per calibration for 0-param tools.
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 it lists platform connections owned by the principal, with specific verb ('list') and resource ('connections'). It distinguishes itself from sibling tools like 'whoami' and 'list_channels' by specifying when to use each.
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 states when to use (need metadata beyond id) and when not (use whoami for just ids). Provides next step after picking a connection (call list_channels). Gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers: read-only, no side effects, returns full WikiPage document with fields (content_md, kind, cross_links, etc.), excludes hidden pages unless scoped, and lists four error modes. Very transparent.
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 sections: purpose, disambiguation, prerequisites, returns, error modes. Front-loaded with main action. Slightly lengthy but every sentence adds value.
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 output schema exists, description still provides key return fields, prerequisites, error modes, and ties with sibling tools. Covers all needed context for reliable invocation.
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% with clear descriptions, so baseline is 3. Description adds value by linking parameters to prerequisites (channel_id from list_channels, slug from list_wiki_pages) and specifying default for target_lang.
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 it reads a full wiki page by slug from the redesigned slug-keyed wiki. It distinguishes from siblings like get_wiki_page (legacy fixed pages) and read_wiki_module/section (partial reads).
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 instructs to call after list_wiki_pages, before read_wiki_module/section if full page needed. Disambiguates from get_wiki_page and lists prerequisites (channel_id, slug).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: asynchronous (returns job envelope), write side effects, idempotency (returns existing job if queued/running), latency (~5s), error modes (authentication_missing, invalid_parameter, channel_access_denied, cooldown_active, service_unavailable, internal_error), and prerequisite access requirements.
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?
The description is lengthy but well-structured with labeled sections (WHEN TO USE, PREREQUISITES, LATENCY, etc.). Every sentence adds value; no redundancy. Could be slightly more concise, but the structure aids readability.
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 complexity (3 parameters, asynchronous behavior, idempotency, multiple error modes) and the presence of an output schema (described inline), the description covers all necessary dimensions: purpose, usage, parameters, behavior, errors, and return shape.
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%, so baseline is 3. The description adds significant context: channel_id is required, sync_type with practical advice (incremental cheap, full expensive), and connection_id with strong recommendation and explanation of mis-routing risk without it.
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 primary action ('Ingest a chat channel's messages into the Atlas knowledge base') and differentiates it from retrieval tools ('It does NOT answer questions — use the retrieval tools for that') and sibling 'refresh_wiki' ('distinct from refresh_wiki, which only re-renders wiki pages').
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?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear guidance: only when explicitly requested or when retrieval results are stale and last sync was >24h ago. Also lists prerequisites (get 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: read-only, no side effects, return format (dict with answer, citations, follow_ups, metadata), error modes as dicts (not exceptions), and time expectations (instant for quick, up to 90s for deep/summarize). This covers all key behaviors.
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?
The description is well-structured with clear sections (When to use, When NOT to use, Prerequisites, Returns, Error modes). It is relatively long but every sentence provides value; however, it could be slightly more concise without losing clarity, justifying a 4 rather than 5.
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 complexity (four parameters, multiple modes, error handling, output format), the description covers prerequisites, return structure, error modes, and timing. It references the output schema implicitly and provides all necessary context for an agent to invoke the tool correctly.
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 value beyond the schema: for channel_id it references list_channels; for question it gives length constraint and example; for mode it explains the retrieval depth (BM25, graph+multi-hop, etc.); for session_id it explains multi-turn continuity and provides an example. This enriches understanding.
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 purpose: answering natural-language questions about a channel with synthesized, cited reasoning. It explicitly distinguishes itself from sibling tools like search_channel_facts, search_memory, and find_facts by specifying when to use each, ensuring the agent selects correctly.
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 guidance on when to use the tool (any question needing an answer with reasoning) and when not to (exact keyword lookup, cross-channel recall, substring scan). It also lists prerequisites (channel_id from list_channels), making usage conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the tool is 'instant, read-only, no side effects'. It explains the return structure, including that expertise_score is a relative float only meaningful for ranking, and describes error modes like authentication_missing and graceful degradation to empty list.
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?
The description is well-structured with a one-line summary, usage context, prerequisites, return format, and error modes. It is slightly verbose but every sentence adds value, so it earns a 4 rather than a 5.
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, no annotations, and an output schema described in text, the description is very complete. It covers return structure, error modes, meaning of empty list, and ranking scale. No gaps remain for effective usage.
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 beyond the schema: for channel_id, it specifies it comes from list_channels and is not a display name; for topic, it mentions matching against knowledge-graph edges; for limit, it describes range and clamping behavior.
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 purpose: 'Rank the PEOPLE most knowledgeable about a topic in one channel.' It uses a specific verb (rank), identifies the resource (people/topic/channel), and distinguishes itself from sibling tools like search_channel_facts and find_facts by emphasizing that it ranks people, not facts.
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?
Explicit guidance is given: 'Call this to answer "who should I ask about X in #channel?"' or to route a question. It provides a prerequisite (channel_id from list_channels) and specifies not to use a display name. It also contrasts with siblings (use find_facts for facts, this for humans).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses read-only nature (no sync trigger), latency characteristics, error modes, return format with field descriptions, and scoping rules. No contradictions.
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?
Well-structured with clear sections for latency, return format, field descriptions, scoping, and error modes. Every sentence serves a purpose without redundancy.
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 provided, the description fully documents the return object structure, field meanings, and error responses. It covers all necessary context for a tool with one required parameter.
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% with description for connection_id. The description adds context on where to obtain the parameter (list_connections/whoami) and format requirements, adding value beyond 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 explicitly states it lists channels the bot can read on one connection, serving as ground-truth source. It distinguishes from sibling tools like list_connections and ask_channel by specifying it provides the channel_id needed for retrieval tools.
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 precise when-to-call instructions: after list_connections/whoami, before retrieval tools, once per connection. Also recommends preferring this over list_connections.selected_channel_count and explains why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully covers behavior: read-only, no side effects, returns specific fields, omits content_md intentionally, and details error modes.
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?
Well-structured with distinct sections for purpose, usage, returns, errors; no extraneous information.
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?
Complete for a listing tool with 4 parameters, described output schema, error modes, and prerequisites; no 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?
Schema coverage is 100%, but description adds significant value by explaining scope's downgrade behavior, kind filter values, and target_lang default.
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 it lists wiki pages as lightweight summaries without page bodies, and distinguishes from read_wiki_page which retrieves the body.
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 states when to use (browsing, discovering slugs) and when not to use (when slug is known and body needed), and lists 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states 'Returns (instant, read-only): ... No side effects.' and lists all error modes in detail. No contradictions.
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 well-organized with clear sections (summary, when to use/not, prerequisites, returns, error modes). It is concise and front-loaded with the key purpose.
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 (3 required), 100% schema coverage, and output schema described, the description covers all necessary aspects including error modes. No 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?
Schema description coverage is 100%, baseline 3. The description adds context beyond schema by explaining how to obtain parameters (e.g., 'Get it from list_channels', 'Discover slugs via list_wiki_pages') and the purpose of 'anchor'.
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 explicitly states 'Fetch ONE structured module from a wiki page without downloading the whole page.' This is a specific verb (fetch) and resource (structured module), and it distinguishes from sibling tools like read_wiki_page and read_wiki_section.
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 clear when-to-use and when-not-to-use guidance, including alternatives (read_wiki_section, read_wiki_page). It also lists prerequisites and how to discover parameters (channel_id, page_slug, anchor).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares it is 'instant, read-only' with 'no side effects'. Lists error modes and return fields comprehensively, providing full behavioral 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?
Well-structured with clear paragraphs: purpose, disambiguation, prerequisites, return signature, error modes. Every sentence adds value; no fluff.
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?
With 4 parameters (3 required), 100% schema coverage, and an output schema (return fields listed), the description covers all necessary context: prerequisites, error handling, return format, and usage guidance. Fully complete 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?
Schema coverage is 100%, but description adds context: anchor is 'kebab-case in-page id' and mentions error handling for unknown anchors; target_lang default noted. Provides extra guidance 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 verb 'Fetch ONE narrative (prose) section' and specifies the resource. It distinguishes from siblings read_wiki_module, read_wiki_page, and find_facts by explaining what each returns.
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?
Explicit when-to-use: 'when you know the page slug and section anchor and want just that article slice, to save tokens.' Includes disambiguation with siblings and prerequisites (channel_id, page_slug, anchor) with source tools listed in parentheses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses asynchronous nature, latency, side effects (writes/overwrites), response shape, error modes, and tracking method.
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 sections, but slightly verbose. Every sentence adds value, so no wasteful text.
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?
Covers all necessary aspects: prerequisites, latency, side effects, error modes, output schema shape, and tracking. Complete for an async, expensive operation.
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?
Adds meaning beyond schema by describing channel_id as required and page_types as optional with default behavior and listing valid values.
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 'Re-render' and resource 'wiki pages' and explicitly distinguishes from sibling tools like trigger_sync and retrieval tools by stating what it does NOT do.
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' and 'WHEN NOT TO USE' sections, including specific scenarios (after trigger_sync, explicit user request) and cautions against routine calls. Also lists prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It fully discloses that the tool always returns a structured error payload, performs no backend call, and is exempt from rate limiting. This is comprehensive behavioral 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 paragraph with front-loaded 'DEPRECATED — do not call.' Every sentence adds value: purpose, replacements, and behavior. No wasted words.
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 simple deprecated nature, the description is complete. It covers what the tool does, what it returns, and alternatives. The existence of an output schema is noted but description doesn't need to repeat it.
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 has 2 parameters with no descriptions and 0% coverage. Description does not add meaning to parameters, but since the tool always returns the same error regardless of parameters, the lack of semantic explanation is acceptable. The implicit understanding that parameters are ignored is sufficient.
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 is deprecated and a compatibility shim, with a specific purpose of returning an error directing to replacements. It distinguishes itself from siblings by explicitly naming replacements.
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 'DEPRECATED — do not call' and provides two specific replacement tools. Also explains that calling it returns an error and does no work, giving clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: read-only, no side effects, instant for small hops, return structure, error modes, clamping of hops. It leaves no ambiguity about what happens in various scenarios.
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?
The description is well-structured with sections and bullets, but slightly verbose. However, every sentence adds value and the information is front-loaded with the purpose.
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 complexity (graph search) and no output schema provided, the description fully covers prerequisites, usage, return format, error handling, and edge cases (empty results, clamping). It is sufficiently complete for correct agent usage.
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%, and the description adds significant context beyond the schema: how to obtain channel_id, that entities are names (not IDs), hops clamping, and typical values. This helps the agent use parameters correctly.
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 purpose: 'Find how named ENTITIES connect in a channel's knowledge graph.' It uses specific verbs and resource, and explicitly distinguishes from sibling tools like 'get_wiki_graph' by contrasting knowledge graph vs. wiki page-link graph.
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 usage contexts ('to answer how is X related to Y?'), prerequisites (requires channel_id from list_channels and entity names), and behavior for missing entities (empty subgraph). Also mentions alternative tools for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side effects (none), latency (instant), safety (safe synchronous call), return format with example, and error case. Since no annotations are present, the description fully handles behavioral disclosure.
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?
Well-structured: purpose first, then usage, prerequisites, returns, side effects. Every sentence adds unique value; no redundant or filler content.
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 params and presence of output schema (context signal), description covers all needed context: purpose, usage conditions, prerequisites, return value with example and error, side effects. Complements sibling tool ask_channel effectively.
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 input schema, so schema coverage is 100%. With 0 parameters, the baseline is 4; description adds no param info but provides return value semantics as a bonus.
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?
Starts with verb 'Mint' and resource 'fresh conversation session id', clearly stating the action and output. Distinguishes from sibling tool 'ask_channel' by explaining it starts a new thread for a clean break.
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 specifies when to use (unrelated topic, start over) and when NOT to use (before every question, noting auto-creation by ask_channel). Prerequisites and authentication requirement are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses latency ('instant'), scalability ('single in-memory/DB lookup; never triggers a sync or job'), and error modes ('authentication_missing'). Since no annotations are provided, the description fully bears the burden, and it does so comprehensively.
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 well-organized into clear sections (purpose, usage, latency, return values, errors). Every sentence is necessary and informative, with no fluff.
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 zero input parameters, the description covers everything an agent needs: what the tool does, when to use it, what it returns, and how it behaves. It is fully self-contained and handles all context for the 27 sibling tools.
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?
There are no parameters, so the baseline is 4. The description adds value by detailing the return schema (principal_id, connections, server_version) and error conditions, going beyond the empty input 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 specifies a verb ('confirm') and a clear resource ('authentication and connection ids'). It distinguishes itself from sibling 'list_connections' by explaining that 'whoami' returns only connection IDs, while 'list_connections' provides additional 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 instructs to 'Call this FIRST in any session, before any other tool' and advises against repeated calls. It also states when to use the alternative 'list_connections', providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description fully covers behavioral traits: it states 'instant, read-only', 'no side effects', and lists all error modes. This compensates for the lack of 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 well-structured into logical paragraphs with clear sections. Every sentence adds value, and it is concise while still being comprehensive. There is no redundancy.
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, the description covers purpose, usage guidelines, parameter, return format, side effects, and error modes. The presence of an output schema (not shown but referenced) further supports completeness.
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?
The schema has 100% coverage for the single parameter channel_id. The description adds meaningful context beyond the schema by providing an example value ('ch-eng') and specifying the source (list_channels), which enhances usability.
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 reports fact extraction progress as a count per status for a channel's messages. It uses specific verbs and resource, and distinguishes from get_job_status by explaining the difference between counting messages by extraction state versus reporting job lifecycle.
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?
It provides explicit when-to-use scenarios: judging corpus completeness before relying on retrieval, tracking progress after sync, and detecting backlogs. It also distinguishes from get_job_status and lists prerequisites (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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only behavior, no side effects, performance hints (instant vs longer), error modes as dicts, and return shape. With no annotations provided, the description fully covers behavioral expectations.
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?
Well-structured with bullet points and code blocks. Every sentence adds value. Front-loaded with core function and usage note. Routing rule is efficiently presented.
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?
Covers prerequisites, behavior, returns, error modes, and performance. With output schema present, description is complete for a complex tool with multiple scopes and error conditions.
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?
Adds significant meaning beyond schema: query length constraint with error, scope options with examples, limit clamping. All three parameters are elaborated with context.
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 'Find facts ACROSS MANY channels by hybrid search' when channel is unknown. It distinguishes from siblings like search_channel_facts and ask_channel, providing a specific verb and resource.
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 a detailed routing rule for three search tools, explaining when to use each. Includes prerequisites and explicit guidance: 'Call it first for broad recall, then drill into a specific channel'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it declares the operation as 'instant, read-only, no side effects,' describes the exact return format including fields like `entity`, `superseded_by`, `relationship`, `confidence`, `context`, `position`, and lists all error modes (authentication, access denied, invalid parameter). It also explains that empty list means no supersession chain.
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 well-structured with clear sections: purpose, when to call, distinction from siblings, prerequisites, return format, and errors. Every sentence adds essential information, and it is front-loaded with the key use case.
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 complexity (2 params, no enums, with output schema), the description covers all necessary context: purpose, usage, behavior, return format, and error modes. The output schema exists, so the description's detailed field explanation is supplementary and complete.
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% with clear descriptions, but the tool description adds significant value: for `channel_id`, it specifies the source (list_channels) and warns it's not a human name; for `topic`, it provides examples and cautions against yes/no questions. This extra context enhances understanding 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's purpose: 'Reconstruct how a decision EVOLVED over time in a channel.' It uses a specific verb ('reconstruct') and resource ('decision evolution over time'), and explicitly distinguishes from sibling tools `find_decisions` and `search_channel_facts` by contrasting their scopes.
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 when-to-use guidance: 'answer how did the team arrive at the current approach for X?' and when-not-to-use: 'for current decision facts use find_decisions, for current state use search_channel_facts.' It also includes a prerequisite (channel_id from list_channels) and notes that empty results are normal for new channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![beever-atlas MCP server](https://glama.ai/mcp/servers/Beever-AI/beever-atlas/badges/card.svg)](https://glama.ai/mcp/servers/Beever-AI/beever-atlas)

Score Badge

Copy to your README.md:

[![beever-atlas MCP server](https://glama.ai/mcp/servers/Beever-AI/beever-atlas/badges/score.svg)](https://glama.ai/mcp/servers/Beever-AI/beever-atlas)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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