Bloom

Search canvas code

code_search

Search canvas TSX. The search spans all pages unless canvasPageId narrows it, follows branch inheritance, and repairs an empty index from canonical Yjs source once. Hits include stable JSX sourcePath locators (50 per page; continue with elementsCursor and the same query), truncatedElementsCount, page identity, contentHash, import relationships and own/parent provenance. Geometry and edit history are not included. Project source code and public repositories are outside this operation's scope; search them with your own tools. Scope: project:read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target": "<target>",
      "query": "<query>"
    },
    "name": "code_search"
  }
}

Input Schema

Name	Required	Description
`query`	Yes	Search text. Matched against source content; not a regular expression.
`cursor`	No	Continue one matching frame’s element list using its elementsCursor and the same query. For searches matching several frames, continue with read_files per frame.
`target`	Yes	Where to search. Only `canvas`: frame source on the branch. Search a Bloom project's code with your own tools.
`branchId`	No	Target branch id. Omit it — Bloom derives the branch from the frames you name, from the token's narrowing, or from your only readable branch, and enumerates the candidates if it genuinely cannot.
`canvasPageId`	No	Narrow a `canvas` search to one page. Omit it — a canvas search spans every page of the branch's project, which is what you want when you do not yet know where a frame lives.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false, which would otherwise look wrong for a search; the description explains why by disclosing that it repairs an empty index from canonical Yjs source once. It also discloses pagination (50 per page, continue with elementsCursor and the same query), truncation counts, provenance, and what is deliberately excluded (geometry, edit history).

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?

Front-loaded with purpose and scope, then behavior, then exclusions — a sensible order with no filler sentences. It is dense and packs several distinct facts into one long sentence, which costs a little readability but nothing is wasted.

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

Completeness5/5

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

There is no output schema, and the description compensates by enumerating the returned fields (sourcePath locators, truncatedElementsCount, page identity, contentHash, import relationships, provenance) and the pagination contract. For a five-parameter read tool with a side effect, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that canvasPageId narrows an otherwise all-pages search, that branchId is normally derived and should be omitted, and that cursor must be paired with the same query. It does not restate the query-matching semantics, which the schema already covers.

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 opens with a specific verb and resource ("Search canvas TSX") and immediately bounds the scope: canvas frame source on a branch, not project code or public repositories. An agent can distinguish it from read_files or design_inspiration_search without opening the schema.

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

Usage Guidelines4/5

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

It gives clear when-to-use context (search spans all pages when you don't yet know where a frame lives) and explicit when-not guidance (project source and public repos are out of scope, use your own tools). It stops short of naming sibling tools like read_files as the alternative for multi-frame continuation, leaving that routing implicit.

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

All Bloom tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?