Skip to main content
Glama
oathe-ai
by oathe-ai

oathe-mcp

MCP server for Oathe AI security audits. Check trust scores before installing MCP servers, plugins, or AI agent skills.

Quick Start

npx oathe-mcp

No API key required. No configuration needed.

Related MCP server: aegis

MCP Client Configuration

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "oathe": {
      "command": "npx",
      "args": ["-y", "oathe-mcp"]
    }
  }
}

Claude Code

claude mcp add oathe -- npx -y oathe-mcp

Tools

submit_audit

Submit a GitHub or ClawHub URL for a security audit.

{ "skill_url": "https://github.com/owner/repo" }

Returns audit_id to track progress. Rate limited: one submission per 60 seconds per IP.

check_audit_status

Check the status of a submitted audit.

{ "audit_id": "uuid-from-submit" }

Poll every 5 seconds. Terminal statuses: complete, failed.

get_audit_report

Get the full security audit report for a repository.

{ "owner": "anthropics", "repo": "claude-code" }

Returns trust score, verdict, findings, category scores, and recommendation.

get_skill_summary

Get a lightweight summary (score + verdict) without full findings.

{ "owner": "anthropics", "repo": "claude-code" }

Returns score, verdict, recommendation, and finding counts.

search_audits

Search completed audits by verdict or minimum trust score.

{ "verdict": "SAFE", "min_score": 80, "sort": "trust_score", "order": "DESC" }

Returns up to 100 results.

Configuration

Environment Variable

Default

Description

OATHE_API_BASE

https://audit-engine.oathe.ai

Override the API base URL

Setting an invalid OATHE_API_BASE will produce a clear error at startup.

License

MIT

Available Tools

5 tools
check_audit_statusA

Check the status of an Oathe security audit submitted via submit_audit. Wait 90 seconds after submission before first poll, then poll every 10 seconds until status is "complete" or "failed". Statuses: queued, scanning, analyzing, summarizing, finalizing, complete, failed. Terminal statuses: complete, failed. When complete, the response includes the full audit report with trust score, verdict, and findings.

ParametersJSON Schema
NameRequiredDescriptionDefault
audit_idYesUUID returned by submit_audit

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Fully explains polling behavior, status progression, and that completion includes full report. No annotations, so description carries burden and does so completely.

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-loaded with purpose, then essential details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all aspects for a polling status check: timing, status meanings, terminal states, and return content. No output schema but description explains what's returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter 'audit_id' is well-described as UUID from submit_audit. Schema coverage 100% and description adds necessary context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks the status of an Oathe security audit and references the submission tool. It differentiates from siblings like 'submit_audit' and 'get_audit_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?

Provides explicit polling instructions: wait 90 seconds, poll every 10 seconds. Lists all statuses and terminal ones, making usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_audit_reportA

Get the full behavioral security audit report for a GitHub repository. Use this to review all findings before installing a third-party MCP server, plugin, or tool. Returns the latest completed audit with trust score, verdict, findings, category scores, and recommendation. Use get_skill_summary for a quick safety check instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub repository owner (e.g. "anthropics")
repoYesGitHub repository name (e.g. "claude-code")

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description describes return content (trust score, verdict, etc.) but does not disclose behavioral traits like authentication requirements, rate limits, or non-destructive nature beyond the implicit 'get'.

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 with purpose first, no redundant words, and a clear alternative suggestion. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully enumerates the return values (trust score, verdict, findings, category scores, recommendation). Covers all needed context for a moderate-complexity 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?

Schema coverage is 100% with clear descriptions for both parameters. The description adds no meaning beyond the schema, meeting baseline expectation.

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 'Get', resource 'full behavioral security audit report', and context 'for a GitHub repository'. Distinct from sibling tool 'get_skill_summary'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'review all findings before installing a third-party MCP server, plugin, or tool'. Also suggests alternative 'get_skill_summary' for quick checks. Lacks explicit when-not conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_skill_summaryA

Check if a GitHub repository is safe to install as an MCP server or AI agent skill. Returns trust score, verdict, and recommendation from Oathe's behavioral security audit. Use this BEFORE installing any third-party tool — it's the quickest safety check. For the full report with all findings, use get_audit_report instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub repository owner (e.g. "anthropics")
repoYesGitHub repository name (e.g. "claude-code")

TDQS

A4/5.0
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 that the tool returns a trust score, verdict, and recommendation, but does not explain the computation or range of these outputs. Lack of behavioral details like side effects or read-only nature is somewhat mitigated by the tool's obvious safety-check intent.

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 consists of two concise sentences: the first states the purpose and output, the second provides usage guidance and a sibling reference. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description is fairly complete, covering purpose, usage, and sibling tool. The absence of an output schema is compensated by describing the return values (trust score, verdict, recommendation). Minor improvement could be adding detail on the trust score scale, but not critical.

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 covers all parameters with clear descriptions (owner and repo with examples). The description does not add extra parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: checking if a GitHub repository is safe to install as an MCP server or AI agent skill, returning a trust score, verdict, and recommendation. It also distinguishes itself from the sibling tool get_audit_report by noting it's the quickest safety check.

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 instructs to use the tool before installing any third-party tool and positions it as the quickest safety check. It also directs users to get_audit_report for the full report, providing clear guidance on when to use the sibling. However, it does not explicitly state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_auditsA

Search all completed Oathe behavioral security audits. Find which skills have been audited, filter by verdict or minimum trust score. Returns up to 100 completed audits. Use this to check if a skill has already been audited before submitting a new audit.

ParametersJSON Schema
NameRequiredDescriptionDefault
verdictNoFilter by audit verdict
min_scoreNoMinimum trust score (0-100)
sortNoSort field (default: created_at)
orderNoSort order (default: DESC)

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that only completed audits are returned and caps at 100 results. However, it lacks details on pagination for larger result sets, authentication requirements, or other side effects. While adequate, key behavioral specifics are missing.

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?

Four concise sentences with no redundancy. The first sentence states purpose, second details filtering, third specifies result limit, fourth gives usage tip. Well-structured and front-loaded.

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 no output schema, the description covers what is returned (up to 100 completed audits, skill information), but does not specify exact fields or structure of results. It adequately supports the search use case but leaves some gaps for a fully self-contained description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context like 'filter by verdict or minimum trust score' and ties usage to checking prior audits, but does not elaborate beyond schema definitions for sort and order. Overall, it adds moderate contextual 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 clearly states the tool searches completed audits, with filtering by verdict and min_score, and returns up to 100 results. It effectively differentiates from sibling tools (check_audit_status, get_audit_report, etc.) by focusing on listing/filtering.

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 if a skill has already been audited before submitting a new audit.' This provides clear when-to-use guidance and implicitly advises against using it for other purposes like submitting or viewing individual reports.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_auditA

Submit a third-party skill for a behavioral security audit before installing it. Accepts any GitHub or ClawHub URL. Returns an audit_id to track progress. Rate limited: one submission per 60 seconds per IP. Returns existing audit_id if URL was already scanned (deduplicated: true). Use check_audit_status to poll for results.

ParametersJSON Schema
NameRequiredDescriptionDefault
skill_urlYesGitHub or ClawHub URL of the skill/repo to audit
notification_emailNoOptional email to notify when audit completes
force_rescanNoBypass deduplication and force a fresh audit

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description fully covers: URL types, return value, rate limit, deduplication, and force rescan option. All relevant behaviors disclosed.

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?

Five dense sentences, each adding distinct info. No wasted words. Front-loaded with purpose.

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 return value, dedup, rate limit, and sibling tool. Lacks error handling details but sufficient for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining deduplication context for force_rescan and rate limit (not in 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?

Clearly states verb 'submit' and resource 'third-party skill for behavioral security audit'. Distinguishes from siblings like check_audit_status.

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 indicates when to use ('before installing'), mentions rate limiting, deduplication, and directs to sibling tool for polling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.1
    • First observedcheck_audit_status
    • First observedget_audit_report
    • First observedget_skill_summary
    • First observedsearch_audits
    • First observedsubmit_audit

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: check_audit_status polls for audit progress, get_audit_report retrieves a full report, get_skill_summary provides a quick safety check, search_audits finds existing audits, and submit_audit initiates a new audit. The descriptions explicitly differentiate tools like get_audit_report vs. get_skill_summary, preventing misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: check_audit_status, get_audit_report, get_skill_summary, search_audits, and submit_audit. The naming is predictable and readable throughout, using clear verbs like 'check', 'get', 'search', and 'submit' paired with relevant nouns.

Tool Count5/5

With 5 tools, this server is well-scoped for its purpose of behavioral security audits for MCP servers. Each tool earns its place by covering distinct aspects of the audit lifecycle: submission, status checking, quick summary, full report retrieval, and search. The count is neither too thin nor excessive for the domain.

Completeness5/5

The tool set provides complete coverage for the security audit domain, including all key operations: submit an audit, check its status, get a quick summary, retrieve a full report, and search existing audits. There are no obvious gaps; agents can navigate the entire workflow from initiation to review without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    C
    quality
    B
    maintenance
    Security scanner and MCP server that catches dangerous patterns in MCP servers and AI agent projects, such as leaked secrets, shell execution, and prompt-injection text. Runs as both a CLI and MCP server with CI-friendly severity gates.
    2
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Audits MCP server configurations for security risks including capability inventory, SSRF, prompt injection, and drift detection. Works in read-only mode and can also be used as an MCP server to let AI agents audit their own attack surface.
    4
    MIT

Latest Blog Posts

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/oathe-ai/oathe-mcp'

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