Persistent project context for Claude. IANA-registered .faf format.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.7/5 across 19 of 19 tools scored. Lowest: 2.8/5.
Each tool has a distinct purpose: scoring, validation, search, memory, generation, etc. Even similarly named tools like faf_score and faf_validate are clearly differentiated by their outputs.
Names follow a consistent verb_noun pattern, with core FAF tools prefixed by 'faf_' and soul management tools using clear verbs (list, get, search). No mixing of styles.
19 tools is well-scoped for the domain of FAF analysis and soul management, covering necessary operations without being excessive.
The tool set covers scoring, validation, search, and memory well, but lacks CRUD operations for souls (no create, update, delete), which is a notable gap for full lifecycle management.
delta_checkDelta Doctrine CheckCInspectDetermine if a topic needs FULL, DELTA, or X-DELTA soul.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose whether the tool is read-only, what happens on error, or any side effects. The description is minimal and lacks transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 10 words, very concise and front-loaded. It effectively communicates the core purpose with no wasted words, though it might benefit from slight expansion for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, no output schema), the description is plausible but incomplete. It does not explain the return value or format, nor how the determination is made, which an agent would need for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameter description ('Topic to check') is clear but minimal; the tool description adds no further semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('determine if') and identifies the resource ('topic') and the possible outcomes ('FULL, DELTA, or X-DELTA soul'). It clearly states what the tool does, though it does not explicitly differentiate from sibling tools, which are varied in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_soul or list_souls). No context on prerequisites or conditions for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_analyzeFull analysis (score + tier + validate)AInspectOne-call composite — returns score, tier-ready, valid, and engine identifier. Two WASM calls, sub-millisecond total.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw .faf YAML content to analyze. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that it makes two WASM calls with sub-millisecond total time, indicating efficiency and read-only behavior. However, it does not cover error handling, idempotency, or other potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that convey the tool's composite nature, performance, and return items. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description lists return items (score, tier-ready, valid, engine identifier) but lacks details on their types, formats, or error conditions. Somewhat complete for quick understanding but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'content' has full schema coverage with a description matching the tool's description. The description adds no additional meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a composite tool that returns score, tier-ready status, validity, and engine identifier in one call. It distinguishes itself from sibling tools like faf_score, faf_validate, and faf_get_tier which perform individual analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is a one-call composite for quick analysis but does not explicitly state when to use it versus calling the separate siblings. No when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_collections_searchSearch a Grok Collection (edge, KV-cached)AInspectPhase III (FRC §7b) — semantic search over a Grok Collection at the edge, KV-cached (1h TTL). Returns matched chunks (content, score, file). Requires the XAI_API_KEY secret; composes with faf_section (structural) for hybrid retrieval. Handled env-aware in the MCP handler (needs the key + KV).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max chunks to return (default 5). | |
| query | Yes | The search query. | |
| collection_id | Yes | The Grok Collection id to search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: KV-caching with a 1-hour TTL, environment-aware handling, and requirement of the XAI_API_KEY secret. It also states the return structure. While it does not explicitly label the tool as read-only, the semantic search nature implies non-destructive behavior. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the first sentence immediately stating the primary function and the second expanding on return type, requirements, and integration. Every sentence contributes value without redundancy. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema), the description covers core functionality, caching behavior, composition with a sibling, and environment needs. It lacks details on error handling (e.g., invalid collection_id, missing key) but provides sufficient context for typical usage. The description is complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions already clear. The description adds no extra information about the parameters (query, collection_id, limit) beyond what the schema provides. It does not explain query formatting or limit semantics, resulting in no added value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'semantic search over a Grok Collection', specifies the Phase III context, and describes the return format (matched chunks with content, score, file). It also distinguishes from sibling tool faf_section by noting composition for hybrid retrieval, making the purpose well-defined and separated from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions composition with faf_section for hybrid retrieval, implying that faf_collections_search is for semantic search while faf_section is for structural. However, it lacks explicit guidance on when to use this tool versus alternatives like search_by_tag or search_context, and does not provide explicit exclusions or prerequisites beyond the API key requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_estimate_tokensEstimate tokensAInspectEstimate token count for arbitrary content via the Zig WASM engine. Sub-millisecond, zero allocations. Useful for context-budget planning.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content to estimate tokens for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses performance traits ('sub-millisecond, zero allocations') and the engine, but does not explicitly state idempotency or side effects. However, the nature of token estimation implies safe, read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and engine, followed by performance and use case. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose and performance but lacks details about the return value (e.g., returns an integer token count). This omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the parameter adequately. The description adds 'arbitrary content' but no additional meaning beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name and title clearly indicate token estimation. The description specifies 'arbitrary content' and the engine, distinguishing it from siblings like faf_analyze or faf_score, which perform different analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Useful for context-budget planning,' implying usage context, but does not explicitly mention when to use or avoid this tool, nor provide alternatives among siblings. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_gateFRC quality gate (promote/hold)AInspectPhase III (FRC) — pre-promotion quality gate. Scores .faf content (edge Mk4) + estimates tokens and returns a deterministic promote/hold verdict BEFORE it goes to a Grok Collection. Promote IFF score >= min_score AND tokens <= max_tokens (defaults 85/8000). Edge parity with the local gate; the hold-hint can't list empty slots at the edge.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw .faf YAML content to gate. | |
| min_score | No | Minimum score to promote (default 85). | |
| max_tokens | No | Maximum tokens to promote (default 8000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description clearly discloses that the tool is deterministic, returns a verdict based on score and token thresholds, and has edge parity with local gate. It also notes a specific behavior about hold-hint not listing empty slots, adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, and uses clear sentences. The last sentence about edge parity adds useful context but could be ambiguous. Overall efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the verdict but does not specify its format (e.g., string, JSON object). It also lacks error handling or edge case behavior. While adequate for basic use, it could be more complete for agent certainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover parameter fields (100% coverage), but the tool description adds default values (85 and 8000) and the logical condition for promotion, which is not present in schema. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states this is a pre-promotion quality gate that scores content, estimates tokens, and returns a promote/hold verdict. It explicitly distinguishes from sibling tools like faf_score, faf_estimate_tokens, and faf_validate by combining their outputs into a decision for a specific phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage at phase III before Grok Collection, but does not explicitly state when to use over alternatives or when not to use. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_get_tierGet tier for a scoreBInspectResolve the FAF tier for a given numeric score. Returns the tier symbol (Trophy/Gold/Silver/Bronze/etc.) per the canonical tier-table.
| Name | Required | Description | Default |
|---|---|---|---|
| score | Yes | Numeric score 0-100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It lacks information on whether the operation is read-only, what happens for out-of-range scores, or any permissions needed. The description is minimal and does not add safety or side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses two short sentences, front-loading the main action. Every word serves a purpose; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one input and one return value. The description covers what it returns (tier symbol). Without an output schema, this is sufficient. However, it could mention handling of invalid scores or edge cases, so not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter well-described. The description adds the context 'per the canonical tier-table', which implies a stable mapping but does not add substantial detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resolve' and the resource 'FAF tier', specifying it takes a numeric score and returns a tier symbol such as 'Trophy', 'Gold', etc. It distinguishes itself from sibling tools like 'faf_score' or 'faf_analyze' by focusing specifically on tier resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus its siblings, nor does it mention any prerequisites or exclusions. Given the large number of sibling tools (18), clearer differentiation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_memoryPortable structured memory (.fafm)AInspectPhase III (FRC) — query the durable .fafm model by type/tag/priority/text. Omit filters for a structured summary. .fafm is NOT scored: this SELECTS facts (provenance preserved), never grades them.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by a tag. | |
| type | No | Filter by fact type (e.g. "feedback"). | |
| query | No | Case-insensitive substring match on fact text. | |
| content | Yes | Raw .fafm YAML content. | |
| priority | No | Filter by priority (e.g. "critical"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses read-only behavior ('SELECTS facts', 'provenance preserved'), non-scoring nature, and the effect of omitting filters. No mention of side effects, but the tool appears non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two precise sentences. First states purpose and filters, second adds critical behavioral context. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and basic usage, but lacks explanation of the required 'content' parameter's relationship to the 'durable model'. No output schema or return format guidance. For 5 parameters and no annotations, more detail is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description mentions filterable fields (type/tag/priority/text) but adds no extra detail beyond the schema. The required 'content' parameter's role is not clarified beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('query') and resource ('durable .fafm model') with specific filter dimensions. It distinguishes from scoring tools ('NOT scored'), but does not explicitly differentiate from sibling query tools like faf_collections_search or search_by_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage hints ('Omit filters for a structured summary') and behavioral contrast ('SELECTS facts, never grades them'), but no explicit when-not-to-use or alternatives. The context is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_orchestrate_recommendationOrchestrate Context Recommendation (FAF)AInspectTakes raw content strings (.faf, .fafm, and optionally package.json/CHANGELOG.md/README.md) and runs deterministic drift + contradiction signals across the FAF substrate. Returns a structured Recommendation (recommend, severity, reason, summary) with hints containing the current effective_policy and partial[] for any stateful signals unavailable on the current surface. Light-lane execution (hosted) is WASM-pure with no filesystem access. Heavy-lane execution (local via bunx/rust-faf-mcp) has full FS + persisted state. Advisory only — never auto-fires.
| Name | Required | Description | Default |
|---|---|---|---|
| faf | No | Raw .faf YAML content (project DNA). Required for any meaningful analysis. | |
| fafm | No | Raw .fafm YAML content (memory layer). Enables drift detection. | |
| readme | No | Raw README.md content. Enables README arch-tree cross-stamp checks. | |
| changelog | No | Raw CHANGELOG.md content. Enables changelog cross-stamp checks. | |
| packageJson | No | Raw package.json content. Enables version cross-stamp checks (.faf vs pkg). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers execution environments (light-lane vs heavy-lane), determinism, and advisory nature. It lacks details on side effects or auth needs, but for a non-destructive analysis tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear first sentence stating purpose. Two paragraphs are slightly verbose but each sentence contributes useful context. Could be trimmed, but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and no output schema, the description adequately explains the return structure (Recommendation with fields) and execution details. It covers the key behavioral aspects needed for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value by explaining what each optional parameter enables (e.g., 'Enables drift detection' for fafm), going beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool takes raw content strings and runs deterministic drift + contradiction signals, returning a structured Recommendation. It is distinct from siblings like faf_validate and delta_check by focusing on orchestration and recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for drift/contradiction analysis, and mentions 'Advisory only — never auto-fires.' However, no explicit when-not or alternative tools are named, leaving the agent to infer context from sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_scoreScore .faf contentAInspectScore .faf YAML content via the Mk4 Zig-WASM engine. Returns 0-100 (capped). Same engine as xai-faf-rust + xai-faf-zig (parity-tested). Sub-ms at the edge.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw .faf YAML content. Souls with a [faf] section have it extracted automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It provides engine, output range, and performance details, but does not disclose whether the tool has side effects (e.g., read-only vs. destructive), required permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, output/engine, and performance. No redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter nuance, output range, and performance, but lacks return format details (e.g., raw number vs object) and error handling. Adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds valuable context: 'Souls with a [faf] section have it extracted automatically' – clarifying input preprocessing beyond the schema's type/description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Score .faf YAML content' with a specific verb and resource, and mentions the unique engine (Mk4 Zig-WASM), distinguishing it from siblings like faf_validate or faf_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as faf_validate or faf_analyze. The description mentions performance and parity but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_sectionStructure-aware retrievalAInspectPhase III (FRC) — returns an EXACT, WHOLE .faf section by dotted path (e.g. "stack", "human_context"), structure preserved — the deterministic complement to blind chunking. Omit "section" to list every path.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw .faf YAML content. | |
| section | No | Dotted path to retrieve (e.g. "stack.backend"). Omit to list all paths. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains that the tool returns exact, whole sections with structure preserved, and that it is deterministic. This provides sufficient behavioral insight for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, dense sentence that front-loads key information (Phase III, FRC) and includes all essential details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers both use cases (with and without section) and indicates return format (exact whole .faf section). Could elaborate on 'structure preserved' but overall complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). Description adds value by explaining the effect of omitting 'section' (list all paths) and providing usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns an exact, whole .faf section by dotted path, with specific examples. It distinguishes itself from 'blind chunking' as a deterministic complement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use this tool (deterministic retrieval) versus alternatives (blind chunking), and provides guidance on omitting 'section' to list paths. However, it does not explicitly compare with sibling tools like faf_analyze.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faf_validateValidate .faf contentAInspectValidate .faf YAML content via the Mk4 Zig-WASM engine. Returns true if mission-ready (>= 100).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw .faf YAML content to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it validates via a specific engine and returns a boolean based on a threshold. It does not mention side effects or permissions, but for a validation tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Essential information is front-loaded (what, engine, outcome).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only validation tool with one parameter and no output schema, the description covers the core function. It doesn't explain 'mission-ready' but that's acceptable domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the description adds minimal value beyond the schema's 'Raw .faf YAML content to validate.' The threshold concept is given in the main description but not tied to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (validate), the resource (faf YAML content), the engine (Mk4 Zig-WASM), and the return condition (true if >= 100). It distinguishes from siblings like faf_analyze and faf_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to check if content is mission-ready), but does not explicitly contrast with siblings or state when not to use. Usage context is inferred but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_faf_from_githubGenerate FAF from GitHubAInspectGenerate a .faf file from any public GitHub repository WITHOUT cloning. Extracts 6 Ws from README, analyzes stack from languages and package.json, and generates Championship-grade AI context. Returns .faf content, quality score, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repository URL or owner/repo format (e.g., "facebook/react" or "https://github.com/facebook/react") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses key behaviors: no cloning, reads from public repos, extracts from README and package.json. It does not mention error cases or side effects, but for a non-destructive generation tool, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: first states core action and key differentiator, second explains what is extracted, third summarises returns. No wasted words, and the critical 'WITHOUT cloning' is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no nested objects or output schema), the description covers inputs, actions, and outputs. It could mention limitations or prerequisites (e.g., internet access, public repo requirement), but for a straightforward generation tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the 'repo' parameter. The tool description does not add additional semantic value beyond what is stated in the schema, and schema coverage is 100%, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating .faf files from public GitHub repositories without cloning. It lists specific actions (extracting 6 Ws, analyzing stack, generating AI context) and distinguishes from sibling tools like faf_analyze or faf_validate, which are analysis or validation tools rather than generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need a .faf from a public GitHub repository without cloning. It does not explicitly state when not to use or provide alternative sibling tools, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_soulGet Context SoulAInspectFetch a context soul by name. Returns structured AI context.
| Name | Required | Description | Default |
|---|---|---|---|
| soul | Yes | Soul identifier (e.g., "spacex", "wolfe", "grok") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states it's a fetch/read operation but does not mention error conditions, permissions, or what 'structured AI context' entails. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action and resource. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers the essential purpose and result. Lacks return format or error details but is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter description. The description ('Fetch a context soul by name') adds no extra meaning beyond the schema's example values. Meets baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (fetch), the resource (context soul by name), and the result (returns structured AI context). Distinguishes from sibling tools like list_souls which lists all souls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates use when you need a specific soul by name, but provides no explicit guidance on when not to use it or when to prefer alternatives like list_souls or search_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_soulsList Available SoulsBInspectList all available context souls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as pagination, ordering, limits, or error handling, leaving the agent with significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose without any superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and behavioral details, the description is insufficient. It fails to cover aspects like what a 'context soul' is, whether results are paginated, or any expected limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds the qualifier 'all available', which implies no filtering, adding meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb and resource: 'List all available context souls.' The name and title align perfectly, and it distinguishes from siblings like 'get_soul' (singular) and 'search_context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_soul' or 'search_context'. The description does not specify exclusions or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tagsList TagsBInspectList all unique tags used in a soul, with counts.
| Name | Required | Description | Default |
|---|---|---|---|
| soul | Yes | Soul identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose side effects, authentication needs, or output format details such as ordering or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 10 words, no unnecessary information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, list operation) the description is minimally viable, but lacks details on tag ordering, count meaning, or pagination, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the soul parameter well-documented. The description adds output semantics ('unique tags with counts') beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'unique tags' with scope 'in a soul' and additional detail 'with counts', distinguishing it from siblings like search_by_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like search_by_tag or tag_intel. The description only states functionality without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refresh_fafRe-ground on .faf content (drift → refresh → re-grounded)AInspectRe-ground on .faf content — re-score via the Mk4 Zig-WASM Enterprise scorer (33-slot, honors the authored app-type shape), report drift vs an optional baseline score, and return a stamped re-ground. The explicit re-grounding primitive for long sessions: drift → refresh → re-grounded. Built for Grok, by request.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Raw .faf YAML content to re-ground on. | |
| baseline | No | Optional last-known score (0-100). When provided, the drift delta (current - baseline) is reported. | |
| verbatim | No | When true, return the full .faf content verbatim with the stamp. Default false (stamped delta + summary). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the internal scorer (Mk4 Zig-WASM), 33-slot, app-type shape, and output behavior (stamped re-ground, drift delta). However, no mention of side effects, persistence, or authorization requirements. With no annotations, the description carries the full burden but is moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action, no redundant words. The phrase 'Built for Grok, by request' is slightly extraneous but doesn't harm clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately describes the return value (stamped re-ground, delta, verbatim option). It covers the tool's core behavior and internal mechanism, making it fairly complete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minor context (e.g., 'drift delta (current - baseline)') but does not significantly enhance parameter understanding beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool does re-grounding on .faf content using a specific scorer, with optional drift reporting. Differentiates from siblings by emphasizing it is the explicit re-grounding primitive for long sessions, but does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for re-grounding after drift in long sessions, but no explicit when-to-use or when-not-to-use compared to alternatives like faf_score or faf_validate. The context of 'long sessions' is helpful but not definitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_tagSearch by TagCInspectFind all entries in a soul with a specific tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to search for | |
| soul | Yes | Soul identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'Find all entries' implying a read operation but omits details on pagination, error handling, or side effects. Does not confirm non-destructive nature beyond inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, efficient. However, could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 params but no output schema or annotations. Description lacks information about return format, limits, or error cases, making it incomplete for a search operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds minimal value by combining parameters into a sentence ('find all entries in a soul with a specific tag'), but does not clarify format or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Find' and resource 'entries in a soul', clearly indicating the tool searches for entries by tag. It implicitly distinguishes from siblings like 'list_tags' and 'tag_intel' by focusing on entries rather than tags or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'tag_intel' or 'search_context'. Does not specify prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_contextSearch ContextAInspectFull-text search across souls. Returns matching lines only (token-efficient).
| Name | Required | Description | Default |
|---|---|---|---|
| soul | No | Specific soul (optional, searches all if omitted) | |
| query | Yes | Text to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds value by noting that results are 'matching lines only' and 'token-efficient,' which are useful behavioral details beyond the schema. However, it could describe side effects or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every phrase adds value: 'Full-text search across souls' for purpose, 'Returns matching lines only' for behavior, and 'token-efficient' for efficiency cue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters and no output schema, the description is mostly complete. It covers the search target, result format, and efficiency. Missing details about result structure (e.g., which fields per line) reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; the parameter names ('soul' and 'query') are self-explanatory, and the description only clarifies the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full-text search across souls' which identifies a specific verb and resource, and the phrase 'Returns matching lines only (token-efficient)' distinguishes it from other search tools like search_by_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full-text search but does not provide explicit guidance on when to use this tool versus its many sibling tools (delta_check, faf_analyze, etc.). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tag_intelTag IntelBInspectDiscover tag patterns, co-occurrence, candidates, and merge suggestions across all namepoints. Optionally suggest tags for a specific handle.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | Optional: suggest tags for this specific namepoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as side effects, permissions, rate limits, or whether the tool modifies data. 'Discover' implies read access but lacks explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the core functionality. Every sentence adds value without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description lacks information about return values, pagination, or interpretation of results. It does not provide enough context for an AI agent to understand what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter 'handle' documented as 'Optional: suggest tags for this specific namepoint'. The description repeats this information ('Optionally suggest tags for a specific handle'), adding no new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs and resources: 'Discover tag patterns, co-occurrence, candidates, and merge suggestions across all namepoints.' It also mentions an optional parameter for handling a specific handle, which distinguishes it from sibling tools like list_tags and search_by_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives among the many sibling tools. The description does not mention when-not-to-use, prerequisites, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.