MCP server
The inference-bureau MCP server gives a coding agent what Auditor knows: the review findings open on its pull request, in any repository Auditor reviews, and, for a Shopify theme, the store behind the repository: the theme as merchants have set it up, the content that depends on each setting, what changed on the store, pictures of its pages, and its pull request previews.
What it is for
An agent fixing a pull request should not have to scrape GitHub for what Auditor said about it. The findings tools give it each open finding in full, with a prompt for fixing it, and let it close each one once it is dealt with, which resolves the thread on GitHub as a review would. They work on every repository Auditor reviews, with or without a store. See Findings over MCP.
For a Shopify theme there is more to know than the code. A theme repository holds the code. The store holds what merchants did with it: templates, section groups and theme settings full of their content, and files that Shopify's AI or the code editor changed. An agent working from the checkout alone cannot see any of that, so it renames a setting that forty templates use, or reads a metafield the store never defined. This server lets the agent ask the store first. It reads the store each repository's theme previews deploy to, the same way previews reach it: through the team's Shopify sign-in or the repository's Theme Access password. It changes nothing on the store, except that preview_deploy deploys a pull request's preview theme. It never touches the published theme.
Connecting an agent
The server is at https://api.inferencebureau.com/v1/mcp and takes an API key of your team as a bearer token: create one on a project's API Keys page and put it in IB_API_KEY, or in place of it below. It speaks Streamable HTTP, so any client that supports remote MCP servers can connect. Its name is inference-bureau, as the examples add it; for a Shopify theme it sits beside Shopify's own Dev MCP server, which answers questions about Shopify's APIs rather than your store.
claude mcp add --transport http inference-bureau https://api.inferencebureau.com/v1/mcp \
--header "Authorization: Bearer $IB_API_KEY"When the team has one repository Auditor reviews, the findings tools use it without being told, and when it has one repository with a store, so do the store tools. With several, the agent passes repo as owner/name; list_stores lists the repositories with a store.
Tools
Findings, for any repository Auditor reviews:
| Tool | What it answers |
|---|---|
list_findings | The findings open on a pull request, given its number or the branch it is from (status: "all" adds resolved and dismissed ones), worst first, with ids and links to their comments. |
get_finding | One finding in full: the explanation, the suggested replacement, the flagged code, and a prompt for fixing it. |
get_review | The latest review of a pull request: the commit, what it checked, its notes, and how many findings are open by severity. |
resolve_finding | Closes a finding once it is dealt with: fixed, or wont_fix with a note saying why. Resolves the thread on GitHub and notes the outcome on the comment. If the flagged code is still there after the push, the next review raises it again. Needs a key with Auditor Permissions. |
Store, for a Shopify theme repository with a store chosen on its Shopify tab:
| Tool | What it answers |
|---|---|
list_stores | The team's repositories with a store chosen, the store each deploys to, and its public theme guide. |
theme_outline | Every section, theme block and theme settings group, under the names the editor shows, with the blocks each takes and where the store places it. |
section_schema | One section, block or settings group in full: settings with labels, defaults, options and ranges; blocks; presets; where it may be added; and what your theme guide tells merchants about it. |
content_usage | Every place the store's content uses a section, block or setting, with the values merchants chose. With setting, how many set it and to what. The agent should call this before renaming or removing a setting id, block type, section or preset. |
store_files | The theme's files with size, MD5 checksum and last change, to find what changed on the store compared with the checkout. |
read_store_file | One file as the store holds it now, such as a template with its content or config/settings_data.json. |
store_definitions | Metafield definitions for products, variants, collections, pages and the rest, as the Liquid that reads them (product.metafields.custom.size_chart), and metaobject definitions with their fields. A Theme Access password reaches themes only, so this needs the team's Shopify sign-in. |
template_assignments | Each alternate template (product.bundle, page.contact) with the products, collections, pages, blogs and articles assigned to it, and assignments to templates the theme does not have. A product assigned to a template that is removed falls back to the default without warning, so the agent should call this before removing or renaming one. Needs the team's Shopify sign-in. |
store_drift | Every template, section group, settings and locale file on the store that differs from a branch (the default branch unless branch names another), with its path in the repository. With content, the store's copies too, ready to write into the checkout: the files @auditor pull would commit. |
page_screenshot | A picture of a storefront page at a chosen width: the viewport, the whole page, or one section. Console errors and Liquid errors the page shows come with it. A browser starts for each picture, so the first call can answer “still working” with a capture to ask again with. |
preview_status | A pull request's preview: links, the commit deployed, render errors on the checked pages, and content the published theme has that the branch lacks. |
preview_deploy | Deploys a pull request's newest commit to its preview theme, as commenting @auditor preview does. Follow it with preview_status. Needs a key with Auditor Permissions. |
The Auditor CLI calls the same store tools: auditor preview deploy, auditor drift, auditor templates and auditor screenshot.
Which theme is read
The store tools read the store's published theme unless given theme (a theme number) or pr (a pull request, whose preview theme is read instead). A theme is read once and kept for a minute, so a run of questions about it does not read the store again each time.
Keys and cost
Any API key of the team works, except for preview_deploy and resolve_finding, which need a key with Auditor Permissions. A key reaches every repository of its team that Auditor reviews: the findings tools work on all of them, and the store tools on those with a store chosen. Give an agent a key you would trust with your findings and your stores' content. The server runs no model, so calls are not billed and do not count toward Directives budgets. Pictures are taken in a short-lived VM that holds only the storefront password, can reach only the store and its font and asset hosts, and sends nothing but reads.