arifOS MCP Server

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a distinct and clearly defined purpose within the kernel's lifecycle: from session initiation (arif_init) through observation, reasoning, ethical critique, judgment, sealing, composition, execution, and memory management. The only potential overlap between arif_route and arif_bridge_connect is explicitly resolved by preferring arif_route. All other tools are uniquely scoped with no ambiguity.
Naming Consistency4/5
All tools follow the 'arif_<verb>' pattern, with most verbs being single words (e.g., compose, judge, seal). The sole exception is 'arif_bridge_connect', which uses a compound verb. This minor inconsistency slightly detracts from the overall uniformity, but the pattern is otherwise consistent and predictable.
Tool Count5/5
With 11 tools, arifOS covers the full gamut of operations for a sophisticated governance kernel without being excessive. Each tool serves a clear and necessary role in the agent's workflow, from initialization to immutable sealing. The count feels well-scoped for the intended domain.
Completeness4/5
The tool set covers the major stages of the decision and execution pipeline: init, observe, think, critique, judge, seal, compose, forge, memory, route, and bridge. This provides a cohesive workflow. Missing are utility tools like listing or unsealing, but these are not central to the core lifecycle, so the gap is minor.
Average 3.7/5 across 11 of 11 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 21 of 24 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on July 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds that mutation only occurs after judge SEAL and lease/chain IDs, and mentions modes. However, terms like '888_HOLD without SEAL' are undefined, reducing clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but dense with jargon. It attempts to be concise but sacrifices clarity. Key information is present but poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the tool returns or how parameters like 'seal_verdict_id' or 'approved_action_hash' relate to the judge workflow. Given the complexity (15 params, destructive behavior, sibling tools), the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds very little about the 15 parameters. Only 'mode' enum values are mentioned in passing. This is insufficient for an agent to correctly use the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic jargon like 'KERNEL 777', 'A-FORGE', and '888_HOLD' without plain-language explanation. It vaguely indicates it's an execution gate requiring judge seal, but the core purpose is unclear for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides some guidance: skip without judge SEAL or while still planning (arif_think). However, it doesn't explicitly state when to use this tool vs siblings like arif_judge or arif_think, leaving ambiguity.
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?
The description reinforces the annotation's destructiveHint=true by stating 'irreversible' and 'immutable append'. It adds behavioral context beyond annotations, such as authority requirements ('Authority: 888_HOLD / SOVEREIGN + ack_irreversible for seal mode') and a veto power ('Arif owns F13 veto'). There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of moderate length, front-loading the core concept of immutable append. It contains poetic language and jargon (e.g., 'civilizational memory'), which reduces conciseness. While it covers key points, it could be more efficiently structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, destructive, no param descriptions), the description leaves significant gaps. It does not explain the meaning or purpose of any parameter, nor describe the output (despite an existing output schema). The mode list discrepancy further undermines completeness. An agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with 0% description coverage, and the description does not explain any parameter in detail. It lists modes in text ('seal | verify | chain | list | dry_run | seal_card | render') but the schema's mode enum includes different values ('seal', 'verify', 'ledger', 'changelog', 'audit'), creating inconsistency. The description adds minimal helpful parameter semantics and introduces confusion instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool performs an 'immutable append' or 'seal' operation, implying irreversible creation of a record. It mentions modes like 'seal' and 'verify', and gives a condition ('Seal only after SEAL verdict path'). However, the language is esoteric and uses proprietary terms (e.g., '888_HOLD', 'F13 veto') that may confuse an AI agent. The purpose is somewhat clear but not universally understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance: 'Seal only after SEAL verdict path' and 'Testing → dry_run', indicating when to use the seal mode versus dry run. It distinguishes the tool from siblings by stating 'Kernel judges; vault seals', implying arif_seal is for sealing after judging. However, it does not explicitly list when to use this tool over sibling tools like arif_judge or arif_think, limiting clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint true), the description adds that recall/inspect are free-ish and writes are gated mutations. It mentions authority and tiers. However, it does not explain what 'J-space mutations' entail, rate limits, or what exactly gets destroyed, leaving some ambiguity.
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 concise (4 sentences) and front-loaded with the essential identifier. It includes a list of modes. However, the dense jargon and lack of structure (e.g., bullet points) slightly reduce readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (55 parameters, no schema descriptions), the description is incomplete. It omits explanations for most parameters, does not clarify parameter interactions, and assumes knowledge of the kernel stack. The output schema exists but does not compensate for the lack of usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 55 parameters and 0% schema description coverage, the description only explains the 'mode' parameter (lists values) and briefly hints at 'tier'. The vast majority of parameters (e.g., query, content, policy) are not addressed, leaving agents to guess their meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a memory governor for a kernel, managing L1–L6 tiers and listing modes (recall, inspect, etc.). It distinguishes itself from a free notepad and from siblings by focusing on structured memory operations. However, the heavy jargon (J-space, F1/F2/F4/F11) reduces immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for structured memory, not ephemeral facts) and distinguishes read vs write modes. However, it lacks explicit guidance on when to use this tool vs sibling tools (e.g., arif_observe, arif_think) 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims binding arbitration and state-changing actions (SEAL/HOLD/SABAR/VOIDs), contradicting the readOnlyHint=true annotation. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense and front-loaded with core purpose, but uses cryptic jargon (KERNEL 888, floors, SABAR) that may confuse agents. Not optimally concise for AI consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core concept, modes, prerequisites, and alternatives, but lacks explanation of cryptic terms and some parameters. Adequate given output schema exists, but could be more comprehensive.
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?
Description adds meaning to key required parameters (actor, intent, domain, etc.) and mentions evidence, but many parameters (actor_id, session_id, etc.) are left unexplained. With 0% schema coverage, more detail would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for constitutional verdict and binding arbitration, with specific verbs like SEAL/HOLD/SABAR/VOIDs. It distinguishes from siblings by naming alternative tools for incomplete evidence or plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states required parameters (actor, intent, domain, etc.) and provides clear when-to-use guidance by directing to siblings when evidence or plan is incomplete, or for low-risk advisory.
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?
Annotations already cover safety (readOnly, idempotent, openWorld). Description adds behavioral detail: returns evidence, sources, uncertainty; authority level L0 OBSERVE; mentions epistemic tags. 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?
Description is very concise with no wasted words. It front-loads the purpose and lists modes. However, the jargon 'KERNEL 111', 'L0 OBSERVE' may be opaque without additional context, slightly reducing accessibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 un-documented parameters and many modes, the description is far from complete. It mentions return types but fails to explain parameter roles or mode differences. Output schema exists but is not shown; description does not compensate for missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – the description does not explain any of the 9 parameters beyond listing some modes. It omits meanings for url, query, layers, actor_id, session_id, etc. This is a critical gap.
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 gathers evidence from reality, with specific verb 'sense' and resource 'reality'. It distinguishes from siblings arif_think (pure reasoning) and arif_route (domain compute), making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for evidence gathering with modes like search, fetch, etc. Directly advises against use for pure reasoning ('skip when pure reasoning → arif_think') and domain compute ('arif_route to GEOX/WEALTH/WELL').
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?
Annotations provide idempotentHint and destructiveHint. The description adds context: binds actor/floors/audit, mints session_id and authority band, and describes anonymous mode without session. Good additional insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with jargon but front-loaded with core purpose. Could be more concise; multiple concepts packed into a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 26 undocumented parameters and no formal output schema, the description lists return fields but lacks explanations for most parameters. Incomplete for a complex initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 26 parameters with 0% description coverage. The description only lists some modes but misses two enum values (opt_out, opt_out_profiling) and does not explain other parameters like nonce, intent, context, etc. Insufficient compensation.
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 this tool initiates a kernel session, binds actor, floors, and audit, and is required before other arif_* verbs. It distinguishes from siblings by noting when to use arif_triage or arif_observe instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before other arif_* verbs, if no session) and when not to use (live session bound → arif_triage; pure facts only → arif_observe). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=true, but the description mentions 'Optional organ_tool+arguments = governed bridge call', which implies potential execution of a non-read-only action. This contradiction undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, and each sentence adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, output schema exists), the description covers purpose, usage, alternatives, return values, and constraints (L0 authority, not a free shell). It is sufficiently complete.
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 88% (high), so baseline is 3. The description adds minimal parameter info beyond the schema; it mentions 'organ_tool+arguments' but does not elaborate on other parameters.
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 is an 'Intent→organ router' and explains the use case: route a goal to the appropriate organ and verb. It distinguishes from siblings by mentioning arif_bridge_connect and arif_triage, providing specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Select when you know the goal but not which organ/verb.' Also gives clear when-not: 'Not session preflight (use arif_triage).' Recommends preferring this over arif_bridge_connect.
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?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. Description adds that it operates at Authority L0–L1, returns structured reasoning + confidence + next_safe_action, and is not a chat model. This provides useful behavioral context beyond annotations.
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 concise, packing purpose, modes, output, and cross-references into a few sentences. It front-loads the core identity. However, heavy jargon (F2/F7, OBS/DER/INT/SPEC) may reduce clarity for some agents, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and an output schema, the description covers purpose, usage, and behavioral traits reasonably well. However, it does not explain most parameters or provide usage examples, leaving some gaps for a complex tool. The output schema exists but is not shared in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description explains the 'mode' parameter with its enum values, but does not describe other parameters like query, plan_id, actor_id, session_id, etc. Given 8 parameters, the description only partially compensates for the lack of schema 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 clearly states it's for structure reasoning under F2/F7, explicitly distinguishes from a chat model and a verdict, and differentiates from siblings by pointing to arif_critique (ethical risk), arif_judge (binding decision), and arif_observe (facts).
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 says when not to use it ('not a chat model, not a verdict') and directs to sibling tools for related tasks. It lists modes but does not provide explicit guidance on when to choose each mode, though the mode names are self-explanatory.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, which the description does not contradict. The description adds beyond annotations: requires non-empty target, lists return types (risk, floors, human impact), and describes modes. However, it does not detail behavioral variations across modes, keeping a score of 4.
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 a single dense paragraph that front-loads purpose and usage. It packs substantial information without excessive verbosity, though it could be better structured with separation of modes and return types.
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 7 parameters (all optional, mostly metadata), no required params, and existence of output schema, the description covers core aspects: purpose, selection criteria, modes, requirements, and return types. Minor inconsistencies (mode list) and missing details on non-core parameters prevent a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides partial meaning for 'mode' and 'target' but contains inaccuracies: lists modes like 'simulate' and 'instruction_scan' not in schema enum, and omits 'shadow' and 'empathy'. Also states target is required but schema allows null default. With 0% schema coverage, the description poorly compensates.
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 performs ethical/dignity/risk stress testing before judgment, distinguishing it from SEAL. It specifies the conditions for selection (blast_radius MEDIUM+, human/dignity impact, irreversible risk) and names a sibling tool (arif_judge) for binding verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (blast_radius MEDIUM+, human/dignity impact, irreversible risk) and when to skip (pure technical with zero human stake). Also mentions authority level L1 and available modes, providing clear context for agent decision.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds significant behavioral context: it is a 'final human-facing composition' with a ΔS≤0 constraint (no state change), and it supports multiple modes. There is no contradiction; the description enriches transparency beyond annotations.
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 short and front-loaded with key information. It uses jargon like 'ΔS≤0' that may be obscure but is concise. Every sentence adds value. Minor deduction for the jargon density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and an output schema exists (not shown), the description covers overall purpose and pipeline position but lacks parameter documentation. It is adequate for understanding when to use the tool but insufficient for parameter-level decisions without the schema. The output schema may compensate, but description doesn't reference it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions modes and style but introduces 'format' and 'style' as modes not present in the enum (schema lacks 'style' and 'format' as enum values, though style is a separate parameter). Other parameters (message, actor_id, language, etc.) are not explained at all. This inconsistency and lack of detail limit its helpfulness.
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: 'Final human-facing composition' and positions it as the last step in a pipeline ('Call LAST after observe/think/judge'). It lists specific capabilities (citations, tone, ΔS≤0) and modes, clearly distinguishing it from siblings like arif_judge and arif_seal.
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 gives explicit guidance on when to call ('LAST after observe/think/judge') and when not to ('not mid-pipeline'). It also states what the tool is not a substitute for (arif_judge, arif_seal), providing clear exclusion criteria. This helps the agent select the correct tool in the pipeline.
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?
Annotations provide basic safety hints (non-destructive, non-idempotent, read-write). The description adds context about authority levels (HIGH / lease) and that it bypasses intent routing, which is valuable. However, it does not elaborate on potential side effects or consequences of misuse beyond these points, so not fully exhaustive.
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 very concise—four sentences. It is front-loaded with the kernel identifier and key purpose, and every sentence adds essential information without redundancy. No wasted words.
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?
For a tool with 6 parameters, 2 required, high schema coverage, and an output schema, the description adequately covers purpose, usage guidelines, and key constraints. It does not explain return values, but the output schema exists. Minor gap: no mention of error cases or expected behavior when parameters are missing.
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 high (83%), so the baseline is 3. The description reinforces that organ and tool_name are required, but does not add new details about other parameters like actor_id, arguments, or session_id beyond what the schema provides. No parameter-specific guidance is given.
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: a low-level, direct organ call that bypasses intent routing, requiring organ and tool_name. It distinguishes itself from the sibling tool arif_route, which is the safer default. The description is specific and actionable.
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 advises agents to prefer arif_route instead, providing clear when-to-use and when-not-to-use guidance. This directly addresses the decision between this tool and its alternative, making it highly helpful for selection.
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:

[![arifos MCP server](https://glama.ai/mcp/servers/ariffazil/arifos/badges/card.svg)](https://glama.ai/mcp/servers/ariffazil/arifos)

Score Badge

Copy to your README.md:

[![arifos MCP server](https://glama.ai/mcp/servers/ariffazil/arifos/badges/score.svg)](https://glama.ai/mcp/servers/ariffazil/arifos)

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/ariffazil/arifos'

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