Skip to main content
Glama
saucelabs

Sauce Labs MCP Server

Official
by saucelabs

lookup_builds

Retrieve build summaries with filters like status, time range, and name. Obtain build IDs needed for further API calls.

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?

No annotations are provided, so the description alone must disclose behavior. It describes a query operation that returns summaries, which implies read-only, but does not explicitly state it is non-destructive. It does not mention rate limits, authentication details beyond 'requesting account', or how pagination works (though offset and limit are parameters). The description is adequate but lacks explicit safety or side-effect information.

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

Conciseness4/5

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

The description is structured as a docstring with parameters listed, but it is somewhat verbose with full sentences for each parameter. The main purpose is front-loaded in the first sentence. While clear, it could be more concise by using a list format. Every sentence provides value, but the length is higher than necessary.

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, 1 required) and the presence of an output schema (not detailed in the description), the description adequately covers the tool's purpose and filtering capabilities. It mentions that the returned ID is useful for other APIs. However, it does not describe pagination behavior (e.g., default limit, how to get next page) or the structure of the response beyond 'summary'. Still, it is mostly complete for a query tool.

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 input schema has 0% description coverage, so the description carries the full burden of explaining parameters. It provides detailed documentation for each parameter: meaning valid values for build_source and status, usage hints for start/end (e.g., provide both), and clarity that user_id, org_id, etc. filter by ownership and authorization. This adds substantial meaning beyond the bare schema.

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

Purpose5/5

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

The description clearly states that the tool queries the requesting account and returns a summary of builds, including the ID which is a required parameter for other build-related API calls. It specifies that the results can be narrowed with filtering parameters, and lists required parameter 'build_source' with valid values. This distinguishes it from sibling tools like 'get_build' (single build) or 'lookup_jobs_in_build'.

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 explains that the tool is for listing builds with optional filters, but does not explicitly state when NOT to use it or mention alternatives. There is no guidance on prerequisites or comparisons to sibling tools like 'get_build' or 'get_build_for_job'. Usage is implied but not explicitly differentiated.

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