Tribal

Official

by tribal-memory

Overview Schema Related Servers Score Discussions

Rust

Hybrid

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation5/5
Each tool has a unique and clearly defined purpose. There is no overlap between search, exploration, ingestion, job monitoring, feedback, and administration tools.
Naming Consistency5/5
All tools follow the 'tribal_verb_noun' pattern consistently, making it easy to infer each tool's function from its name.
Tool Count5/5
With 10 tools, the server is well-scoped for managing a knowledge base. Each tool serves a distinct and necessary role without unnecessary bloat.
Completeness4/5
The toolset covers the core lifecycle of knowledge management (search, explore, retrieve, ingest, feedback), but lacks explicit tools for updating or deleting individual items, which is a minor gap.
Average 4.6/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 571 commits in the last 12 weeks
- Last stable release on June 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses mutation, non-blocking behavior, atomic swap, and no-op condition. It also notes operator-only restriction. The dry_run parameter is documented in the schema but not the description, which is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and each sentence adds essential information without redundancy. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema present), the description covers the key behavioral aspects. It implies asynchronicity via 'worker drives to completion' and the sibling job_status tool fills the gap. The description is sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond the schema. It mentions naming the target parameters but doesn't elaborate on validation or interaction. The baseline of 3 is appropriate given full schema coverage.
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 starts a reindex to a new embedding geometry, specifying the key parameters (provider, model, dimension). It differentiates from sibling tools like cancel and prune by focusing on initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that reads/writes continue during reindex, the swap is atomic, and unchanged target is a no-op. It mentions operator-only access and that the worker drives completion. While it could explicitly contrast with alternatives, the context of siblings provides enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses depth cap at 3, latency implications for include_standing at depth > 1, and ordering of results. It does not mention authentication or rate limits, but it adequately describes behavioral traits for a read-like operation.
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 (overview, workflow, direction, relation types, depth). It is front-loaded with the main action, and each sentence adds necessary information without redundancy. 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 complexity (graph traversal, 8 parameters, sibling tools), the description is highly complete. It integrates the tool into a workflow, explains parameter trade-offs, and sets expectations for depth limits. An output schema exists, so return value details are not needed.
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%, so baseline is 3. The description adds significant value beyond the schema by explaining the workflow, providing definitions for direction and relation types, and cautioning about depth. This extra context 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's purpose: 'Traverse the relationship graph from a specific knowledge item.' It distinguishes itself from siblings like tribal_discover by describing a typical workflow, and the description is specific about traversing relationships (supports, contradicts, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool after tribal_discover and outlines a clear workflow: discover, pick an item, then explore. It explains parameters like direction and relation types, aiding decision-making. It lacks explicit 'when not to use' instructions but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It reveals response behavior (keyed by ID, missing IDs map to null) and implies read-only usage via 'retrieve.' However, it does not explicitly state side-effect freedom or authorization needs, though the retrieval nature is clear.
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 front-loads the core action, then provides focused usage guidance and response details in just three sentences. Every sentence is necessary and adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema, and sibling tools, the description completes the picture by specifying when to use, limitations (direct lookup), and response format. It does not need to explain return values (output schema exists) and covers all essential contextual aspects.
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 extra meaning to parameters beyond what the schema provides (e.g., include_references, include_standing are described in schema). Thus, it meets the baseline without surpassing 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 starts with 'Retrieve one or more knowledge items by their IDs,' clearly stating the verb and resource. It explicitly distinguishes this tool from siblings (tribal_discover for semantic search, tribal_explore for relationship traversal), making its specific purpose unmistakable.
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 usage context: 'Use this when you have a specific item ID ... and need the full item.' It also clearly states when not to use it, directing to alternative tools for semantic search and relationship traversal, leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains that the run is aborted, profile failed at next task boundary, active profile untouched, and that it's operator-only. Covers key side effects, though reversibility is not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second adds behavioral details. 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?
Despite no parameters and presence of output schema, the description covers essential behavioral details (cancellation effects, auth requirement, single-flight). No apparent 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?
Zero parameters, baseline score 4. Description adds meaning by stating 'takes no arguments; reindex is single-flight', confirming no input needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool cancels the live reindex run, with specific behavior (abort, fail profile at next task boundary). Distinguishes from siblings like tribal_reindex and tribal_reindex_prune.
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?
Indicates cancellation is conditional ('if any'), and notes reindex is single-flight. Doesn't explicitly state when not to use, but context implies it's for active runs only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: asynchronous operation with immediate job_id return, knowledge extraction and storage. Mentions that project/model/principal come from context. However, no annotations exist, so the description carries full burden; it could mention idempotency or side effects, but the provided info is sufficient for safe use.
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?
Concise with clear structure: main action, async note, usage guidance, exclusions, and context sourcing. Every sentence serves a purpose; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async, multi-step extraction) and existence of an output schema, the description covers essential operational aspects, usage, and parameter context. It does not detail error handling or output structure (covered by schema), but is complete enough for effective use.
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% (baseline 3). The description adds value: explains how to write content naturally for best results, and clarifies project_id as optional override. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Submit raw text for knowledge extraction') and identifies the resource ('into Tribal'). It explains the system's extraction process (facts, heuristics, etc.) and clearly differentiates from siblings by focusing on ingestion, not discovery, exploration, or other operations.
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 on when to use: 'when you've learned something worth preserving' with concrete examples. Also states when NOT to use: 'Do NOT use this for storing code snippets...'. Recommends polling with tribal_job_status for async completion and notes context sourcing from tribal_set_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?
With no annotations, the description fully covers behavioral traits: job lifecycle (queued → extracting → triaging → relating → completed/failed), terminal states (completed, failed, with sub-outcomes), and wait_seconds blocking behavior. 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?
The description is well-organized with sections for lifecycle, terminal states, and usage. It is somewhat lengthy but all information is relevant and earns its place.
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 (not shown), the description need not detail return format. It comprehensively covers job lifecycle, terminal states, and wait_seconds behavior, leaving no gaps for agent understanding.
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 by explaining the job lifecycle and the effect of wait_seconds beyond schema descriptions, but the schema already describes parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks the progress of an ingest job submitted via tribal_ingest, with a specific verb ('Check') and resource ('Ingest Job Status'). It distinguishes from sibling tools by focusing on status polling.
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?
Guidance is provided on when to use (after tribal_ingest) and how to use wait_seconds to collapse round-trips. It does not explicitly mention when not to use or alternative tools, but the 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?
Despite no annotations, the description fully discloses the tool's behavior: what gets superseded (non-active complete and failed profiles), what gets deleted (embeddings), and what remains untouched (active profile and run history). 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 extremely concise with two sentences, front-loading the core purpose and adding necessary details without any 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 simplicity (no parameters, straightforward action) and the presence of an output schema, the description is complete. It covers the action, scope, and authorization requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description adds value by explaining the cleanup process beyond the schema, meeting the baseline of 4 for zero-parameter 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 explicitly states the tool's purpose: reclaim storage by superseding non-active and failed profiles and deleting embeddings. It clearly distinguishes from siblings like tribal_reindex and tribal_reindex_cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Operator-only' to indicate restricted usage, implying it should be used by operators for cleanup. While it doesn't list explicit alternatives or when-not-to-use scenarios, the 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 provided, so description carries full burden. It explains default exclusion of superseded items, behavior of include_standing and its latency, project_id three-way semantics, tag AND logic, and pagination via cursor. No contradictions or hidden 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?
Description is well-structured and front-loaded with core purpose. Each sentence adds value, though slightly longer than minimal. 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?
For a tool with 10 parameters, nested objects, and an output schema, the description is comprehensive: covers usage, filters, pagination, standing, superseded items. No gaps remain.
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 description coverage is 100%, but description adds significant value: explains natural language embedding, semantic similarity ranking, project_id semantics, tag AND vs OR, and when to use kinds filter sparingly. Go 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 it's for searching Tribal's knowledge base using natural language, with semantic similarity ranking and optional filters. It distinguishes itself from sibling tools like tribal_explore (for exploring item details).
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 'Use this as your first step when you need context... before starting work on a feature, debugging, design decision.' Provides examples of queries and when to use filters vs not. Advises follow-up with tribal_explore for deeper understanding.
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 provided, the description fully carries the burden. It discloses that feedback builds an eval dataset, that submission should be selective and only when signal is clear, and that incomplete feedback (missing trace_id) should not be submitted. This goes beyond basic 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 well-structured with a clear lead sentence, followed by explicit guidance. It is slightly long but each sentence is informative. It could be slightly more concise, but overall it is front-loaded and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (4 required) and no annotations, the description covers all necessary aspects: purpose, usage, parameter roles, and behavioral expectations. It mentions that feedback forms an eval dataset, which is important context. The description is 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters described). The description adds context beyond the schema, such as explaining the purpose of embedding_profile_id (for lineage), explored_anchor_ids (anchors used), and notes (optional reasoning). It does not simply repeat schema descriptions but enriches them.
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: 'Record a quality signal about a retrieval session.' It uses specific verbs and resources, and distinguishes itself from sibling tools like tribal_discover and tribal_explore by focusing on the combined retrieval session quality.
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 (when Tribal's knowledge helped or failed), when-not-to-use (not for individual items), and criteria for positive/negative ratings. It also warns against fabricating trace_id and advises to be selective, making it clear how to use the tool correctly.
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 provided, the description bears full responsibility for behavioral disclosure. It explains that session context becomes default for subsequent calls, how server resolution works, and that this tool fills gaps or overrides. The description is transparent about the tool's impact and limitations.
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 efficiently structured: first sentence defines purpose, then usage guidance, then behavioral explanation. Every sentence adds value and no waste. It is front-loaded with the core 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 low complexity, full schema coverage, and presence of an output schema, the description adequately covers all necessary information. It explains purpose, usage, parameter details, and behavioral implications, leaving 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 valuable context beyond the schema: for 'model' and 'provider' it recommends setting once at session start, and for 'project_id' it clarifies override behavior. This improves usability without being verbose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Set or override session-level context for Tribal') and resource ('session context'). It distinguishes itself from siblings by emphasizing that it configures defaults used by other tribal tools, which is a distinct role from data ingestion or discovery 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?
The description explicitly states when to use the tool ('at the start of a session' or 'when switching projects') and explains the default server inference and when to override. It also implies when not to use it (when server inference suffices), providing clear guidance.
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:

[![tribal MCP server](https://glama.ai/mcp/servers/tribal-memory/tribal/badges/card.svg)](https://glama.ai/mcp/servers/tribal-memory/tribal)

Score Badge

Copy to your README.md:

[![tribal MCP server](https://glama.ai/mcp/servers/tribal-memory/tribal/badges/score.svg)](https://glama.ai/mcp/servers/tribal-memory/tribal)

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/tribal-memory/tribal'

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