Secure Close access for AI agents

Leads, contacts, opportunities, activities, tasks, and workflows via Close's official MCP server.

Through Close, agents can search leads and opportunities, read notes and activities, and update the CRM or place voice-agent calls when you allow it – every call runs through your policies and is logged for audit.

Server URL: https://mcp.close.com/mcp

Credential modes

Close supports per-org dynamic registration only, so there is no app to create on Close's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.

Before you begin

A Close account that can reach the leads and opportunities your agents need.
Administrator access to your Agent Authority workspace, to add the resource.

Setup

In the Agent Authority console, go to Resources and click Add Resource.
Select Close from the catalog.
On Choose how to install Close, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.

Dynamic client registration

When you add the resource, the gateway registers its own OAuth client with Close – the credential that lets it sign users in. Close's own role and permission settings still apply, so an agent can only reach what the person who signed in could already reach.

Verify the connection

The gateway syncs the Close tools automatically. To check the connection end to end, ask your agent to run a request:

Get my Close org info

If your organization and user details come back, the connection is working.

How users connect

Access is per user. Each additional user connects their own Close account the first time their agent calls a Close tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.

Each person only reaches the leads, opportunities, and settings their Close role allows.

Available tools

Close exposes a broad tool surface (99 tools). Highlights by area:

Tool	Access	Description
`org_info`	read	General information about the organization and current user
`search`	read	Natural-language search for leads or contacts
`lead_search`	read	Simple lead search returning the initial result set
`activity_search`	read	Search activities, ordered by date descending
`aggregation`	read	Aggregate CRM data to answer analytical questions
`fetch_lead`	read	Fetch a lead (company) by ID
`find_opportunities`	read	Find opportunities by status, owner, lead, or pipeline
`find_tasks`	read	Find tasks with filters
`create_lead`	write	Create a new lead (company)
`update_lead`	write	Update an existing lead
`create_contact`	write	Create a contact on a lead
`create_opportunity`	write	Create an opportunity
`create_note`	write	Create a note on a lead
`create_comment`	write	Comment on notes, calls, opportunities, tasks, and custom objects
`create_task` / `update_task`	write	Create or update lead tasks
`create_workflow`	write	Create a workflow (sequence) in Draft status
`enrich_field`	write	Use AI to determine and set a field value on a lead or contact
`delete_lead`	write	Permanently delete a lead and all of its data

The connector registers the full Close MCP tool set (leads, contacts, addresses, notes, comments, opportunities, pipelines, statuses, tasks, call tasks, email/SMS templates, smart views, custom activities, custom objects, custom fields, forms, workflows, scheduling links, voice agents, and product knowledge search). Use gateway policies to allow only the tools each agent needs.

Required scopes

The gateway requests these scopes automatically when it registers the client, so there is nothing for you to configure. Close decides what to grant, and any scopes it returns during registration replace the list below.

mcp.read – read access to CRM data
mcp.write_safe – non-destructive writes (create/update)
mcp.write_destructive – destructive writes (deletes)
offline_access – refresh tokens for long-lived connections

Policy examples

Rules are evaluated first-match-wins from the top of the list, and every org starts with a seeded Allow all rule sitting at the bottom – so a recipe made only of allow rules restricts nothing. These examples work by adding denies above it.

Read-only access: deny create_*, update_*, delete_*, enrich_field, apply_voice_agent_update, and schedule_voice_agent_call. The last three matter – the wildcards miss them, but enrich_field writes an AI-derived value back to a lead or contact, apply_voice_agent_update persists a config change, and schedule_voice_agent_call queues a real outbound call. Add propose_voice_agent_update if agents shouldn't store proposals either.
Safe writes only: deny delete_* so agents can never destroy CRM data.
Sales-assist scope: deny the administration surface – *_email_template, *_sms_template, *_pipeline, create_workflow, and *_voice_agent* – leaving lead, contact, opportunity, and task tools available.

To deny by default instead, turn off the seeded Allow all rule and allow the read surface explicitly: org_info, search, paginate_search, lead_search, activity_search, aggregation, get_fields, and fetch_* / find_*. get_fields and paginate_search are easy to forget – aggregation requires fetching the field list with get_fields first, and search pages through paginate_search – so leaving them out breaks the tools you just allowed. Removing Allow all is org-wide: anything relying on that fall-through loses access, so add your specific rules first.

Next steps

Create a policy – start from the read-only pattern in Policy examples above.
Policies – how first-match-wins rule order and the seeded Allow all rule interact.

Secure Close access for AI agents

On this page