Verify generated code

Check AI-generated Veracity integration code against current official documentation before you commit or deploy, so you catch outdated endpoints, deprecated parameters, and incorrect authentication patterns at development time.

An AI agent (a program such as Cursor, GitHub Copilot, or Claude Code that uses an LLM to read your code, run commands, and call APIs) generates integration code from training data that has a knowledge cutoff. Veracity APIs change: endpoints move, parameters are renamed, authentication flows are updated. Code generated from stale training data can pass local tests and still fail in production when it calls an endpoint that no longer exists or passes a parameter that has been removed. The Veracity Development MCP Server gives your agent access to current documentation so you can verify generated code before it leaves your development environment.

Before you start

You need:

• The Veracity Development MCP Server installed and configured in your agent
• A code editor or terminal where your agent is active
• The AI-generated integration code you want to verify

Verify generated code with the MCP server

1. Identify the Veracity API calls in the generated code. List each endpoint, HTTP method, and the parameters the generated code passes. You can ask your agent to produce this list: "List all Veracity API calls in this file, including the endpoint path, HTTP method, and parameters."

2. For each API call, ask your agent to retrieve the current documentation using the Veracity Development MCP Server:

   Check the Veracity documentation for the [endpoint name] endpoint and confirm
   whether the path, parameters, and authentication requirements in this code are correct.
   

   The agent uses the MCP server's search_Veracity_dev_docs and get_Veracity_api_method tools to retrieve live documentation and compare it against the generated code.

3. Review the agent's response for each discrepancy it reports. Common issues include:

   • Endpoint path has changed (for example, a version prefix added or removed)
   • A required parameter is missing from the generated call
   • A parameter name has been renamed
   • The authentication header format differs from the current specification
   • A scope or permission requirement has been added since the training data cutoff

4. Update the generated code to match the current documentation. Ask the agent to regenerate specific calls where discrepancies are found: "Rewrite this API call to match the current Veracity documentation you retrieved."

5. Repeat for every Veracity API call in the generated code. Do not assume that because one call is correct, others from the same generation session are also correct. Training data inconsistencies are not uniform.

Verify authentication and token handling

6. Ask your agent to check the token acquisition and refresh logic against current Veracity Identity Provider documentation:

   Check the Veracity documentation for the current OAuth token endpoint and confirm
   whether the grant type, scope format, and token refresh approach in this code are correct.
   

7. Confirm that the generated code uses the correct audience value for the Veracity environment it targets. Development and production environments use different audience values; AI-generated code sometimes hard-codes one or omits the field entirely.

Verify access control patterns

8. Ask your agent to check tenant context handling against current Veracity Tenant Management documentation. Confirm that the generated code passes tenant identifiers in the location and format the current API requires. See also Handle tenancy boundaries.

9. Confirm that the permission scopes requested in the generated code match the scopes your registered application is approved for. The MCP server can retrieve the scope definitions; your application's approved scopes are visible in the Veracity developer portal.

Before committing

• Run a final check: ask your agent to summarise any remaining differences between the generated code and the current Veracity documentation. If the agent reports no differences and you have addressed all previous discrepancies, proceed to testing.
• Follow the guidance in Test before production to validate the verified code against Veracity development credentials before requesting production access.

Limitations

• The Veracity Development MCP Server retrieves current documentation but does not execute code or make API calls on your behalf. Verification confirms documentation alignment, not runtime behaviour: testing is a separate step.
• The MCP server covers the Veracity platform APIs documented on the Veracity developer portal. It does not cover third-party APIs your integration may call alongside Veracity.
• If the agent reports that it cannot find documentation for a specific endpoint, the endpoint may be deprecated or the naming may differ from the generated code. Search the Veracity developer portal directly and update the generated code to match what you find.