Skip to content

What MCP is

MCP — the Model Context Protocol — is an open standard that lets an AI assistant use external services. Without it, an assistant can only talk: it can draft you a contract, but it cannot send it for signature. With it, it has tools.

AssinaJá runs an official MCP server. Once connected, you can ask the assistant in plain language to prepare a document from one of your templates, tell you who has not signed yet, or fetch the signed PDF.

Signature work is repetitive: take a template, fill the same fields with data that lives somewhere else, pick the signers, send, then keep checking who is missing. That gap is what MCP closes.

It works where you already are. If you are drafting a proposal in a conversation with the assistant, the document leaves from that conversation. No exporting, no switching tabs, no re-uploading the file.

The assistant reads your templates. It queries your organisation’s real templates — with the signers and merge fields actually defined there — rather than inventing a format.

It is for asking, not only for doing. “Which documents have been waiting for signature for more than a week?” is a question the assistant answers from the real list.

It is the same engine. MCP tools call the same services as the public API — there is no second implementation with different rules. What is forbidden in the application stays forbidden here.

Method For
OAuth Web assistants: Claude.ai, ChatGPT, Copilot, Grok
X-Api-Key header Local tools and automation: Claude Code, Cursor, CI

Web assistants do not let you set your own headers, so they use OAuth. Those are the connections described in Connect Claude.ai and Connect ChatGPT.

The server address is the same either way:

https://app.assinaja.pt/mcp

For Claude Code, for instance, the connection is a single command with the API key travelling in the header:

Terminal window
claude mcp add --transport http assinaja https://app.assinaja.pt/mcp \
--header "X-Api-Key: ajk_live_..."

This is the part that sets the integration apart, and it is worth understanding before connecting anything.

Even over OAuth, what is issued is not access to your user account. It is access bound to one specific API key. The authorisation page says so itself:

This AI assistant is asking for access to your organization. Access goes through an API Key — the assistant can only do what that key allows, and it never accesses your account.

If the key can only read documents, that is what the assistant can do — there is no route from there to anything else.

The assistant only sees what the key allows

Section titled “The assistant only sees what the key allows”

Filtering happens before the assistant decides anything. When it asks the server which tools exist, the answer is already cut down to the key’s permissions: a tool outside that scope does not appear in the list at all, rather than being refused when called.

In practice, an assistant connected with a key lacking Documents — publish does not even know publishing is possible.

Authorising is not a click that disappears. Who authorised, which key, which assistant, which permissions, when, and from what address are all stored. You see that record under Settings → API Keys, in the Authorized to AI assistants section:

Consent record (evidence). To cut an assistant’s access, suspend or delete the key.

The key is revalidated on every request. Suspending, expiring or deleting it cuts the assistant off at once — no waiting for a session to end.

That answers the most uncomfortable case: if you distrust a connection, suspend the key and see what breaks. Suspending is reversible.

The server sends safety instructions the assistant receives before acting: signer codes belong to the template and must never be invented; publishing emails signers immediately and cannot be undone, so it requires explicit confirmation in the conversation; and a failed creation is never retried blindly, because a second call creates a second document and a second batch of emails.

60 requests per minute per credential, shared with the public API.

The available tools depend on the permissions ticked on the key. The names on the right are the ones you see in the assistant.

Key permission The assistant can then
Templates — read List templates · Get template details
Documents — read List documents · Get document details · Get document overview · Get signing links · Download document file
Documents — create Create document · Create document from template · Create document from Word template · Create upload link · Get upload link status
Documents — publish Publish draft and notify signers
Documents — archive/delete Archive document · Delete document · Delete draft
Organization — read Get organization · Get subscriptions and plan features
Analytics — read Analytics overview · Usage metrics · Metric over time · Metric breakdown · Signing funnel · Adoption and seats · Metric catalog

The assistant cannot reach files on your disk. When it needs one, it creates a delivery link — you open it, upload the file, and it carries on. See Deliver a file to an assistant.

Analytics are off by default. Whether an assistant may read the organisation’s numbers is a separate decision, under Settings → Policies:

Whether assistants connected over MCP may read this organization’s figures. Off by default. It never grants access to documents, content or keys — only aggregated metrics, and every request is written to the audit trail.

An assistant can get things wrong. Reading the right documents and summarising them badly is a possible failure, and MCP does not solve it. For anything that matters, check in the application before sending.

What it does is done in your name. Documents are created in your organisation and consume your quotas.