Verify your integration
A test script to run before you ship — tool discovery, per-category calls, natural language selection, and end-to-end workflows.
Connecting is not the same as working. This page is the check to run before you put the integration in front of users.
Before you start
- A connected client, per Connect an AI assistant.
- A test Marq account with at least one brand template, one image, and — if you use data tools — one dataset with a few rows.
- A tool timeout of 60 seconds or more.
Step 1: Connect and list tools
Confirm the client can complete discovery and see the tool list. Compare what it shows against the tools reference. A short list usually means the token is missing a scope, not that tools are missing.
Use MCP Inspector as your reference
MCP Inspector connects to the server directly and shows raw requests and responses. When your client behaves oddly, reproduce it in Inspector: if Inspector works and your client does not, the problem is in your client, and you have halved the search space.
Step 2: Call one tool per group
Work down the groups. Each of these is read-only and safe to run repeatedly.
| Group | Call | Expect |
|---|---|---|
| Templates | document_SearchTemplates with no filters | Templates from the test account |
| Images | image_SearchImages with a keyword you know matches | Ranked results |
| Data | data_ListDataSets | Datasets with their collections |
| Brand kit | brand_GetBrandKit | Kits, and colors/fonts/logos keyed by brand role |
| Document read | dmes_GetDocumentStructure on a test project | Page count and per-page summary |
| Document edit | dmes_ReplaceStyledText on a throwaway project | Changed text, formatting intact |
| Export | conversion_ExportDocument | A download URL and file name |
If brand_GetBrandKit returns assets with a null schemaKey, that is expected — those assets are not mapped to a brand role and cannot be applied.
Step 3: Check natural language tool selection
Tool descriptions are the only thing steering the model's choice, so verify that plain requests land on the right tool. Ask, and watch which tool fires:
| Prompt | Should call |
|---|---|
| "What templates do we have for events?" | document_SearchTemplates |
| "What does page 2 say?" | dmes_GetAllText or dmes_GetTextContent |
| "Change the headline to Spring Launch" | dmes_ReplaceStyledText |
| "Make this match our brand" | brand_GetBrandKit, then dmes_ApplyBranding |
| "Send me a PDF" | conversion_ExportDocument |
Step 4: Run end-to-end workflows
Single calls passing tells you little. These four chains are the ones real usage produces.
Template to finished project
document_ListTemplateCategories→document_SearchTemplatesdocument_CreateProjectFromTemplatedmes_GetSmartFields— if it reports that values are needed, ask the user for themdmes_ApplyUserSmartFields/ApplyTeamSmartFields/ApplyProjectSmartFields
Brand kit passthrough
brand_GetBrandKit- Pass its
brandingfield straight intodmes_ApplyBranding
The assistant should not ask the user for hex values or font names. If it does, your client is dropping part of the tool result.
Image search to placement
image_SearchImagesdmes_SetBlockImagewith the returned image ID, ordmes_CreateImageBlockfor a new blockconversion_ExportDocument
Read before targeted edit
dmes_GetStyledTextContenton the blockdmes_ReplaceStyledTexton the range you identified
Editing without reading first is the most common cause of a wrong-looking result, because the assistant guesses at the existing formatting.
Step 5: Test alongside other servers
Users connect several MCP servers at once, and tool names collide conceptually — every server has something called "search." Connect Marq alongside the other servers your product ships with and re-run step 3. If the model reaches for the wrong server, the fix is usually in your system prompt, naming the Marq server for design and brand work.
Common tool-call mistakes
Editing a template instead of a project. Templates are shared assets. Create a project from the template, then edit the project. Only edit a template when the user explicitly asks to change the template itself.
Parallel edits to one document. Two edit calls in flight against the same document return a 409 conflict. Batch edits into a single request, or run them serially. Reads can go in parallel.
Skipping the smart-field check. After opening or creating a document, call dmes_GetSmartFields first. If it reports that values are needed, prompt the user rather than leaving placeholders in the output — a document full of unresolved smart fields looks broken even though every call succeeded.
Treating a smart-field document as empty. Raw text full of {{ }} expressions is a template that has not been filled, not an empty document.
Timing out on export. Export renders a file. Give it the full timeout.
Automate it
Once the script passes by hand, keep it. The chains in step 4 make good integration tests, and tool descriptions change — a run against a test account on each release catches a tool that quietly stopped being selected long before a user reports it.
Ignoring a 429. The limit is 30 requests per minute per session. A chain that fans out reads across many blocks can reach it. Honour Retry-After rather than retrying immediately.
Letting the token go stale. Access tokens last an hour. Confirm your client refreshes without dropping the user back into a sign-in prompt mid-task.
If something fails
See Troubleshooting.
Updated 3 days ago