oathe-mcp
OfficialAllows 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
MCP server for Oathe AI security audits. Check trust scores before installing MCP servers, plugins, or AI agent skills.
Quick Start
npx oathe-mcpNo 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-mcpTools
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 |
|
| Override the API base URL |
Setting an invalid OATHE_API_BASE will produce a clear error at startup.
License
MIT
Available Tools
5 toolscheck_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.
| Name | Required | Description | Default |
|---|---|---|---|
| audit_id | Yes | UUID returned by submit_audit |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | GitHub repository owner (e.g. "anthropics") | |
| repo | Yes | GitHub repository name (e.g. "claude-code") |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | GitHub repository owner (e.g. "anthropics") | |
| repo | Yes | GitHub repository name (e.g. "claude-code") |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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.
5 tool updates
v0.1.1- First observed
check_audit_status - First observed
get_audit_report - First observed
get_skill_summary - First observed
search_audits - First observed
submit_audit
TDQS
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.
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.
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.
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
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
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
- ArcjetOAuthcom.arcjet
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Related MCP Servers
- AlicenseAqualityFmaintenanceSecurity scanner for AI agent packages that enables AI agents to audit MCP servers and packages for vulnerabilities, prompt injection, and supply chain attacks.5293AGPL 3.0
- FlicenseNot gradedqualityBmaintenanceMCP server for auditing AI agent permissions and access by scanning for the trifecta of credentials, injection, and reach without heavy infrastructure.-
- AlicenseCqualityBmaintenanceSecurity 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.21MIT
- AlicenseNot gradedqualityAmaintenanceAudits 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.4MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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