Pay-per-call safety guards for AI agents: injection, tool-call, signing, secret, x402-trust.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 7 of 7 tools scored. Lowest: 2.9/5.
Each tool targets a distinct security domain: prompt injection, secret scanning, code review, transaction safety, tool call safety, and x402 trust audit. Despite overlapping themes, their purposes are clearly differentiated by detailed descriptions.
Tool names use a mix of patterns like verb-noun (inject-guard, sign-guard), noun-verb (secret-scan), and noun-noun (pr-summary, x402-trust-audit). The consistent use of lowercase and hyphens helps readability, but the lack of a uniform verb_noun pattern lowers consistency.
Seven tools is a reasonable number for a security-focused server covering multiple guardrails and utilities. Each tool earns its place without overwhelming the agent.
The set covers core agent safety areas: input guardrails, secret detection, code review, transaction verification, and tool call safety. The inclusion of a PR summary tool is slightly out of scope, but overall coverage is strong with minor gaps like audit logging.
inject-guardAInspectUntrusted-content guardrail for agents: submit a blob of text you are about to feed to your own LLM (scraped web content, a tool result, another agent's message) and get a machine-enforceable verdict - is this a prompt-injection / jailbreak / data-exfiltration / tool-hijack attempt? Returns a risk level, the detected classes with spans, the unicode obfuscation it found (zero-width, bidi-override, tag-chars, homoglyphs), and a SANITIZED copy safe to feed onward. Hybrid: a deterministic, uninjectable pattern engine (authoritative) plus an LLM classifier that can only raise the risk, never clear a flag. Detection of known injection classes - not a proof of safety. [security; up to 15c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The untrusted text to scan before you feed it to your LLM. | |
| context | No | Optional: where the content came from (url, tool name, sender) - context only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the tool's hybrid approach (deterministic pattern engine plus LLM classifier) and its behavioral traits: it can only raise risk, never clear a flag. It also states limitations ('not a proof of safety') and discloses cost. No annotations provided, so the description alone provides full transparency.
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 is detailed and informative, but slightly verbose with phrases like 'Hybrid: a deterministic, uninjectable pattern engine (authoritative) plus an LLM classifier...' that could be streamlined. However, every sentence adds value, and the structure is logical.
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?
With no output schema, the description fully covers the return values: risk level, detected classes with spans, unicode obfuscation details, and a sanitized copy. It also mentions limitations and cost, making it complete for an AI agent to understand the tool's capabilities and response.
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 reinforces the meaning of 'content' as untrusted text and 'context' as provenance information. While it doesn't add new technical details beyond the schema, it contextualizes their usage effectively.
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: to scan untrusted text for prompt injection and related attacks before feeding it to an LLM. It lists specific threat classes (prompt-injection, jailbreak, data-exfiltration, tool-hijack) and distinguishes itself from siblings like secret-scan or secure-code-review.
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 tells when to use the tool: 'submit a blob of text you are about to feed to your own LLM' and gives examples of sources (scraped web content, tool result, another agent's message). It implies when not to use it (not a general-purpose security scanner) and differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pr-summaryBInspectTurn a git diff into a clear PR description or release notes. [dev-tools; up to 30c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| diff | Yes | Unified git diff to summarise | |
| style | No | e.g. conventional, changelog, executive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose that this is an AI call, potential latency, token limits, or what happens with large diffs. The cost mention is useful but insufficient for behavioral transparency.
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 is very short and to the point, but could be structured with separate sentences for purpose and usage. The bracketed cost info is concise but fits. Minimal waste, but slightly too terse.
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?
The tool has no output schema and moderate complexity (summarizing a diff). The description gives a high-level idea of output but does not explain return format, length, or potential failure modes. Adequate but not complete.
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 descriptions for both parameters. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate since the schema already documents the parameters adequately.
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 converts a git diff into a PR description or release notes. The verb 'turn' is somewhat generic but the resource is well-defined. Sibling tools are all security-focused, so this distinguishes itself effectively.
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?
No guidance on when to use this tool vs alternatives. The bracketed cost note does not provide usage context. There is no mention of prerequisites, exclusions, or related tools for fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secret-scanAInspectLeaked-credential guardrail for agents: submit a blob you are about to commit, log, post, or hand to another tool (a diff, a config, an .env, an LLM output) and get a machine-enforceable verdict - does it contain a live secret? Detects cloud keys (AWS), VCS tokens (GitHub/GitLab), provider API keys (Stripe, OpenAI, Anthropic, Google, Slack), private-key blocks, JWTs, and credentials embedded in URLs, plus high-entropy key=value assignments. Returns a risk level, the detected classes with a MASKED locator (never the secret itself, so the verdict cannot re-leak), and a REDACTED copy safe to emit onward. Deterministic, sub-second, never fetches. Detection of known secret formats - not a proof of cleanliness. [security; up to 200c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The text to scan for leaked secrets (diff, config, .env, log line, LLM output). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: deterministic, sub-second, no network fetches, returns masked locators (never the secret), redacted copy, and cost (200c/call). This covers safety, performance, and data handling comprehensively.
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 is front-loaded with purpose and usage, then details detection capabilities, output, and properties. It is efficient—every sentence adds information 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?
Despite lacking an output schema, the description explains the return values (risk level, detected classes with masked locator, redacted copy) and other traits (determinism, cost). It is fully sufficient for an agent to understand inputs and outputs.
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 schema includes a rich description for 'content' that matches the main description almost verbatim. Since schema_description_coverage is 100%, the description adds no extra value beyond what the schema already provides, resulting in baseline 3.
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 identifies the tool as a 'Leaked-credential guardrail for agents' and specifies the action (submit a blob, get a verdict). It lists specific detection targets and distinguishes itself from sibling guards by name and function.
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 provides concrete scenarios for use (about to commit, log, post, hand to another tool) and mentions limitations ('not a proof of cleanliness'). However, it does not explicitly compare to sibling tools or state 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.
secure-code-reviewCInspectSecurity review of a code snippet or diff. Returns structured findings (severity, CWE, location, remediation). [security; up to 75c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Source code or unified diff to review | |
| context | No | Optional context about the code | |
| language | No | Language hint, e.g. typescript, python |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states it returns structured findings and mentions pricing (75c/call), lacking details on side effects, permissions, or behavioral boundaries.
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 is a single, efficient sentence with a bracketed note, front-loading the purpose without any 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?
For a security review tool, the description is minimal; it does not explain coverage scope, false positives, or limitations, and lacks an output schema to clarify return structure.
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 the description adds no significant value beyond the schema's parameter descriptions, maintaining the baseline score.
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 performs a security review on code snippets or diffs and returns structured findings, which distinguishes it from sibling tools like secret-scan or inject-guard that focus on specific security aspects.
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 provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sign-guardAInspectPre-sign safety oracle for agent wallets: submit the transaction or EIP-712 message you are about to sign and get a machine-enforceable verdict. Decodes the calldata/typed-data, flags the drainer toolkit (unlimited approvals, setApprovalForAll, permit/permit2 + EIP-3009 to an unexpected party, transferFrom draining an unnamed account, ownership transfer, raw ETH to a stranger), and binds the decoded action to your stated intent - only a fully pinned, clean action is auto-sign-safe. Fails closed: an undecodable on-chain call is cautioned and an unrecognized off-chain signature grant is blocked. Deterministic, sub-second, no endpoint fetch. It vouches that the action matches what you said; it does NOT vouch that a counterparty is trustworthy. [security; up to 200c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| tx | No | An EVM transaction you are about to sign. | |
| context | No | Optional free-form context. | |
| expected | No | Your stated intent. Supplying it lets the verdict BIND the action; only a fully bound, clean action is auto-sign-safe. For an allowance, you MUST supply maxAmount; for a transferFrom, supply `from`. | |
| typedData | No | An EIP-712 message you are about to sign (the off-chain drainer surface: permit, Permit2, EIP-3009). { domain, types, primaryType, message }. | |
| spendPolicy | No | Optional buyer spend policy (context only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: decodes calldata, flags drainer patterns, binds to intent, auto-sign only for clean pinned actions, fails closed, deterministic, sub-second, no endpoint fetch. No contradictions found.
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 is efficiently written—each sentence conveys critical information with no filler. It front-loads the purpose and logically flows through capabilities, constraints, and limitations.
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?
Input parameters are well-covered. The lack of an output schema means the agent must infer the verdict structure, though the description gives some hints ('auto-sign-safe', 'cautioned', 'blocked'). A slightly more detailed output format would elevate completeness further.
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%, but the description adds value by explaining the 'expected' parameter's role (binding action for auto-sign) and highlighting required fields (maxAmount for allowance, from for transferFrom). This goes beyond schema descriptions.
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 is a 'Pre-sign safety oracle for agent wallets' that decodes transactions/typed-data and returns a verdict. It distinguishes from siblings like inject-guard or secret-scan by focusing on pre-sign verification, making its purpose specific and unambiguous.
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 explains when to use the tool (submit tx or EIP-712 message before signing) and what to expect (fails closed, no counterparty trust). It lacks explicit exclusions or comparisons to alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tool-call-guardAInspectPre-execution safety oracle for agent actions: submit the tool call you are about to run (shell, http, sql, file, code, env) plus your stated intent, and get a machine-enforceable verdict before you execute it. Decodes what the call does, flags the danger toolkit (rm -rf, reverse shell, curl|sh, SSRF to cloud metadata, credential reads, DROP/DELETE-without-WHERE, path traversal, dynamic eval), and binds it to your intent (allowedHosts/allowedPaths/readOnly/noNetwork) - only a fully pinned, clean, intent-matched call is auto-exec-safe. Hybrid: a deterministic, uninjectable detector engine (authoritative) plus an LLM classifier that can only raise the risk. Fails closed. Detection of known-dangerous patterns, not a proof of safety; it never executes the call. [security; up to 8c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| call | Yes | The tool call you are about to execute. | |
| intent | No | What this call is for (natural language). Used by the classifier for intent-mismatch. | |
| context | No | Optional: where the task/input came from (untrusted source label). | |
| expected | No | Machine-checkable constraints. Supplying them lets the verdict BIND the call; only a positively-scoped, satisfied call is auto-exec-safe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the hybrid detector engine, failure modes (fails closed), dangerous patterns flagged, and that it never executes the call. With no annotations, it carries full burden and does well, though it omits latency or output structure.
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 is a single paragraph that front-loads the main purpose and adds specific details. It is somewhat lengthy but each sentence is informative, avoiding 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?
No output schema exists, so the description should explain the verdict structure. It mentions 'machine-enforceable verdict' and 'auto-exec-safe' but does not specify the response format or fields, leaving some ambiguity for an agent.
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. The description mentions the call and intent parameters but adds no new meaning beyond the schema's own descriptions for each property.
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 title 'tool-call-guard' and description clearly state the tool is a pre-execution safety oracle that accepts a tool call and intent, returning a verdict. It distinguishes itself from siblings like inject-guard by focusing on dangerous patterns across multiple action types.
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 says to use this tool before executing a call, and mentions it provides a machine-enforceable verdict. However, it does not state when not to use it or list alternatives, though the sibling tools imply different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402-trust-auditAInspectVet an x402 counterparty before settling USDC: scores the advertised payment requirements AND (when supplied) the EIP-3009 authorization you are about to sign. Returns a machine-enforceable trust verdict (per-entry scores, coverage-honest trustScore, spend-constraint + tamper-evident fingerprint) for buyer agents and wallet/spend-policy layers. No endpoint fetch. [security; up to 200c/call]
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional free-form context. | |
| expected | No | Optional caller expectations. | |
| endpointUrl | No | Resource URL being paid (context only; never fetched). | |
| spendPolicy | No | Optional buyer spend policy to evaluate against and to pin facilitators. | |
| paymentPayload | No | The UNSIGNED EIP-3009 authorization the buyer is about to sign: { authorization|message: {from,to,value,validAfter,validBefore,nonce}, domain: {name,version,chainId,verifyingContract} }. Lets the audit bind the menu to the actual charge (server-enforced to/value/verifyingContract/chainId). Omit to vet requirements only - but then the verdict is never auto-settle-safe. | |
| serverMetadata | No | Optional server metadata the caller already holds (context only; not fetched). | |
| paymentRequirements | Yes | The x402 payment requirements from the counterparty: the 402 `accepts` array, or a single object. | |
| selectedOptionIndex | No | Index in the accepts array the buyer intends to settle (default 0). The verdict is scoped to it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool does not fetch endpoints, returns a structured verdict, and has a cost. It remains silent on error conditions, permissions, and side effects, but covers key behavioral traits sufficiently.
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 is information-dense but well-structured, opening with the main purpose. It could be slightly more concise (e.g., 'per-entry scores...' details), but every sentence adds value. Front-loaded with key actions and constraints.
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 8 parameters and no output schema, the description explains parameter roles but lacks detail on the exact output format (beyond 'per-entry scores...'), error handling, and edge cases. The tool's complexity demands more thorough completeness for optimal agent 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% (baseline 3). The description adds meaning by explaining that `paymentPayload` is an unsigned EIP-3009 authorization, `endpointUrl` is never fetched, and `selectedOptionIndex` scopes the verdict. This goes beyond the schema's generic descriptions.
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 action ('Vet an x402 counterparty before settling USDC'), resource (payment requirements and EIP-3009 authorization), and output (trust verdict). It is distinct from siblings like secure-code-review or secret-scan, which focus on code security, not trust evaluation.
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 specifies the primary use case (before settling USDC) and includes contextual clues like 'security; up to 200c/call' and 'No endpoint fetch'. However, it does not explicitly state when not to use the tool or mention alternative approaches, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
