Common AI tasks

Worked examples for the most common Veracity integration tasks using an AI agent, with prompts that apply correct Veracity patterns from the start.

Complete the most common Veracity integration tasks using an AI agent, with example prompts that apply the right Veracity patterns from the start.

Each task below names what you are trying to do, lists the skill or prompt that primes your agent with the correct Veracity context, and gives a worked example you can adapt. An AI agent is a program (Cursor, GitHub Copilot, Claude Code, or a compatible tool) that uses an LLM to read your code, run commands, and call APIs on your behalf.

Before you start

For all tasks:

Install and configure the Veracity Development MCP Server so your agent can retrieve current API and authentication documentation
Install the relevant agent skill or add the prompt file described in each task below

Identity and authentication

Implement Veracity authentication

Add OAuth-based authentication to an application using the Veracity Identity Provider.

Prompt template:

Using the current Veracity Identity Provider documentation from the Veracity Development MCP Server,
implement [authorisation code / client credentials] flow authentication for this application.
Store all credentials as environment variables. Do not inline any credential values.

Use authorisation code for user-facing apps; use client credentials for service-to-service integrations. Optionally add your language and framework, for example: for a Node.js Express app.

What to check in the output:

Token acquisition uses the authorisation code flow, not client credentials, for user-facing apps
Refresh logic is present and handles token expiry without re-prompting the user
No credential literals appear in the generated code

Generate an authenticated API call

Generate a correctly authenticated call to any Veracity API endpoint.

Prompt template:

Using the current Veracity API documentation from the Veracity Development MCP Server,
generate an authenticated [HTTP method] call to [describe the operation].
Include error handling for 401, 403, and 5xx responses.

What to check in the output:

The authorisation header uses a bearer token retrieved from the identity provider, not a hard-coded value
401 and 403 are handled as distinct error cases
The endpoint path and HTTP method match current Veracity documentation

Access management (VTM)

Scope access to a tenant

Generate code that enforces tenant boundaries using Veracity Tenant Management (VTM).

Prompt template:

Using the current Veracity Tenant Management documentation from the Veracity Development MCP Server,
generate a [language] function that retrieves [resource] for tenant ID {tenant-id}.
Pass the tenant identifier as an API parameter. Do not filter client-side.

Replace [language] with your language (for example, TypeScript) and [resource] with the specific resource you are retrieving.

What to check in the output:

The tenant identifier is passed as an API parameter, not applied as a post-query filter
No hard-coded tenant IDs appear in the generated code
The function does not fall back to a default tenant if the parameter is missing

Data platform (Data Workbench)

Query workspace-scoped data

Generate a data query that operates within a specific Data Workbench workspace and returns only authorised records.

Prompt template:

Using the current Data Workbench API documentation from the Veracity Development MCP Server,
generate a [language] function that retrieves [resource] for workspace ID {workspace-id}.
Pass the workspace identifier as an API path parameter. Do not filter client-side.

Replace [language] with your language (for example, TypeScript) and [resource] with the specific data you are querying, for example: all datasets.

What to check in the output:

The workspace identifier is passed as a path parameter, not applied as a post-query filter
Access checks operate at the resource level, not only at the route level
No hard-coded workspace or tenant IDs appear in the generated code

Process regulated maritime data

Generate integration code that accesses Veracity regulated data with the correct access controls applied.

Prompt template:

Using the current Data Workbench API documentation from the Veracity Development MCP Server,
generate a [language] function that queries [data type] data for [entity] where my service
account has confirmed read access.
Apply server-side filtering, log the API call at query time, and do not cache the response
beyond the current request lifecycle.

Replace [data type] with the regulated dataset (for example, Emissions Connect) and [entity] with the unit of data access (for example, vessels).

What to check in the output:

Filtering is applied as API parameters, not in application code after a full dataset is returned
A logging statement is present at the point of the API call, not only at display or export
The response is not assigned to a persistent cache

Code review

Review generated code for Veracity correctness

Verify that generated code follows Veracity conventions before committing.

Prompt template:

Review this code for Veracity integration correctness. Check:
1. Are all credential values read from environment variables?
2. Is the tenant identifier passed explicitly on every API call?
3. Are 401 and 403 responses handled distinctly?
4. Do the endpoint path and parameters match current Veracity documentation?

Use the Veracity Development MCP Server to verify against current documentation where needed.

What to check in the output:

The review addresses all four checks, not a subset
Any flagged issues reference specific lines or functions
Suggestions match current Veracity documentation, not outdated patterns