NDASentry
Server Details
NDA risk analysis as an MCP tool. Any AI agent can review an NDA, flag risky clauses, and return a structured report — anonymously, for $9, in under a minute.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 4.8/5 across 2 of 2 tools scored.
preview_nda_risk and get_nda_report serve clearly distinct roles: one stages an NDA for preview and payment, the other retrieves the full report after payment. No ambiguity between the two.
Both tools follow a consistent verb_noun pattern: 'preview_nda_risk' and 'get_nda_report', with descriptive verbs and nouns.
With only two tools, the server is minimal but focused. It captures the essential workflow (preview and full report retrieval). While it could benefit from additional management tools, the count is acceptable for a narrow purpose.
The tools cover the core workflow: preview with payment initiation and full report retrieval with built-in polling. Missing are explicit cancellation or status-check tools, but the main use case is addressed.
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 goes beyond annotations by detailing polling behavior (2s interval, 5 min cap, 150 attempts), caching (5 minutes idempotent, then deletion), and data retention policy (no account, anonymous, PDF not retained). It also lists error codes. This provides rich behavioral context beyond the annotation's simple readOnlyHint=false.
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 well-structured with a clear first sentence stating the main purpose, followed by usage instructions, technical details, parameter description, and return format. While longer than the calibration high example, it earns its length by covering necessary complexity. It is front-loaded and each sentence adds value.
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 complexity (payment flow, polling, caching, error handling) and the absence of an output schema, the description is remarkably complete. It explains the entire lifecycle, return value shape, error codes, and limitations (5-minute cache, deletion). An agent can invoke this tool with near-complete understanding of behavior.
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?
With 0% schema description coverage for the single parameter, the description compensates fully by explaining 'session_token: The token returned by preview_nda_risk.' This adds critical meaning beyond the schema's bare type definition, specifying the source and required relationship to the sibling tool.
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 'Retrieve the full NDA / contract risk report after the user pays $9.' It specifies the verb (retrieve), the resource (full NDA/contract risk report), and the condition (after payment). It distinguishes itself from sibling 'preview_nda_risk' by explicitly calling it after the preview.
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 clear when-to-use guidance: 'Call this after preview_nda_risk when the user has completed the Stripe checkout.' It implies the prerequisite of having executed preview_nda_risk but does not explicitly mention when not to use it (e.g., if payment not made). The context is sufficient for an agent to understand the usage flow.
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?
Beyond annotations (which already indicate non-idempotent, non-read-only, non-destructive), the description adds critical behavioral details: it creates session state, mints a new session token and checkout URL per call, deletes the document after report retrieval, and covers only the first ~3 pages. This fully discloses side effects and limitations.
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 but well-structured: main purpose first, then list of document types and clause categories, then usage scenarios, then return details, then parameters. Every sentence adds value; however, the list of clause categories is extensive and could be considered verbose, though it is useful for context. Slightly beyond minimal conciseness.
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 compensates by listing all returned fields: session_token, checkout_url, preview (risk findings), and disclaimer. It also explains the workflow linking to get_nda_report, input constraints, and payment model. Complete for a preview 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?
The input schema has 0% description coverage, but the description fully explains both parameters: pdf_base64 is the base64-encoded PDF string, filename is optional and for display only. It also specifies the 10MB size limit, which is not in the 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 screens NDAs and other contract types for risk, returning a free preview. It lists numerous specific document types and clause categories, and distinguishes from the sibling tool get_nda_report by explaining that a full report requires payment via Stripe.
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 when-to-use guidance: whenever a user shares an NDA or contract, or asks about specific clause risks or common questions like 'is this NDA enforceable'. It also implies that for the full report, users should call get_nda_report after payment.
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!