Search for the pain, not the app idea.

Write problem-shaped queries

Describe the user, workflow, friction, or repeated job. Avoid starting with the solution you already want to build.

What search returns

Through MCP, search_problems(query) returns concise candidates built from existing Immensity clusters.

• clusterId — the stable problem-cluster identifier used to create a project.
• name — the cluster's short label.
• problemStatement — the normalized statement of the pain.
• summary — a concise description of the recurring problem.
• evidenceCount — how much stored source evidence supports the cluster.
• sources / communities — where the evidence came from.
• hasProject — whether the signed-in user already has a project for it.

Evaluate a result before creating a project

A high evidence count is useful, but it is not enough by itself. Look for a problem statement that is specific, repeated, and attached to a recognizable user or workflow.

1. Read the problem statement and ask whether the pain is concrete.
2. Check the evidence count and source diversity.
3. Look at the communities to understand who is experiencing the problem.
4. Prefer a problem with a clear repeated job over a one-off complaint.
5. Create the project only when you want to investigate it further.

Turn a result into a project

In an MCP client, the normal sequence is:

search_problems("freelancers chasing unpaid invoices")
→ choose clusterId
create_project_from_problem(clusterId)

create_project_from_problem creates the project for the signed-in account or returns the existing owned project if you already created one from that cluster.

Search iteratively

If a query is too broad, narrow the workflow or user. If it is too narrow, remove product-specific language and describe the underlying job instead.