Configure MCP access for AI agents

Use the Finsaku MCP server to give an AI agent a defined set of status and administration tools. The agent acts through the Finsaku user who completes OAuth sign-in; it does not receive a separate permission grant when the MCP client is registered.

For

Tenant administrators and solution owners preparing an approved AI agent for Finsaku work.

Requires

The default https://mcp.finsaku.com/mcp address or the tenant-specific URL for a custom-domain tenant, a compatible agent client, an active Finsaku user, and scoped permission groups.

Available when

The deployment exposes OAuth discovery for its MCP server and the client supports remote MCP, dynamic client registration, and PKCE.

Before you begin

Define the task, data boundary, allowed writes, human approval points, test tenant, and evidence required after each run.

Expected result

The agent completes its intended calls, remains blocked from a neighbouring prohibited operation, and leaves verifiable Finsaku records.

How Finsaku controls an agent call

Authorised clientAgent requests a tool

OAuth sign-in→

Finsaku identityUser and tenant context

Check every call→

MCP serverPermission and input

Run existing service→

Verified resultFinsaku state and history

Check fails

Denied or invalidNo tool change

The MCP server is a deployment-level Finsaku access surface. It is not added under Administration → Integrations and it does not store an external provider credential in the tenant. A compatible client discovers the Finsaku authorisation service, registers as a public OAuth client, and uses browser sign-in with PKCE.

Registration proves that the client can take part in the OAuth flow. Effective access still comes from the signed-in user's active groups, tenant, affiliation, and any system permission required by the selected tool. Use Access model and troubleshooting when a connected agent can sign in but cannot complete a call.

Set the agent boundary

Define one bounded job before assigning permissions. The current MCP tool set supports:

• read-only application (quote) and loan (contract) status lookup by reference number;
• tenant, product, product-version, object-definition, lookup, and label configuration;
• document, email, and SMS template configuration;
• tenant-wide and product-specific event-action configuration;
• tenant settings, logo, and wallpaper management.

It does not return full customer records, filled customer fields, generated customer documents, or integration credential maps. Configuration reads can return template bodies and event-action settings. Review them for hard-coded customer data and secret webhook headers before granting the agent access. The server also does not expose tools for lending decisions, lending, payments, or loan changes.

Use those boundaries in the agent instructions. An agent should not claim it reviewed customer circumstances when its tools only returned a reference and status.

Prepare identity and permissions

1. Decide which named Finsaku user will complete the client's OAuth sign-in. MCP registration does not create a Finsaku service account.
2. Create a permission group for the bounded agent task, or review every existing group that supplies permissions to that user.
3. Add the list and read permissions needed to inspect current configuration before considering create or update access.
4. Add create or update permissions only for the records the agent is expected to manage.
5. Keep delete, complete-collection replacement, product-version activation, tenant settings, and branding permissions out of the group unless the task requires them.
6. Test with a non-production tenant or controlled configuration record before using the agent against production.

Permissions are cumulative. A narrow MCP group does not restrict broader access already supplied by another active group. Follow Permission groups to review every membership and test both an intended operation and a neighbouring operation that must remain unavailable.

Three agent use cases

1. Reference-status agent for an operations queue

An operations team receives application and loan references from an approved work queue. The agent checks each reference and returns its current Finsaku status so the team can route the item.

The agent uses only application and loan status tools. Each result contains the internal ID, reference number, and status; it does not contain the customer's name or application data. Grant the system permission quote:Read, contract:Read, or only the one required by the queue.

A suitable instruction is:

Check the Finsaku status for the supplied quote and contract references. Use read-only tools only. Return the reference and status, identify not-found results, and do not infer a customer's identity or eligibility.

Verify a sample of returned references by opening the corresponding applications or loans. Also test a reference outside the user's affiliation scope; the agent must not reveal whether that record exists.

2. Lending-product configuration agent

A product owner has an approved specification for a new lending product. The agent can inspect tenant currencies and existing product groups, reusable object definitions, and lookups; create the product and a draft version; and report the resulting configuration for review.

Keep activation as a separate approval point. Activating a product version deactivates its sibling versions, locks the activated version, and makes it available to the applicable application flow. Deleting a product also deletes its versions. The agent should reuse existing tenant-level objects and lookups where suitable instead of silently creating duplicates.

A suitable first instruction is:

Read the current Finsaku product, object-definition, lookup, and tenant-currency configuration. Compare it with this approved product specification and return a proposed sequence and field-level differences. Do not create, update, delete, or activate anything.

After review, authorise the specific create calls. Open the product and version in Administration and compare every collected field and term with the specification. In a non-production tenant, approve activation and start a test application. Schedule production activation only after the test result and the final product approval.

3. Template and event-action setup agent

An administrator needs a document generated, or an email or SMS sent, after a selected application or loan event. The agent can inspect existing templates, check safe availability metadata for enabled email, SMS, and document providers, create or update the template, and configure the product event action.

The provider check returns registration and availability information without credentials or setting values. For a document action or email attachment, the agent must use a template returned for the selected product and event. Saving the event action does not send a test message or prove that the provider will accept a later request.

A suitable first instruction is:

For product Consumer Loan, list the current message and document templates, enabled provider availability, and event actions for the approved event. Propose the template and event-action changes. Do not save them, expose provider settings, or invent a provider or template ID.

After approving the bounded change, trigger a representative event in a test context. Check Event Action Execution History, the generated document or message record, and the provider result before enabling the production workflow.

Give the agent operating rules

Put the following controls in the agent's standing instructions:

1. use list or read tools before proposing a write;
2. state the tenant, target record, current value, and proposed value;
3. use Finsaku IDs returned by tools instead of inventing them;
4. stop for human approval before create, update, activate, replace, delete, or asset upload calls;
5. never request or repeat customer PII, credentials, tokens, or integration settings;
6. make one bounded change, read the result back, and report how it was verified;
7. stop after an uncertain response until the current Finsaku state has been checked.

Some write tools replace a complete record or collection. Omitting an existing label from a complete label replacement deletes that label and its associations. Updating a configuration from a stale version can fail. These operations need a fresh read and an explicit comparison immediately before the write.

Connect and test the agent

1. Use https://mcp.finsaku.com/mcp as the default platform MCP server URL. If the tenant has opted for a custom domain, obtain and use its tenant-specific MCP URL instead.
2. Add it as a remote MCP server in the authorised agent client.
3. Complete browser sign-in as the test user prepared for the task.
4. Run a permitted read and compare the result with Finsaku.
5. Run a neighbouring prohibited operation or use a user without that permission. Confirm that Finsaku denies it.
6. In a non-production or controlled context, approve one reversible configuration write and read the record again.
7. Open the corresponding Administration record and history to confirm the actor, event, time, and stored values.
8. Sign out or disconnect the test client when the test is complete.

If sign-in never starts, check the complete server address and the client's support for OAuth discovery, dynamic client registration, public clients, and PKCE. The standard address is https://mcp.finsaku.com/mcp; a tenant using a custom domain must use its supplied tenant-specific URL. If sign-in completes but a tool fails, check the user's effective permissions, tenant and affiliation before changing the connection.

Give end users Use Finsaku through an MCP client for the connection, verification, privacy, and troubleshooting procedure.