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_<status_code>.
| Name | Required | Description | Default |
|---|---|---|---|
| session_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides detailed disclosure of polling mechanism, caching, idempotency, and error codes. Annotations are minimal (readOnlyHint=false) so the description carries the full burden and excels.
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?
Concise yet thorough. Uses bullet points for polling and returns, every sentence adds value. No fluff.
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 key aspects: purpose, prerequisites, polling mechanics, caching, error handling, and return format. No output schema, but description sufficiently explains 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?
Only parameter 'session_token' is explained as 'The token returned by `preview_nda_risk`.' This adds critical context beyond the input schema, which has 0% description 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?
Clear verb and resource: 'Retrieve the full NDA risk report for a paid session.' Distinguishes from sibling 'preview_nda_risk' by specifying it is for paid sessions and requires a session_token from that 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?
Explains when to use (after preview_nda_risk, when payment is expected) and outlines polling behavior and error codes. Does not explicitly state when not to use or list alternatives, but the context of a paid full report vs free preview is implied.
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?
Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds critical behavioral details beyond annotations: it creates session state and a one-time checkout URL, is not idempotent (each call mints new tokens), and has a 10MB size limit. No contradictions with annotations.
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 opening line, followed by output explanation, behavioral notes, and argument descriptions. Every sentence provides unique value, and the information is front-loaded. No redundant text.
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 explicitly states the return structure (dict with session_token, checkout_url, preview, disclaimer). It covers size limit, encoding, and references the sibling tool. It lacks error handling details but is sufficiently complete for a preview tool with moderate complexity.
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%, placing the burden on the description. The description adequately explains both parameters: pdf_base64 is 'The NDA as a base64-encoded PDF string' and filename is 'Optional original filename (for display only).' While not extremely detailed, it adds necessary meaning beyond 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 'Stage an NDA for analysis and return a free risk preview,' specifying the action (preview), resource (NDA), and output (risk preview). It distinguishes itself from the sibling tool get_nda_report, which is for the full report after payment.
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 explains the tool's behavior: it returns a partial preview and a Stripe Checkout URL that must be completed to unlock the full report via get_nda_report. It also notes the tool is not idempotent and creates one-time session state, giving clear guidance on when to use and when to use the alternative.
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!