TeamDesk Knowledge Base & Support

Slava Shinderov  Staff  5/18/2026 9:02:44 AM

@Dean, please provide more details about the integration with Claude you're looking for.

Officially, we use only OpenAI models and only through internal integrations, so it is not clear to me what you mean by "only the URL is exported to Claude and not the actual content."

Lp 5/27/2026 6:59:06 PM

Dean, what are you looking to do? We have had a lot of success with Claude, although a lot was built out internally. Happy to share

Dean Guidry 6/2/2026 11:42:49 AM

I would like to see a send to Claude option for a view or table, or search return.

Dean Guidry 6/27/2026 7:40:28 AM

Another iteration which would be especially usefull is to be able to create a view of selected documents and send the documents column to Claude for analysis. This integration would speed up my workflow tremdously. I am a lawyer and Claude has become so essesetial to the practice of law now that anthing to speed up the process has is required to compete in the current practice flow as opposing counsel are using it routinely now. As things are now with Teamdesk, I have to download each document then send them to a claude chat…pain in the ass.

L. C. Parker 6/27/2026 1:11:44 PM

Dean, short version: you don't have to wait for TeamDesk to build this. You can roll it yourself with features available toda…with Some work

The core problem behind "only the URL gets sent" is that a link can't carry the document's contents, and your files sit behind a TeamDesk login, so anything that just hands Claude a URL leaves it blind. The fix is a small piece of glue that fetches the actual file and passes it to Claude. Two ways to do it.

Automated (the route I took, bia n8n): a button or a record change fires TeamDesk's built-in "Call URL" workflow action into an automation workflow tool I built, which pulls the file, sends it to Claude, and writes the result back onto the record. No downloading, no pasting. Best when you want the same standard analysis run across a lot of documents.

Conversational (closer to what you described): you would need an MCP connector to your own Claude account, which lets Claude reach into TeamDesk and pull the documents itself via API. Point it at a view and just talk: "pull these and compare the indemnity clauses." A dozen documents is no harder than one, and it kills the download-each-file-and-paste-it routine for good. This I would scope as I read only/one way (Can pull from TD, not write, because sometimes AI decides to help you in ways that you did not want)

MCP and really any API config does require some careful thinking through and planning, both from security, scope, and data integrity standpoints.

Two cautions, since this is legal work. First, keep a locked-down, read-only, logged gatekeeper between any tool and your live database (that's the "API proxy in the middle" I mentioned really is). Be careful with the prebuilt TeamDesk MCP connectors on GitHub: when I audited them they had real holes, Potential, credential leaks, wide-open create, update, and delete with no logging, which is a non-starter for client files.

Second, the documents themselves get sent to the AI provider, so the question that matters for privileged material is whose plan and whose terms the request actually runs under. My understanding is that Anthropic's commercial tiers (Team, Enterprise, and the API) do not use your inputs or outputs for training by default under their Commercial Terms, while the consumer plans (Free, Pro, Max) can unless you opt out. That turns on your specific subscription, and I don't know which one you're on, so you'll want to confirm it yourself against Anthropic's own terms and privacy pages rather than relying on me. OpenAI is the same idea with its own per-plan rules. One sharp edge for legal use: if you reach a model through a plugin or tool that runs on someone else's subscription or API key, it is that account's terms that govern your data, not yours, so it's worth knowing whose account your client files are actually passing through. Treat all of this as my own understanding as an individual, not legal advice and not a position I'm offering on behalf of anyone. I have not done a thorough legal review, and the answer depends on your plan, so validate it for your own setup before trusting it with privileged files.

None of this is exotic; it's mostly wiring together things. I've been down this road, so I'm glad to share what'll save you the trial and error: I have what I internally call our Teamdesk-API-golden-records; which is a verified (and refined overtime) TeamDesk REST API reference (auth, reading and writing records, pulling attachments, error codes, and real response shapes, all checked against the live API and written to drop straight into an AI's context), plus the lessons learned from our own MCP project. If any of this is unclear, just ask and I'll walk you through it.

ONE THING I CANNOT STRESS ENOUGH: the scoping of credentials for this, needs to be very deliberate. I highly recommend setting up a separate user, even though you have to pay for the license, which will be used for this work. And a special role, where you scope, what tables and what fields they can access. User is tied to API token, the roll is tied to the user, the permissions are set on the roll. I strongly suggest that when you set up the role, you set everything to no access across the board. And then selectively go back and turn on Reed only for what you want to read. Make sure you also update the ad, modify and delete Fields to know. Otherwise you’re in for a heap of trouble sooner or later.

If you create an API key based off of your user, it will have access to everything that you do. Do not do that!!!!

Dean Guidry 6/28/2026 12:04:52 AM

Wow!! That is awesome! Thanks.

L. C. Parker 6/29/2026 6:13:08 PM

Dean, follow up question. Have you built out any skills or prompts when it comes to specific type of document review?

I dropped one of my contract review skills into Claude and asked it to generalize it and create an output for sharing, with explanations.

Not sure if as of any use, but dropping it here regardless.

The below is not a skill in and of itself. It is the description of a scale. But you could probably ask Claude to help you craft it into a proper skill. The below is a very simplified, and very short representation of what our skill file actually is.

—-
# Contract Review Skill Extract for Sharing Principle (Generic Template)

> **Why this is a skill and not just a prompt**
>
> Dropping a contract into a chat window with "review this" gives you whatever
> the model happens to fixate on in that one session. It is non-repeatable, has
> no coverage guarantee, and treats a blank signature block and a stylistic nit
> as equally important. Run the same contract twice and you get two different
> reviews.
>
> A skill fixes that by encoding four things the blind drop cannot:
>
> 1. **A fixed analysis framework** so the same baseline checks run on every
> document, every time, regardless of who is driving.
> 2. **Type-specific checklists** so a deed gets deed checks and an NDA gets NDA
> checks, instead of generic "looks fine to me" coverage.
> 3. **A related-documents prompt** so the review looks across the package, not
> just the four corners of one file. Most real errors live in the gaps
> between documents (price says one thing, settlement statement says another).
> 4. **A severity-tiered, owner-assigned output** so a deal-blocker and a typo
> are visibly different, and every action lands on a named person.
>
> The value is coverage, repeatability, and a clean handoff. Not cleverness.
> Delete this block before using the template as an actual skill file.

---

Systematic contract analysis for **[ORGANIZATION NAME]**. Every analysis applies
the universal framework below, then loads the contract-specific checklist from
`references/`.

## Document voice (mandatory)

Before writing the review report, read `references/house-style.md`. Apply the
organization's writing conventions to all generated prose. Never alter quoted
contract or statutory text to satisfy a style rule. Quote it verbatim.

> Example conventions a team might enforce here: banned punctuation or phrasing,
> a required tone, a fixed report vocabulary, formatting standards. The point is
> that output style is a setting, not a per-session accident.

## Step 1: Identify contract type

Read the uploaded document. Classify it into one of the types below and load the
corresponding reference file.

| Domain | Contract Type | Reference File |
| -------------------- | -------------------------------------- | -------------------------- |
| [Domain A] | [Standard Form / Type 1] | `domain-a.md` §1 |
| [Domain A] | [Standard Form / Type 2] | `domain-a.md` §2 |
| [Domain B] | [Type 1] | `domain-b.md` §1 |
| [Domain B] | [Type 2] | `domain-b.md` §2 |
| [Domain C] | [Settlement / Closing Document Type] | `domain-c.md` §1 |
| [Domain C] | [Conveyance Document Type] | `domain-c.md` §2 |
| [Domain D] | [Service / Vendor Agreement Type] | `domain-d.md` §1 |
| [Domain E] | [Governance Document Type] | `domain-e.md` §1 |
| [Domain F] | [Technology / SaaS Terms] | `domain-f.md` §1 |
| [Domain G] | [Insurance / Certificate Type] | `domain-g.md` §1 |

If a contract does not match any type, apply the universal framework only and
note the gap.

## Step 2: Related documents prompt

Before analysis, ask the reviewer what related documents exist. Critical
findings often come from cross-referencing external documents, not from the
contract in isolation.

Prompt by contract type:

| Contract Type | Ask For |
| ------------------------ | ------------------------------------------------------------------- |
| [Governance Document] | [Plats/notes], [recorded exhibits], [bylaws], [prior versions] |
| [Purchase Agreement] | [Prior amendments], [inspection reports], [title work], [survey] |
| [Financing Instrument] | [Loan agreement], [prior modifications], [settlement statement] |
| [Construction Agreement] | [Scope of work], [insurance certificates], [draw schedule] |
| [Service Agreement] | [Governing master agreement], [fee schedule], [SOW] |

If related documents are provided, load the Cross-Referencing Workflows section
and validate consistency across all documents. If not provided, note in the
Confidence Assessment which cross-checks could not be performed and what
specific documents would be needed.

## Step 3: Universal analysis framework

Run these checks on every contract regardless of type.

### 3.1 Document identification

Extract: contract type, title, effective date, parties (full legal names with
entity suffixes), governing law, term/expiration.

### 3.2 Financial terms verification

- Cross-check all dollar amounts: spelled-out vs. parenthetical, header vs.
body, schedule vs. narrative.
- Verify interest rate calculations, payment schedules, and maturity dates
mathematically.
- Flag fee structures: origination, late fees, escalation clauses, penalties.
- Confirm payment terms: timing, method, application order.
- Identify deposits, earnest money, retainers, and refundability conditions.
- On scanned/OCR source, flag every discrepancy and never suppress one. Call out
every spelled-out-vs-numeric or cross-document amount mismatch, even when it
looks like a scan artifact. A possible OCR cause is a reason to verify against
the source image, never a reason to downgrade or skip the finding. Small
numeric errors carry outsized legal and financial consequences, so default to
reporting and confirming over assuming.

### 3.3 Obligation and risk mapping

- Map each party's obligations with specific performance deadlines.
- Identify default triggers and cure periods.
- Analyze termination provisions: for cause vs. convenience, notice, penalties.
- Review indemnification scope: one-way vs. mutual, carve-outs, caps.
- Assess insurance requirements: types, limits, additional insured status,
certificate timing.
- Check limitation of liability and damage caps.

### 3.4 Dispute resolution assessment

- Identify mechanism: litigation, arbitration, mediation, or tiered.
- Evaluate arbitration clauses: provider, rules, location, class action waiver,
opt-out window.
- Check jury trial waivers and enforceability context.
- Review attorney fees provisions: prevailing party, caps, shift conditions.
- Note forum selection and choice of law implications.

### 3.5 Consistency and integrity checks

- Verify party names consistent throughout (including entity suffixes).
- Confirm all dates internally consistent: effective, term, renewal, maturity.
- Check cross-references: do section references point to the correct sections?
- Identify blank fields, placeholders, or template artifacts.
- Compare signature blocks to party definitions in the preamble.
- For scanned/OCR documents, always call out a malformed name or mismatched
character (apostrophe, entity suffix, custodian format, legal description)
and never resolve it as OCR noise without checking. Flag it and have the
reviewer confirm against the original image, especially payee/custodian names
and legal descriptions, where a single wrong character changes legal meaning.

## Step 4: Contract-specific checklist

Load the reference file from Step 1. Execute its extraction steps, analysis
checklist, and risk-flag review. This is where domain expertise lives: each
reference file holds the checks that only matter for that one document type.

## Step 5: Output

Every analysis produces:

- **Executive Summary** (2-3 sentences): what it is, who is involved, key risk.
- **Favorable Terms**: provisions that benefit [ORGANIZATION].
- **Points Requiring Attention**, ranked by severity tier:
- **BLOCKERS**: must resolve before execution/recording. Includes blank
fields, amount discrepancies, wrong legal references.
- **Errors / Typos**: mechanical fixes for the drafting attorney. Include
exact location and correction.
- **Substantive**: require business and/or legal decisions by [ORGANIZATION].
- **Financial Verification Table**: all dollar amounts cross-checked with
pass/fail. When related documents are available, cross-check amounts across
documents.
- **Action Items by Owner**: every item assigned to a specific person or role
(e.g., "[Reviewing Attorney]," "[Business Owner]," "[Operations]"). Group by
owner for handoff. Include a "Quick Reference: Mechanical Fixes" table for the
drafting attorney.
- **Confidence Assessment**: flag where assumptions were made vs. verified from
the document. Explicitly list cross-checks that could not be performed due to
missing related documents.
- **Document Classification** (optional structured trailer for document-management
routing): emit the classification for this contract as a JSON object, e.g.
`{"type_code": "...", "document_type": "...", "category": "...", "priority": "..."}`,
per the schema in `references/document-taxonomy.md`. This feeds any downstream
categorization or routing pipeline.

## Cross-referencing workflows

When analyzing document packages (not single contracts), apply multi-document
validations:

- **Transaction Package** ([Purchase Agreement] + [Amendments] + [Settlement
Statement] + [Conveyance] + [Security Instrument]): verify price, parties,
dates, and legal descriptions are consistent across all documents.
- **Financing Package** ([Note] + [Modifications] + [Security Instrument] +
[Transmittal]): build the complete modification chain and verify all
calculations.
- **Construction Reconciliation** ([Agreement] + [Schedule of Values] + [Bids] +
[Draws]): cross-reference the schedule of values against budget and bid
amounts.
- **Governance Audit** ([Declaration] + [Management Agreement] + [Bylaws] +
[Articles]): verify entity names, statutory compliance, and control provisions.

## Supporting references

- Jurisdiction-specific statutes and standard form references:
`references/jurisdiction-legal.md`
- Known counterparties and entity names: `references/counterparties.md`
- Document-type taxonomy for downstream categorization:
`references/document-taxonomy.md`

---

> **How to adapt this template**
>
> Replace every `[BRACKETED]` placeholder and each `references/*.md` filename
> with your own. The three reference files at the bottom are what make the skill
> yours: statutes/forms for your jurisdiction, your actual counterparties, and
> your document-management taxonomy. The framework in Step 3 stays constant; the
> Step 1 table and the reference files are where you encode what your team
> actually knows.

L. C. Parker 6/29/2026 6:42:17 PM

# Blind Drop vs. Skill: Why Contract Review Needs a Framework

Both start the same way: a contract goes into a chat window. What you get back
is where they split. One is a one-time opinion. The other is a repeatable
process. Here is the difference, line by line.

| Dimension | Drop the file in and ask "review this" | Run it through a review skill |
| ---------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------- |
| **Coverage** | Whatever the model happens to notice this session | A fixed framework runs the same baseline checks on every document |
| **Repeatability** | Run it twice, get two different reviews | Same checks, same structure, regardless of who is driving |
| **Domain fit** | Generic read. A deed and an NDA get the same treatment | Type-specific checklist loads. A deed gets deed checks |
| **Cross-document** | Limited to the four corners of the one file you pasted | Prompts for the related package and validates consistency across it |
| **Triage** | A typo and a dealbreaker come back looking equally important | Findings are tiered: blockers, then errors, then judgment calls |
| **Handoff** | You re-read the output and figure out who owns what | Every action item is already assigned to a named person or role |
| **Numbers discipline** | A spelled-out vs. numeric mismatch can get waved off as a typo | Every amount discrepancy is flagged and checked against the source |
| **Auditability** | No record of what was and was not checked | A known framework means you can see exactly what coverage you got |

## The failure the blind drop misses

The expensive errors usually do not live inside one document. They live in the
gaps between documents. The purchase agreement says one price; the settlement
statement says another. A name is spelled one way in the note and another way in
the security instrument. A dollar figure is correct in the body and wrong in the
schedule.

A person pasting a single file and asking "any issues?" almost never gets these,
because the model is only looking at what is in front of it. A skill that
*prompts for the related documents first* and then cross-checks them is the part
that catches the costly mistakes. That single step is the strongest argument for
having a framework at all.

## The honest tradeoff

A skill is not free. It takes upfront work to author the framework, the
type-specific checklists, and the reference files, and it needs occasional
maintenance as forms and counterparties change. A blind drop has zero setup.

So the call is simple:

- **One-off gut check, low stakes, nobody downstream relies on it:** the blind
drop is fine.
- **Reviews that have to be reliable, repeated, and handed to someone else:** the
framework pays for itself fast, because the cost is paid once and the coverage
is collected every time.

## Bottom line

The blind drop gives you an opinion. The skill gives you a process. The framework
is the asset, not the cleverness of any single answer.

Dean Guidry 6/29/2026 6:48:34 PM

I just did that and specified for use with a particular type of matter. Claude produced an excellent compilation of the various prompt instructions I’ve inserted from time to time in various chats. I did not know it was called a skill set before you explained it.

L. C. Parker 6/29/2026 7:41:39 PM

Awesome! Just make sure to cite check any reference you use your skills. Hope I contributed a little bit to your journey.