MCP

Tightly runs a Model Context Protocol server, so an agent can read your organisation through the same keys and the same reach as any other client.

Use the endpoint for your organisation's region:

Region	MCP endpoint
US	https://mcp.app.tightly.io/mcp
EU	https://mcp.eu.tightly.io/mcp

Transport is streamable HTTP.

Two ways in

A key, for an unattended agent. Send the key as the bearer token, exactly as you would to the REST API. No browser, no consent screen, no person in the loop:

{
  "mcpServers": {
    "tightly": {
      "type": "http",
      "url": "https://mcp.app.tightly.io/mcp",
      "headers": { "Authorization": "Bearer tly_live_..." }
    }
  }
}

For an EU organisation, use https://mcp.eu.tightly.io/mcp as the url above.

OAuth 2.1, for an agent acting for a person. The server is an authorization server with dynamic client registration, so a client that speaks OAuth discovers it, registers itself, and sends the person to a consent page. The session then acts as that person, with that person's own access.

The difference in one line: a key is a principal of its own, and an OAuth session is a proxy for a human being. Side by side:

	A key	A session
How it is granted	An admin mints tly_live_ with resource scopes.	A person signs in on the consent page and picks Read or Read and act.
Whose reach	The key's scopes, inside its organisation.	The person's own, decided by the API on every call.
Sold with	Essentials, and every rung above it.	Essentials, and every rung above it. A Lite organisation is refused at consent, in the sentence the plan serves.
execute, search, search_help and the two doc tools	Yes, cut to the key's scopes.	Yes.
ask and query_metrics	Never. The conversation is for a signed in person.	Yes.
The act tools	Never. A key has nobody at the keyboard.	Only on Read and act, and only where the client can ask its person.
Writes through execute	Never.	Never.

The fifteen tools

Five of them a key is offered. The other ten are a person's, because each one either answers as Ask Tightly does or ends in somebody confirming a sentence.

Tool	Title	A key	A session
search	Search Tightly's function reference	Yes	Yes
execute	Read Tightly	Yes	Yes
get_docs_index	List Tightly's help articles	Yes	Yes
get_doc	Read a Tightly help article	Yes	Yes
search_help	Search Tightly's help	Yes	Yes
ask	Ask Tightly	No	Yes
query_metrics	Read Tightly's metrics	No	Yes
get_act	Read what an act did	No	Yes
stage_to_bench	Stage the worked buy to the Bench	No	Read and act
stage_reorder_to_bench	Stage reorder lines to the Bench	No	Read and act
create_purchase_order	Draft a purchase order	No	Read and act
keep_answer	Keep this answer	No	Read and act
save_skill	Save as a draft skill	No	Read and act
undo_act	Take it back	No	Read and act
request_connector	Ask Tightly for a new connection	No	Read and act

execute is the door onto the platform's own function registry, and it is where a key's reach is enforced. Every tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint before your client calls it, so a client can decide what to put in front of a person without reading a word of this page.

request_connector is confirmed the same way an act is, but it writes no data of yours: it files one record with Tightly's own team about a source Tightly does not connect yet, and it is refused for anybody outside Tightly, in Tightly's own sentence.

Two sentences hold for every act, and they are the promise rather than a description of it. Every act ends in a person's own confirmation of a sentence composed from served figures, and is then performed under that person's own credential through the same gates as a page press. And a client that cannot ask its person is offered no act tool at all.

Reach, on a key

A key reaches over MCP exactly what it reaches over REST, and the check happens twice:

1. Before the call. A function whose category maps to a scope the key does not hold is refused in the MCP server, with the sentence in the resource's own words: "This key cannot read Order book."
2. On the call. The MCP server forwards the key itself as the bearer token on every REST call it makes, so the same door that guards a direct request guards this one. There is no second privilege path and no service account behind the agent.

Categories with no public resource are unreachable by a key at all: the dashboard, the basket, budget, the plan editor and its line plans, markdown, automations, imports and integrations. The two planning reads the contract publishes are the exception, and they cost planning:read like any other resource.

A key never writes

execute writes nothing, for any principal. Every function that would change data is refused before the request is issued, on both doors. That is the current fact and a deliberate one.

The act tools above do write, and none of them is offered to a key. Each is a signed in person's, on the wider grant, and each ends in that person confirming a sentence in their own client and the write being made under their own credential. A key has nobody to ask, so it is offered no act tool at all rather than a confirmation nothing can answer.

When a key's acts open they will park in the minter's Inbox for a person to approve, and the changelog will say so. Until then an integration that writes uses the REST door and its own scopes, which is what that door is for.

What lands in the audit

Every MCP call made with a key is recorded against the key, the same as a REST call, with via set to mcp. Open the key's Usage drawer in Settings, then Developer, and both doors show in one list: the operation, the status, when, and which way it came.

The via field is derived from the User-Agent the MCP server sends, Tightly-MCP/<version>. It tells the two doors apart for your own reading; it is not an access control, and nothing is granted or refused on the strength of it.

Which functions exist

search is the honest answer: the registry carries over 150 functions across 31 categories, and which of them a given key can reach depends on that key's scopes. Ask for what you want and the server names the function, or refuses and says which resource the key is missing.

What a session may spend

A key spends the rate limits it always spends: every MCP call by key is a forwarded REST call under that key, counted once in that key's own window, 600 reads and 120 writes a minute. Nothing here is counted twice.

A signed in session has two windows of its own, counted per session:

Allowance	Per	Ceiling
Tool calls	Minute	120
Act proposals	Hour	20

A call the door refuses still spends the minute. A call refused at the tool gate spends no proposal, because it never got to propose anything.

The refusal arrives as an error result whose text is JSON:

{
  "allowance": "calls",
  "code": "rate_limited",
  "detail": "This agent has asked 120 times this minute; try again in 30 seconds.",
  "error": true,
  "limit": 120,
  "refused": true,
  "reset": 1788523260,
  "retry_after": 30
}

code is the REST door's own word for this refusal, so a client that learned rate_limited there reads the same code here. retry_after is seconds and reset is unix seconds. There is no Retry-After header on a tool result: a JSON-RPC channel has none for one call, which is why the number rides in the body under the name and the unit the header carries on the keyed door.

The proposals refusal reads "This agent has proposed 20 acts this hour; try again in 60 minutes."

Approved clients

Which agents an organisation lets in is a setting in the app, not a thing a client declares. A key needs no approval: minting it was the approval.

Choosing between MCP and REST

Use	When
REST	You are writing an integration. Fixed calls, fixed shapes, a contract you can pin to a train.
MCP	You are giving an agent access. Open-ended questions, a tool the model chooses, and reads only where the agent holds a key.

An ERP posting purchase orders wants REST. An analyst asking their assistant which styles are short of cover wants MCP. A system doing both holds one key and uses both doors, and both show in the same Usage drawer.