sites_listLABSCO SUMMARY
Closing the build-verify-fix loop against a real browser.
The agent that wrote the feature is a poor judge of it. Squidler exercises the app from natural-language use cases and hands back the friction it found, so the fix comes from what a user hit rather than from the implementation the agent already believes in.
What it is
A hosted MCP server for Squidler, which exercises a web app the way a person would from use cases written in natural language rather than DOM selectors. Through it an agent registers sites, writes and runs those use cases as test cases, and reads back the problems the runs found; built-in instructions teach the client a test-after-feature workflow.
What you get
- Test cases written in plain language through a guided conversation, labelled by feature, and run one at a time, by label or all together
- Each run's pass/fail outcome, with its execution events and screenshots, and the problems it found, listed and summarised
- One problem opened in full
- Sites, labels, custom headers and test logins managed from the same connection, persona UX reviews run on validated test cases, and problems resolved or dismissed once dealt with
- Built-in agent guidance, so the client knows the workflow without you explaining it
Requirements
A Squidler API token from the integrations page, sent as a bearer token to the HTTP endpoint. Nothing is installed.
Setup effort
Add the hosted endpoint plus a key — paste it into your client, then supply credentials
USE CASES
01
Finding what broke after a feature shipped
Read the summary first, then the full problem list, before touching the code.
02
Understanding one failure in detail
Open the problem and read what the run actually did.
03
Clearing the board after a fix
Resolve what is fixed and dismiss what is not a defect, so the next run is legible.
04
Putting a new app under test
Register the site, then read its detail back to confirm what is being exercised.
05
Checking the state of everything you have registered
One list covers all the sites rather than one dashboard each.
51 tools
Listed in project docs. Your client may show a different list.
site_detailssite_createproblems_summaryproblems_listproblem_getproblem_resolveproblem_dismisstest_case_createtest_case_create_respondtest_cases_listtest_case_gettest_cases_list_by_labelvalidate_test_casetest_case_updatetest_case_deletetest_case_runtest_cases_run_alltest_cases_run_by_labeltest_case_create_standalonevalidate_test_case_texttest_case_run_standalonetest_case_runs_standalone_listtest_case_promotetest_runs_listtest_case_polltest_run_outcometest_run_eventstest_run_stoppending_checks_listlabels_listlabel_getlabel_createlabel_updatelabel_deletetest_case_labels_addtest_case_label_removeheaders_listheader_addheader_deletecredentials_listcredentials_create_userpasscredentials_create_emailcredentials_create_oidcpersonas_listpersona_review_runpersona_review_findingspersona_findings_listpersona_finding_triageaccount_statusaccount_upgrade_urlBEFORE YOU INSTALL
What to know first
Tools you get
51 tools named in the project's documentation.
Requires
- A Squidler account and API token
- A client that can send an Authorization header to a remote MCP server over HTTP
Where it runs
The documented client connects to a hosted endpoint.
INSTALLATION
Connect your client
Server setup
ENDPOINT URL
https://mcp.squidler.ioAdd this hosted endpoint to your MCP client using the credentials listed under Requirements.
MCP Clients
Any MCP client
ANY MCP CLIENT · JSON
{
"mcpServers": {
"squidler": {
"type": "http",
"url": "https://mcp.squidler.io",
"headers": {
"Authorization": "Bearer <YOUR_SQUIDLER_API_TOKEN>"
}
}
}
}<YOUR_SQUIDLER_API_TOKEN> is the API token from squidler.io/integrations/api-keys. The token travels in the Authorization header, so use a client that can send headers to a remote server.
