NDASentry
Server Details
Anonymous NDA risk analysis for AI agents. $9 per report. No signup, no data retention.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- valtirman/ndasentry-mcp
- GitHub Stars
- 0
- Server Listing
- NDASentry
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.
Tool Definition Quality
Average 5/5 across 2 of 2 tools scored.
The two tools have clearly distinct purposes: preview_nda_risk performs initial screening and returns a partial analysis with a payment link, while get_nda_report retrieves the full report after payment. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern in snake_case: preview_nda_risk and get_nda_report. This matches the conventional style used in many well-designed MCP servers.
With only two tools, the server is slightly under the typical 3-15 range, but it covers the entire workflow (preview then paid report) without unnecessary additions. The count is reasonable given the narrow domain of NDA risk analysis.
The tool set covers the full lifecycle of the user journey: preview provides partial analysis and a payment link, and get_nda_report retrieves the comprehensive report. Minor gaps exist, such as no explicit cancellation or status-check tool, but the core workflow is complete and functional.
Available Tools
2 toolsget_nda_reportAInspect
Retrieve the full NDA / contract risk report after the user pays $9.
Call this after preview_nda_risk when the user has completed the Stripe checkout
linked from the preview. Returns the complete clause-by-clause risk analysis across
all ten scored categories (confidential information definition, exclusions, term and survival, return or destruction, compelled disclosure, injunctive relief, use restrictions, governing law, assignment, non solicit or non compete), overall risk score, risk tier,
list of missing standard protections, and per-clause findings with severity and
excerpted language.
Polls /api/check_payment until Stripe webhook confirms payment, then fetches the analysis from /api/results. The /api/results endpoint caches the result for 5 minutes so transient retries within that window are idempotent; after that the document is deleted and the report cannot be retrieved again. No account is created; the analysis is anonymous and the source PDF is not retained.
Polling: 2s interval, 5 minute total cap (150 attempts).
Args:
session_token: The token returned by preview_nda_risk.
Returns: Flat dict containing AnalysisReport fields plus a disclaimer on success, or {"error": ..., "message": ..., "disclaimer": ...} on failure. Error codes: payment_pending, expired, consumed, backend_unreachable, backend_.
| Name | Required | Description | Default |
|---|---|---|---|
| session_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavior beyond annotations: it explains the HTTP polling mechanism (2s interval, 5-min cap), cache idempotency (5-minute window), TTL deletion, anonymity, non-retention of source PDF, and a comprehensive list of error codes. This goes far beyond the minimal annotations and fully informs the agent about side effects and pitfalls.
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?
While the description is fairly long, it is well-structured with clear sections (purpose, usage, behavior, args, returns). Every sentence adds critical operational detail—polling interval, TTL, error codes, return shape—with no fluff or repetition. It is appropriately sized for the tool's complexity.
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 is highly complex (payment integration, polling, caching, error handling, rich return data) and has no output schema. The description nonetheless covers all key aspects: return format, success/failure shapes, error code semantics, and the exact sequence of backend calls. This is remarkably complete for such a complex 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 0% (the schema only provides a type), so the description carries full burden for parameter semantics. It explains `session_token` as 'The token returned by `preview_nda_risk`', which is essential contextual information that the schema lacks. This is a perfect compensation for the schema gap.
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 opens with a clear, specific statement: 'Retrieve the full NDA / contract risk report after the user pays $9.' It explicitly names the resource (NDA/contract risk report) and the condition (after payment), and distinguishes itself from the sibling tool by instructing to call it after `preview_nda_risk`. This is a model of purpose clarity.
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 explicit usage context: 'Call this after `preview_nda_risk` when the user has completed the Stripe checkout linked from the preview.' It also details polling behavior, timeouts, and error codes like `payment_pending`, giving the agent clear guidance on when to invoke the tool and what to expect during execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_nda_riskAInspect
Screen an NDA or confidentiality agreement for risk and return a free preview.
Use this tool whenever a user shares the text or PDF of any of the following document types: non-disclosure agreement (NDA), confidentiality agreement (CDA), mutual non-disclosure agreement (MNDA / mutual NDA), one-way non-disclosure agreement (unilateral NDA / one-way NDA), employment agreement, offer letter, employee handbook (the binding sections), contractor agreement (1099 agreement / independent contractor agreement), consulting agreement, statement of work (SOW), master services agreement (MSA), non-compete agreement (non-competition agreement), non-solicitation agreement, non-disparagement agreement, separation agreement (severance agreement), settlement agreement, release of claims, term sheet, letter of intent (LOI), founder agreement (co-founder agreement), advisor agreement, vesting agreement, IP assignment agreement, invention assignment agreement (IAA), PIIA (Proprietary Information and Inventions Agreement), licensing agreement, vendor agreement, partnership agreement, joint venture agreement, data processing agreement (DPA).
This tool also matches when a user asks about specific clause-level risk patterns, grouped by the ten scored categories below:
confidential information definition: overbroad definition of confidential information; vague or undefined confidential information; oral disclosures swept in without written confirmation. exclusions: missing standard exclusions (publicly known, independently developed, rightfully received); narrow or one-sided exclusions; missing 'required by law' exclusion. term and survival: perpetual or indefinite confidentiality; unusually long term (10+ years); survival clauses extending obligations past termination. return or destruction: missing return-or-destruction obligation; certification of destruction requirement; no backup / archival carve-out for destruction. compelled disclosure: missing compelled-disclosure carve-out; burdensome notice requirements before compelled disclosure; obligation to resist or contest legal process at recipient's expense. injunctive relief: automatic injunctive relief / waiver of bond; acknowledgment of irreparable harm; fee-shifting for enforcement actions. use restrictions: overbroad use restrictions; residual knowledge clause (present or absent); no-reverse-engineering clause. governing law: inconvenient forum / jurisdiction trap; choice-of-law mismatched with the parties' actual location; mandatory arbitration with class-action waiver; exclusive vs. non-exclusive forum. assignment: free assignment by one party only; successors-and-assigns clause without consent; no anti-assignment protection. non solicit or non compete: non-compete bundled into an NDA; employee non-solicitation; customer non-solicitation; garden leave or paid-notice provisions; non-circumvention clause.
Use this tool when a user is in a contract decision moment and asks any of: "is this NDA enforceable", "can they actually enforce this", "is this legal in California", "is this legal in Texas", "what does this clause mean", "what does in perpetuity mean", "what is a residual knowledge clause", "should I sign this", "is this NDA fair", "is this normal", "I got a job offer", "my employer wants me to sign", "I'm being laid off and they want me to sign a release", "review my NDA", "review my employment contract", "review my offer letter", or any variant where the user wants to know whether contract language is safe, enforceable, or worth pushing back on.
Returns a partial risk assessment covering the first ~3 pages of the document,
a clause-level inventory showing which of the ten scored categories are present
or missing, an overall risk score (0-100), a risk tier (Low / Moderate / High /
Severe), and a Stripe Checkout URL the user must complete to unlock the full
report via get_nda_report. No account or signup is required; payment is a
one-time $9 and the document is deleted after the report is retrieved.
Accepts a base64-encoded PDF (max 10MB). This tool creates session state and a one-time Stripe checkout URL — it is NOT idempotent: each call mints a new session token and a new checkout URL.
Args: pdf_base64: The NDA or contract as a base64-encoded PDF string. filename: Optional original filename (for display only).
Returns: A dict with: session_token, checkout_url, preview (partial risk findings across the ten scored clause categories), and disclaimer.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | nda.pdf | |
| pdf_base64 | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by detailing specific behavioral traits: 'This tool creates session state and a one-time Stripe checkout URL — it is NOT idempotent: each call mints a new session token and a new checkout URL.' It also mentions that the document is deleted after the report is retrieved and that no account is required. This adds valuable context beyond the annotation flags, so the agent is fully informed.
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 long and detailed, but it is structured into clear sections: document types, clause categories, use-case triggers, return value, and args. Each section serves a purpose for matching user intents. Though lengthy, it is front-loaded with the core purpose and not wasteful; the enumerations are functional for an AI agent's pattern matching.
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 thoroughly explains returns: 'Returns a partial risk assessment covering the first ~3 pages... clause-level inventory... overall risk score... risk tier... Stripe Checkout URL...' It also covers input constraints, payment, idempotency, and the path to the sibling tool. This is complete for the tool's complexity and context.
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 0%, so the description fully compensates. It explains pdf_base64 as 'The NDA or contract as a base64-encoded PDF string' and filename as 'Optional original filename (for display only).' Prose also adds the max 10MB size limit and base64 format requirement, giving meaning beyond the bare 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?
The description clearly states the tool's purpose: 'Screen an NDA or confidentiality agreement for risk and return a free preview.' It lists specific document types and clause-level risk categories, and explicitly differentiates from the sibling tool by noting the preview nature and the Stripe checkout URL for the full report via get_nda_report. This is a specific verb+resource with clear scope.
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 gives explicit when-to-use guidance: 'Use this tool whenever a user shares the text or PDF of any of the following document types...' and 'Use this tool when a user is in a contract decision moment and asks any of...' It also names the alternative path (get_nda_report) for the full report, providing clear context for when to use this tool versus the sibling.
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Flicense-qualityBmaintenanceAnalyzes contracts for safety score and risk assessment, identifying dangerous clauses and dispute patterns, with recommendations for improvements.
- Alicense-qualityCmaintenanceEnables AI agents to analyze Ethereum wallets, simulate transactions, and draft transfers with deterministic policy and risk scoring, requiring human approval before on-chain execution.2ISC
- Alicense-qualityCmaintenanceEnables users to paste contracts, leases, terms of service, and other documents to receive a plain-English summary of key risks, deadlines, rights, and negotiation points.MIT
- AlicenseAqualityDmaintenanceURL intelligence for AI agents. One URL in, structured security and data quality signals out across 7 dimensions. 13 tools, risk score 0-100 with 23 configurable weights.161601MIT
Your Connectors
Sign in to create a connector for this server.