Mcp-Omega-Brain

by VrtxOmega

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v2.1.1
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as omega_brain_report vs. omega_brain_status or omega_rag_query vs. omega_vault_search. However, some overlap exists in the VERITAS gates where multiple gates (e.g., veritas_evidence_gate, veritas_math_gate) serve similar high-level validation functions, which could cause minor confusion without careful reading of descriptions.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear prefixes (omega_, veritas_) that group related functionality. The naming is predictable and organized, making it easy to identify tool categories and purposes at a glance.
Tool Count3/5
With 27 tools, the count is borderline high for a single server, potentially overwhelming for agents. While the tools cover comprehensive governance and verification domains, the set might benefit from consolidation or splitting into more focused servers to improve usability.
Completeness5/5
The tool set provides complete coverage for its domains: Omega Brain offers full lifecycle management (ingest, query, execute, log, seal) and VERITAS includes all 10 gates plus supporting utilities. No obvious gaps exist; agents can perform end-to-end workflows without dead ends.
Average 4.3/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on April 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format (JSON with three fields) but does not state whether the tool has side effects or is read-only. The mapping is deterministic but the mutability is ambiguous.
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?
Two sentences: first maps verdicts to states, second gives usage and return format. Efficient and front-loaded, with no unnecessary 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 simple tool with one enum parameter and no output schema, the description provides enough information (mapping, usage, return fields) to use correctly. No gaps apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the 'verdict' parameter with enum values. The description adds no additional semantic nuance beyond the schema, which is adequate for this single-parameter tool.
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 the tool maps VERITAS verdicts to CLAEG terminal states with specific mappings, and identifies when to use it (after a pipeline run). However, it does not differentiate from the sibling tool veritas_claeg_transition, which likely has a similar purpose.
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 usage context ('Use this after a pipeline run') but does not specify when not to use it or mention any alternatives among the sibling tools.
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?
With no annotations, the description bears full burden. It describes the translation and satisfiability check and discloses return values and reason codes, but does not cover side effects, limitations (beyond timeout), or input validation behavior.
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?
Three sentences, front-loaded with the core function, no unnecessary words. Every sentence adds value.
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?
The tool has one complex parameter and no output schema. The description explains purpose and output shape but does not clarify what happens if required fields are missing or provide examples. Given complexity, it is adequate but not 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 coverage is 100% (all properties have descriptions). The description adds no parameter-specific information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool translates boundary constraints into interval arithmetic or SMT formulas and checks satisfiability with evidence values. It specifies it is 'Gate 5/10' and distinguishes from siblings by indicating use after the evidence gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this after evidence gate', providing clear context for when to invoke. It does not explicitly state when not to use, but the sequential hint is helpful.
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?
No annotations provided. Description discloses it stores and returns JSON with specific fields, but does not cover side effects like overwrite behavior, idempotency, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action and return format. No extraneous text.
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?
Tool is simple with 3 parameters and no output schema. Description covers purpose, usage, and return fields. Could mention behavioral details like idempotency but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema's parameter descriptions, which are already clear for content, source, and tier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stores', the resource 'knowledge fragment in provenance RAG store', and the purpose 'persist for future retrieval via omega_rag_query', distinguishing it from retrieval tools like omega_rag_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'persist decisions, patterns, or findings for future retrieval'. Does not include when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the return format (fields like rag_matches, vault_history, handoff, continuity_type) and the call timing, but does not discuss side effects, idempotency, or error conditions. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states purpose, second gives usage and return format. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no nested objects, the description covers the tool's action, parameters, return fields, and recommended call site. It is complete for the tool's simplicity, though it omits prerequisites like session state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the task parameter has a description). The description adds an example and specifies the type. This adds modest value beyond the schema, but does not compensate for missing parameter details like constraints.
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 'Loads episodic context for a new task by querying the RAG store, vault history, and any sealed handoff.' This specific verb+resource combination distinguishes it from sibling tools like omega_rag_query or omega_vault_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this once at the start of every new task before doing any work,' providing clear context. It does not list conditions when not to use or alternatives, but the instruction is direct and sufficient for an AI agent.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON with verdict and findings) and mentions the checks performed. However, it does not state whether the operation is destructive, requires authentication, or has side effects. Annotations would have helped, but the description provides a reasonable behavioral overview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states what it does and the gate number, second provides usage guidance and return summary. No wasted words, front-loaded with key information.
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?
The description is complete for the tool's complexity: it explains the gate function, usage, and return structure. No output schema, but return format is described. Slightly more detail about edge cases or failure modes would improve completeness.
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?
Input schema has one parameter 'claim' with 100% description coverage on all nested properties. The description reiterates the purpose but adds no novel parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's 'Gate 3/10' for analyzing supply-chain security via specific checks (SBOM scan, CVE check, etc.) and explicitly says 'Use this to assess third-party dependency risk before deploying or releasing.' It distinguishes from sibling gates (e.g., veritas_security_gate, veritas_adversary_gate).
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?
Description provides explicit usage context: 'Use this to assess third-party dependency risk before deploying or releasing.' It does not mention when not to use or name alternatives, but the context of sibling gates implies differentiation. Still, clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes behavior: computes max(cost_i / bound_i), checks against redline thresholds, and returns verdicts and reason codes. It also notes that the gate is skipped when no cost vector is declared. This provides adequate transparency for an agent.
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 four sentences long and front-loads the core purpose. It includes all necessary information without being overly verbose. Could be slightly more concise, but it effectively communicates the essential details.
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 that there is no output schema, the description explains the return format (verdict, utilization, reason_code) sufficiently. It also covers the key contextual detail about automatic skipping. The nested input schema is well-documented, so the description does not need to elaborate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each property of the 'claim' object. The description mentions 'cost vector' and 'cost bounds' which are part of the schema, but does not add significant meaning beyond what the schema already provides. Thus, it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Gate 6/10' for computing resource utilization and checking against redline thresholds. It uses a specific verb ('computes', 'checks') and specifies the resource ('cost budgets'). The sibling context suggests it is distinct from other Veritas gates like evidence or security gates.
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 states when to use: 'Use this to verify cost budgets are within limits' and when it is automatically skipped: 'skipped automatically if no cost vector is declared'. It does not explicitly mention alternatives among siblings, but the purpose is clear enough for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses the creation (write operation), the SHA-256 sealing, and the auto-load behavior on restart. However, it does not mention potential side effects or permissions.
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?
Three sentences with no extraneous information. Front-loaded with the primary action and key property (SHA-256 sealed handoff). Efficient and well-structured.
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?
The description explains the tool's purpose, usage timing, and return format. For a tool with 6 parameters and no output schema, it is fairly complete. Could mention error conditions, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes each parameter (task, summary, etc.). The description adds overall context but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a SHA-256 sealed handoff document that auto-loads on server restart. The specific verb 'creates', resource 'handoff document', and the unique URI 'omega://session/preload' make the purpose distinct from sibling tools like omega_seal_run or omega_log_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'at the end of a session to ensure seamless context continuity for the next session.' Provides clear when-to-use guidance, though it does not discuss alternatives or when not to use.
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?
Returns JSON with verdict, fragility, attacks_tested, attacks_degraded. Discloses threshold trigger. No annotations provided, so description adequately covers behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second specifies usage and output. No filler, front-loaded with key information.
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?
Covers purpose, usage, output format. Lacks detailed explanation of attack transforms but overall complete for a gate tool given input schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the description does not add extra parameter-specific meaning beyond what schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'stress-tests the claim against attack transforms' and labels it as the 'final robustness check', distinguishing it from sibling gate tools. The verb+resource combo is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this as the final robustness check' and specifies the fragility threshold. No explicit exclusions or alternatives named, but the context implies it's the last step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it returns JSON with verdict (PASS | MODEL_BOUND), dominance float, and reason_code. The threshold and trigger condition are clearly stated. No side effects are mentioned but the tool appears to be a pure computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely covering purpose, metric, threshold, effect, and return format. No fluff, front-loaded with the gate number and metric.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested parameter and no output schema, the description adequately covers the gate's evaluation logic, return format, and triggering condition. It doesn't detail how claim fields are used, but the schema provides that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all subfields of 'claim'. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema already does the heavy lifting.
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 detects evidence monoculture by measuring source dominance with a specific metric (max_count_from_single_source / independent_set_size) and threshold (0.50). This distinguishes it from sibling gates like veritas_evidence_gate which likely handle evidence validation differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to guard against single-source bias in evidence' and specifies the condition that triggers MODEL_BOUND. While it doesn't mention when not to use it or alternatives, the context of sibling gates implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the violation trigger (any CRITICAL finding or exposed secret) and return format (verdict with PASS/MODEL_BOUND/VIOLATION and findings). No side effects or permissions discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: purpose, usage, and return. No fluff, front-loaded with the primary action.
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?
Covers all essential aspects for a gate: what it evaluates, enforcement policy, verdict outcomes, and return type. No output schema exists, so describing the return format is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'claim', with detailed property descriptions. The description adds no additional parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (evaluates), resource (security posture), and specific aspects (SAST, secret detection, etc.). It distinguishes itself as 'Gate 8/10' among sibling VERITAS gates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to enforce zero-tolerance security policy', indicating when to use. Does not explicitly state when not to use or provide alternatives, but the context of being a security gate is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and clearly discloses traits: tamper-proof, immutable, and the exact return fields (seal_hash, chain_position, timestamp). It could also note that entries cannot be deleted or modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver maximum information with minimal words: action, purpose, and return details are front-loaded and efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and output schema, the description fully covers the tool's function, parameters, and return fields. For a simple 2-param tool, nothing essential is 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 100%, so the description adds only slight nuance (e.g., 'structured event metadata', 'outcome text to seal'), meeting the baseline but not significantly exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('appends') and resource ('SEAL... hash chain'), clearly distinguishing it from sibling tools like omega_brain_report or veritas_mis_greedy which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('to create an immutable audit record of significant events, decisions, or state changes'), but does not mention when not to use it or suggest alternatives.
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?
No annotations are provided, so the description must cover behavioral traits. It does not state whether the tool has side effects or requires specific permissions, but it clearly indicates it computes and returns a score without mentioning mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences—each serving a distinct purpose: formula, usage, and output. No redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return format. It covers input requirements and usage context, making it complete for a straightforward computational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds value by detailing nested fields expected in evidence_item (provenance, method, value, timestamp) and clarifies the role of policy_env, enriching understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the VERITAS Quality score for a single evidence item, using a specific formula. It distinguishes from siblings like veritas_evidence_gate by positioning itself as a prerequisite step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool to evaluate individual evidence quality before submitting to the evidence gate, providing clear context and a directive. It does not explicitly state when not to use alternatives, but the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool is read-only, does not modify arguments, and returns JSON with fields approved, similarity, and verdict. The description discloses the boolean and float range (0-1) and verdict values. However, it omits any mention of potential error handling, rate limits, or authentication requirements.
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 two sentences with no filler. Every sentence adds value: first defines the tool, second gives usage guidance and return format. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description provides sufficient context: purpose, usage, return format, read-only nature. It lacks details on error conditions or edge cases, but for a read-only alignment check, this is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by implying the purpose of baseline_prompt as 'task baseline describing the intended operation', but the schema already provides similar detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is a 'read-only alignment gate' that measures semantic similarity between a proposed action and task baseline. It clearly distinguishes from sibling omega_cortex_steer by specifying that this tool does not modify arguments. The verb 'check' and resource 'alignment' provide specific purpose.
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 usage context: 'Use this to check alignment before high-impact operations' and names the alternative omega_cortex_steer for automatic argument correction. This makes it clear when to use this tool vs. its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool writes persistent data, returns JSON with specific fields (session_id, stored, entry_count), and implies the operation is safe (no destructive actions mentioned). Could elaborate on overwrite/append behavior, but sufficient for a log tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with purpose, followed by usage guidance and return value. No redundant information; every sentence earns its place.
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 4 parameters with full schema descriptions, a clear usage instruction, and declared return fields, the description is complete enough for the agent. Could include error handling, but the tool is straightforward and sibling tools are analytical, making this log tool well-defined.
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?
Input schema has 100% description coverage for all 4 parameters. The description adds no new meaning beyond the schema, only restating some fields. Baseline is 3 when schema is complete, and the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a complete session record to the vault for cross-session persistence, using a specific verb and resource. It distinguishes itself from sibling omega_vault_search by noting data is retrievable via that tool, ensuring no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool at the end of a work session to record what was done, and mentions that data can be retrieved via omega_vault_search. This provides clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It describes core behaviors (parsing, canonicalization, validation, ID computation) and specifies return fields (verdict, claim_id, etc.), but lacks details on edge cases like error handling or side effects. Still, it is largely transparent for a validation gate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: function, usage instruction, and output format. It is front-loaded, efficient, and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object, no output schema), the description clearly explains the output JSON fields. However, it omits explicit handling of validation failures (e.g., VIOLATION verdict implications) and error scenarios, leaving minor completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes the 'claim' parameter and its nested fields. The description adds context about partial evaluation (only relevant fields required) but does not significantly augment parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: parsing, canonicalizing, and validating a BuildClaim's structure, with the explicit role as Gate 1/10. This distinguishes it from sibling gates by indicating it is the first step in the pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to 'Use this first to validate claim structure before running any downstream gates,' providing clear when-to-use guidance and implying alternatives are other gates for later steps.
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?
Despite no annotations, the description discloses the return JSON structure and the side effect of auto-sealing violations to the audit ledger. It could mention whether the tool is read-only or have rate limits, but it covers the key behavioral aspects.
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?
Three sentences with no wasted words: first sentence states action and signatures, second gives usage and purpose, third covers output and side effect. Each sentence earns its place.
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?
The description covers purpose, usage, output format, and side effect. It compensates for the lack of output schema by listing the return fields. However, it doesn't mention size limits or error conditions, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'text' is well-described in both the input schema and the main description, which adds examples (commit messages, incident reports) beyond the schema's brief example. This enriches the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it scans text for four specific NAFE failure signatures, with a clear verb and resource. This distinguishes it from sibling tools, which are primarily gates or execution tools, making it a unique scanning/analysis tool.
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 gives explicit context: 'Use this on commit messages, PR descriptions, or incident reports'. While it doesn't list alternatives or when not to use, the context effectively guides the agent to appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions it returns JSON with specific fields (final_verdict, gate_results, etc.), which is good. However, does not disclose potential side effects, authorization requirements, or runtime implications such as long execution time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first describes purpose and gates, second gives usage guidance and return format. No redundant or off-topic content. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 gates, large claim object), description covers purpose, usage distinction, and return structure. Lacks mention of prerequisites, order guarantees, or handling of errors. Output schema is not provided, so description compensates by listing return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add detail beyond schema parameter descriptions; it focuses on return format. Does not clarify edge cases like partial claim objects or default behavior of fail_fast.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs the full 10-gate VERITAS pipeline end-to-end for evaluating a BuildClaim, listing all gate names. Differentiates from sibling gate tools by specifying 'use individual gates for targeted checks'.
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 tells when to use this tool ('complete end-to-end evaluation') and when to use alternatives ('use individual gates for targeted checks'). Provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses return format (JSON with verdict and reason_code) and enumerates all possible reason codes. No side effects or authorization details are given, but the primary behavioral trait (validation with structured output) is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: first defines purpose and checks, second gives usage timing and return format. No wasted words, front-loaded with key information.
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?
Covers input structure, output format, and pipeline placement. Lacks explicit mention of prerequisite gates (e.g., intake), but the phrase 'after intake' implies it. Output schema is absent but description compensates with reason codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with rich descriptions, but the description adds value by noting that all claim fields are optional for partial evaluation and by listing the specific type checks performed, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool enforces type-level correctness with specific checks (unique primitives, non-empty domains, operator arity, etc.) and positions it as Gate 2/10 in a pipeline, distinguishing it from sibling gates like intake or evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this after intake to catch structural errors before evidence evaluation', providing clear sequencing context among sibling pipeline tools. Does not list exclusions but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output as a formatted text report with sections, implying it is a read-only operation. It does not disclose any potential side effects or required permissions, but the behavior is reasonably transparent for an audit report generator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two sentences: first states purpose and contents, second gives usage guidance and output structure. No superfluous words, every sentence valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one simple parameter, no output schema, and no annotations, the description covers the necessary context: what it does, when to use it, and what the output contains. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with description already covering range and default. The description does not add additional semantic information about the parameter beyond what the schema provides. With 100% schema description coverage, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a human-readable audit report with specific contents (SEAL chain entries, Cortex verdicts, vault statistics). The verb 'generates' and resource 'audit report' are specific. It also distinguishes from the sibling 'omega_brain_status' by mentioning it's for a quick health summary 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 says 'Use this to inspect the trust and governance layer; use omega_brain_status for a quick health summary instead.' This provides clear when to use and when not, with an alternative sibling tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists the return fields (vault_sessions, vault_entries, etc.) but does not explicitly state that the operation is non-destructive or read-only. However, 'health summary' strongly implies no side effects, and the return structure is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose concisely, and the second provides usage alternatives and lists return fields. Every sentence is informative and no extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently covers return values by listing all fields with types. It is complete for a simple status check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100% (vacuously). The description adds no parameter information because there are none. Per guidelines, with high coverage and no params, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a quick health summary of Omega Brain subsystems as structured JSON. It uses specific verbs and resources ('returns', 'health summary of all Omega Brain subsystems') and distinguishes itself from the sibling tool omega_brain_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: use this for a fast status check, and use omega_brain_report for a detailed audit report instead. This clearly delineates when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description carries burden well. It discloses the core behavior (block, steer, pass) based on similarity, and specifies the JSON return structure with fields. However, it does not explicitly mention side effects (e.g., logging, persistence) or whether the tool modifies state beyond returning a result.
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 single paragraph, front-loading purpose and sibling distinction, then thresholds, then return format. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description fully specifies the return format (JSON with similarity, steered_args, corrections, verdict). It covers inputs, behavior thresholds, and differentiates from sibling. All necessary context for an AI agent to use this gate tool correctly is present.
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?
Input schema has 100% description coverage – each parameter is already clearly explained. The description adds no further detail about individual parameters beyond what schema provides, but it contextualizes them within the tool's behavior. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's an alignment gate with automatic argument correction, and explicitly distinguishes from sibling omega_cortex_check by specifying when to use this tool ('Use this instead of omega_cortex_check when you want arguments auto-corrected'). The verb 'steer' and resource 'tool arguments' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit thresholds for when to use: similarity < 0.45 blocks, 0.45-0.65 steers, > 0.65 passes unchanged. Also names the alternative (omega_cortex_check) and the preferred use case (when auto-correction desired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the search type (semantic similarity), return format (JSON array with specific fields), and implies read-only behavior. Could mention idempotency or side effects but is adequate for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource, then usage and return structure. Every sentence adds value and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with well-described parameters and no output schema, the description fully specifies the return format (fragment, similarity_score, quality_score, source, tier). No gaps remain.
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?
Input schema covers 100% of parameters with descriptions. The description adds a natural-language query example and repeats the top_k range, but does not provide significant extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches a provenance RAG store using semantic similarity and returns ranked text fragments. It distinguishes itself from the sibling omega_vault_search, which does exact keyword matching.
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 'Use this for meaning-based search; use omega_vault_search instead for exact keyword matching.' This provides clear context for when to use this tool and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses use of FTS5, exact matching, and return format (JSON array with timestamps and session context). Does not mention authentication or side effects, but search is inherently read-only; still good for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and method, second gives usage guidance and output format. No redundant words, highly efficient.
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 one parameter and no output schema, the description covers purpose, method, usage guidance, and return format. It contrasts with a sibling tool. Complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains FTS5 syntax (AND, OR, NOT, quotes). The description adds 'exact keyword matching' but does not provide additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (searches), resource (vault database), and method (exact keyword matching via SQLite FTS5). Explicitly distinguishes from sibling tool omega_rag_query, 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?
Provides explicit guidance: use for precise keyword lookups, and directs to omega_rag_query for semantic search. This gives clear when-to-use and 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the governance process: alignment check, possible steering, execution, and auto-logging. It also mentions that external tools return steered_args instead of executing. However, it does not describe what happens if alignment fails or provide details on potential side effects (e.g., cost, state changes). Overall, fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence packs core purpose and behavior; second sentence provides usage guidance and return format. Every part is necessary and front-loaded. 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?
Given 3 required parameters, no output schema, and no annotations, the description covers purpose, usage, behavior, and return fields (result, cortex_verdict, seal_hash). It also distinguishes between Omega Brain and external tools. Could mention error handling or alignment failure behavior, but overall sufficient for a wrapper tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the role of each parameter in context: 'tool' is the target Omega Brain tool name, 'args' may be steered by Cortex, and 'baseline' is for alignment check. This goes beyond the schema's individual 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?
Description clearly defines tool as a Cortex-governed execution wrapper that checks alignment, steers, executes, and logs to SEAL chain. It distinguishes from siblings by specifying that it wraps Omega Brain tools (default invocation) while external tools are returned with steered_args for manual invocation. The verb 'wraps' and specific resource 'Omega Brain tools' make 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 'Use this as the default way to invoke any Omega Brain tool with full governance' and clarifies that external tools are not executed but returned for manual invocation. This provides clear when-to-use and when-not-to-use guidance, effectively differentiating from sibling tools like omega_ingest or omega_rag_query.
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?
Describes computation of independence, agreement, quality scores, and output format (verdict, reason_code). No annotations provided, so description carries full burden; lacks detail on side effects or prerequisites but is sufficient for a stateless evaluation tool.
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?
Three sentences, front-loaded with purpose, 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?
Covers purpose, usage, and output; with no output schema, it lists verdict and reason codes. Could mention the claim structure more but schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context by explaining that the tool checks thresholds and provides output meanings; schema already has 100% coverage with detailed parameter descriptions, so the description complements rather than replaces.
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?
States specific verb ('evaluates evidence sufficiency'), resource ('critical variables'), and distinguishes from sibling tools by naming alternatives for individual calculations.
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 tells when to use this tool ('to verify thresholds') and when to use alternatives ('veritas_compute_quality or veritas_mis_greedy'), providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully explains behavior: it validates under closed-world rules, notes the absorbing state, and specifies the return format (allowed boolean and reason string). This is fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then usage guidance and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies the return fields (allowed, reason). It also covers the key rule about TERMINAL_SHUTDOWN absorbing, making it sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds overall context (closed-world rules, absorbing state) but does not provide additional semantics for individual parameters beyond the schema's own 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 validates CLAEG state transitions under closed-world rules, with a specific verb (validates) and resource (state transition). It also briefly distinguishes this as the validation step before changing state.
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 using this tool 'before changing system operational state' and highlights the important rule that TERMINAL_SHUTDOWN is absorbing. This provides clear context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns JSON with specific fields (independent_set, independent_count, total_items, agreement). While it doesn't explicitly state that the tool is non-destructive or read-only, the context implies it's a computational algorithm with no side effects. A slight gap exists in not mentioning safety traits, but overall it's transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage guidelines, then output format. No wasted words; every sentence adds value. Very efficiently structured.
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 one required parameter, no output schema, and no annotations, the description fully covers the tool's purpose, usage context, and return format. It is complete and leaves no critical gaps for an AI agent to understand when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% with one parameter, but the description adds meaning by specifying that evidence items should have fields like id, variable, value, timestamp, method, provenance, and optional dependencies. This goes beyond the generic schema description and helps the agent understand expected structure.
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 runs the MIS_GREEDY algorithm to find the maximum independent set of evidence items with constraints (shared source, chain, dependency, same-protocol-within-24h). It also distinguishes itself from siblings like veritas_compute_quality and veritas_evidence_gate by explaining when to use each, making the purpose very specific and well-differentiated.
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 'Use this to check evidence independence before submitting to the evidence gate; use veritas_compute_quality for individual quality scores.' This provides clear context on when to use this tool and when to use an alternative, which is excellent guidance for an AI agent.
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:

[![omega-brain-mcp MCP server](https://glama.ai/mcp/servers/VrtxOmega/omega-brain-mcp/badges/card.svg)](https://glama.ai/mcp/servers/VrtxOmega/omega-brain-mcp)

Score Badge

Copy to your README.md:

[![omega-brain-mcp MCP server](https://glama.ai/mcp/servers/VrtxOmega/omega-brain-mcp/badges/score.svg)](https://glama.ai/mcp/servers/VrtxOmega/omega-brain-mcp)

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/VrtxOmega/omega-brain-mcp'

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