Which integrations are available for this server?

Allows for the submission of GitHub repositories for security audits and the retrieval of security reports, trust scores, and vulnerability findings for GitHub-hosted projects.

oathe-mcp

Official

by oathe-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

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

Name	Required	Description	Default
`audit_id`	Yes	UUID 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

Name	Required	Description	Default
`owner`	Yes	GitHub repository owner (e.g. "anthropics")
`repo`	Yes	GitHub 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

Name	Required	Description	Default
`owner`	Yes	GitHub repository owner (e.g. "anthropics")
`repo`	Yes	GitHub 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

Name	Required	Description
`verdict`	No	Filter by audit verdict
`min_score`	No	Minimum trust score (0-100)
`sort`	No	Sort field (default: created_at)
`order`	No	Sort 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

Name	Required	Description
`skill_url`	Yes	GitHub or ClawHub URL of the skill/repo to audit
`notification_email`	No	Optional email to notify when audit completes
`force_rescan`	No	Bypass 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.

5 tool updatesv0.1.1Feb 24, 2026
- First observedcheck_audit_status
- First observedget_audit_report
- First observedget_skill_summary
- First observedsearch_audits
- First observedsubmit_audit

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-09-09 22:37 across 5 tools

Disambiguation5/5

Each tool targets a distinct action: submitting, checking status, retrieving a fast summary, retrieving a full report, and searching. Even the two report-style tools are clearly separated by their descriptions, which explicitly tell when to use each.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: submit_audit, check_audit_status, get_audit_report, get_skill_summary, search_audits. The pattern is uniform and easy to predict.

Tool Count5/5

The 5 tools are well-scoped for a focused security-audit service: submission, status tracking, report retrieval, quick check, and historical search. No tool feels redundant or missing.

Completeness5/5

The tool surface fully covers the audit lifecycle: submit an audit, poll for status, retrieve the report or a quick summary, and search past audits. There are no obvious dead ends or critical gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
StackResolve C
dev.stackresolve
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Developer Tools
151
ArcjetOAuth
com.arcjet
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Security AI & Machine Learning Code Execution
21

Related MCP Servers

AgentAudit
Security Code Analysis Testing & QA Tools
agentaudit-dev
A
license
A
quality
F
maintenance
Security scanner for AI agent packages that enables AI agents to audit MCP servers and packages for vulnerabilities, prompt injection, and supply chain attacks.
Updated 3 months ago (2026-06-12 20:10 UTC)
5
8 npm
3
AGPL 3.0
aegis
Security Code Analysis Penetration Testing
cognis-digital
F
license
Not graded
quality
C
maintenance
MCP server for auditing AI agent permissions and access by scanning for the trifecta of credentials, injection, and reach without heavy infrastructure.
Updated 18 days ago (2026-08-29 10:45 UTC)
-
MCP Shield
Security Code Analysis CI/CD & DevOps
rob925
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.
Updated 2 months ago (2026-07-10 14:06 UTC)
2
1
MIT
mcp-audit
Security Penetration Testing
saagpatel
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.
Updated 2 days ago (2026-09-14 00:21 UTC)
4
MIT

Appeared in Searches

A CLI tool for auditing MCP (Model Context Protocol) configurations or servers