Skip to main content
Glama
saucelabs

Sauce Labs MCP Server

Official
by saucelabs

lookup_builds

Query and filter Sauce Labs builds to retrieve summaries and IDs for monitoring test execution across real devices or emulators.

Instructions

    Queries the requesting account and returns a summary of each build matching the query, including the ID value,
    which may be a required parameter of other API calls related to a specific build. You can narrow the results of
    your query using any of the optional filtering parameters.
    :param build_source: The type of device for which you are getting builds. Valid values are: 'rdc' - Real Device
        Builds, 'vdc' - Emulator or Simulator Builds
    :param user_id: Optional. Returns any builds owned by the specified user that the authenticated user is authorized to view. You can look up the IDs of users in your organization using the Lookup Users endpoint.
    :param org_id: Optional. Returns all builds in the specified organization that the authenticated user is authorized to view.
    :param group_id: Optional. Returns all builds associated with the specified group that the authenticated user is authorized to view.
    :param team_id: Optional. Returns all builds for the specified team that the authenticated user is authorized to view.
    :param status: Optional. Returns only builds where the status matches the list of values specified. Valid values are: running - Any job in the build has a state of running, new, or queued. error - The build is not running and at least one job in the build has a state of errored. failed - The build is not running or error and at least one job in the build has a state of failed. complete - The build is not running, error, or failed, but the number of jobs with a state of finished does not equal the number of jobs marked passed, so at least one job has a state other than passed. success -- All jobs in the build have a state of passed.
    :param start: Optional. Returns only builds where the earliest job ran on or after this Unix timestamp. Note: If experiencing errors, try providing both start and end parameters together.
    :param end: Optional. Returns only builds where the latest job ran on or before this Unix timestamp. Note: If experiencing errors, try providing both start and end parameters together.
    :param limit: Optional. The maximum number of builds to return in the response.
    :param name: Optional. Returns builds with a matching build name.
    :param offset: Optional. Begins the set of results at this index number.
    :param sort: Optional. Sorts the results in alphabetically ascending or descending order. Valid values are: asc - Ascending desc - Descending
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
build_sourceYes
user_idNo
org_idNo
group_idNo
team_idNo
statusNo
startNo
endNo
limitNo
nameNo
offsetNo
sortNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that this is a query/read operation (implied by 'queries' and 'returns'), mentions authorization requirements ('authenticated user is authorized to view'), and provides some behavioral notes (e.g., error handling suggestion for start/end parameters). However, it lacks details on rate limits, pagination behavior beyond limit/offset, or what happens with no matches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with the core purpose, but becomes verbose with detailed parameter documentation that might be better placed in schema descriptions. While each sentence adds value, the structure mixes high-level purpose with low-level parameter details, making it less streamlined than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (12 parameters, no annotations, but has output schema), the description is quite complete. It covers the tool's purpose, parameter semantics thoroughly, and some behavioral context. The existence of an output schema means return values don't need explanation. Minor gaps remain in explicit sibling differentiation and comprehensive behavioral disclosure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides extensive parameter semantics beyond the input schema, which has 0% description coverage. For all 12 parameters, it explains their purpose, valid values (e.g., build_source: 'rdc' or 'vdc'), usage notes (e.g., user_id requires lookup via another endpoint), and behavioral implications (e.g., status values map to job states). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Queries the requesting account and returns a summary of each build matching the query.' It specifies the verb ('queries'), resource ('builds'), and output ('summary of each build including ID value'). However, it doesn't explicitly differentiate from sibling tools like 'get_build' or 'lookup_jobs_in_build', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through parameter explanations (e.g., 'You can narrow the results using optional filtering parameters') and mentions that the ID may be required for other API calls. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_build' (for single builds) or 'lookup_jobs_in_build', nor does it mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/saucelabs/sauce-api-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server