Cross-Project Search

Find items by a text query across many projects at once — or across every project you can access. This is a read-only capability.

Select the tool by capability, not by a fixed name. These tool names and parameters have changed more than once, so confirm against the tools actually available in this session rather than assuming. As of this writing:

To find…	Tool	Notes
Source strings by text / context / key	search_strings	scope = all (default) | text | context | key
Target-language translations by text	search_translations	optional target languageIds (e.g. uk,de)
Source files by name / title	search_files	file-based projects only
Branches by name / title	search_branches	—
Directories by name / title	search_directories	file-based projects only

Inputs

• filter (required) — the text to search for. Max 128 characters; longer is rejected outright. Note the name is filter, not query.
• projectIds (optional) — comma-separated project IDs, max 50; a longer list is rejected as an invalid request, not run slowly. See Scoping — usually you should leave it out.
• limit (1–500, default 25) / offset — pagination.

Scoping

Default: omit projectIds. Don't ask the user which projects to search — run the search and report what you found. Omitting it also lifts the 50-project cap, which applies only to an explicit list.

Be aware of what "omitted" actually covers, because it differs by platform:

• Crowdin Enterprise — every project in the current organization that the user can read.
• crowdin.com — only projects the user owns. Projects they merely collaborate on, owned by someone else, are not searched.

So on crowdin.com, if the user expects a match in a project they don't own, an omitted search will miss it. Two ways to reach those projects:

• pass projectIds for the specific projects, resolving names to IDs with list_projects; or
• pass userId (crowdin.com only) to search that owner's projects instead of the caller's. Results stay filtered to what the caller is allowed to read, so this cannot expose anything new. Only use it with a real user id you already have — never invent one.

Either way, don't silently report "not found": say which scope you actually searched.

An explicit list must stay within a single owner (all projects of one organization); a mixed list is rejected. On Enterprise that is automatic, since everything lives in one organization.

How matching works

Knowing this prevents confidently reporting "not found" when the query was simply shaped wrong:

• Match is case-insensitive substring, so Save also hits Saved and Unsaved.
• A multi-word filter is split on spaces and every word must match (though different words may match in different fields). A long pasted sentence will usually return nothing — search a distinctive word or a short phrase instead.
• % and _ are literal characters, not wildcards.
• Hidden strings are excluded from results.

Reach for a different tool instead when:

• The scope is a single, already-known project → use that resource's single-project listing/filter tool (e.g. list_strings with a filter), not cross-project Search.
• You need fuzzy TM or glossary matches → use the concordance tools. They are driven by a source/target language pair plus expressions rather than a plain text filter; read each tool's own schema for its remaining required inputs, which differ between them. Project-scoped: concordance_search_in_tms / concordance_search_in_glossaries. Account-wide (every TM / glossary you own or manage, no project needed): concordance_search_in_all_tms / concordance_search_in_all_glossaries.
• You already have the item's ID → fetch it directly by ID.

Handling problems

• "Search query is too broad…" — the server gave up on the query rather than failing. Make filter more distinctive, narrow to a projectIds list, or (for strings) set a specific scope instead of all. Never re-send the same request unchanged.
• A project isn't found → drop that id from projectIds and retry with the rest.
• Empty result from search_files / search_directories → these only cover file-based projects. Don't report "nothing exists" if the projects in question are string-based.

Presenting results

Group matches by project, and by file within a project — when a search spans the whole organization, which project a hit came from is the context the user is missing, so never present a flat list of texts. Follow the normal output conventions for whether that becomes a rendered table or plain markdown. If results are paginated, say so and offer the next page.