stitch-mcp-get-project

Get Stitch Project Details

CRITICAL PREREQUISITE: You must ONLY use this skill when the user EXPLICITLY mentions "Stitch".

Constraints

Do NOT use this skill if:

• You already have both projectId and screenId and your goal is to get screen details or code. Use stitch-mcp-get-screen directly instead.

This skill retrieves the detailed metadata of a specific Stitch project.

Use Case

Invoke this skill when you need to know the context of a project (e.g., its default theme, device type) before generating new screens, or to verify project existence.

Input Parameters

The skill expects you to extract the following information from the user request:

• name (required): The resource name of the project. Format: projects/{project_id}.

Resource Path Parsing

If the user provides a resource path or URL, use the following rules to extract the project name:

1. Format: web application/stitch/projects/{projectId}

   • Logic: Extract projectId and construct the name as projects/{projectId}.

2. Format: projects/{projectId}

   • Logic: Use the string as is.

3. Format: https://stitch.withgoogle.com/projects/{projectId}

   • Logic: Extract projectId and construct the name as projects/{projectId}.

Example: Input "Describe web application/stitch/projects/12345", Call get_project(name="projects/12345").

Output Schema

Returns a Project object including:

• name, title, createTime, updateTime
• designTheme: Detailed theme settings.
• screenInstances: List of screen instances currently in the project.

Usage Example

User Input: "What is the theme of project 'projects/123'?"

Agent Action:

1. Identify the user wants details of a specific project.
2. Extract project name "projects/123".
3. Call get_project tool with arguments {"name": "projects/123"}.

References

• Examples

When to use

Load this skill when the user needs read-only discovery, inspection, or summarization of the current resource state . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Retrieves the detailed metadata of a specific Stitch project.

Rules

• Read before write: first confirm the current state and actual capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test output are missing, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase state; when results are unclear, query first and do not retry blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Perform prechecks

Confirm the query scope, identity context, pagination limit, and output fields; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute bounded read-only queries and retain source identifiers; retain an associable status or receipt for every external call.

Step 5: Verify delivery

Return the resource identifiers, query conditions, pagination state, and unverified items, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with the user's intent, and adjacent tasks were not misrouted to this skill.
• Inputs, target objects, versions, and output locations are all clear, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope of user authorization.
• Results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and actionable next steps.

Gotchas

1. Mistaking the plan for the result: documentation or prompts do not equal actual execution; the actual execution level must be indicated.
2. Retrying on error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-scale, publish, overwrite, and paid operations are not natural extensions of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Do not create, modify, or delete resources; if write operations are needed later, first hand off to the corresponding write skill and reconfirm. If the request requires another skill, do not copy its body text; hand off by skill name and retain the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When self-checking before delivery is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation refusal, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。