Carrick

Search functions by what they do

search_by_intent

Read-onlyIdempotent

Search every function in this project by what it does, including sibling repos you do not have checked out. Pass a plain-English concept ('verify a webhook signature'); matches need no keyword overlap. Use it before writing any helper, parser, validator or domain function, even when you are sure it is new — grep can prove a name is absent but never that the behaviour is. A row whose only tie to the query is a word most functions share is counted in the response rather than ranked. To browse instead, use list_function_intents. For a set of functions you are about to write or have just written, and for a whole-project reuse audit, use find_similar.

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": {
      "query": "<query>"
    },
    "name": "search_by_intent"
  }
}

Input Schema

Name	Required	Description
`repo`	No	Your repo as owner/repo (git remote) or just the repo name. Resolves which Carrick project to query.
`query`	Yes	Plain-English description of what the function should do (e.g. 'verify webhook HMAC signature', 'normalize email addresses')
`top_k`	No	How many top matches to return (default 8). Keep tight — the agent should drill in on a few good matches rather than skim a long list.
`offset`	No	Rank offset into the matches (default 0). Pass the `next_offset` from a previous call to page through.
`compact`	No	Return locator-only rows (name, path, lines, similarity) instead of full detail. Use for wide enumeration.
`project`	No	Carrick project slug to query. Omit to auto-resolve via `repo`, or omit both when the workspace has one project.
`also_phrased_as`	No	Up to 2 further wordings of the same concept, such as the mechanism ('sha256 of a JSON body') beside the purpose ('hash a value to a cache key'). Purpose wording and mechanism wording reach different functions, so one call runs both and returns one deduped list, with matched_phrasings on each row naming the wordings that found it. For separate questions, call the tool once per question.
`similarity_threshold`	No	Cosine-similarity floor for inclusion (default 0.3). Raise to filter weak matches; lower to surface more candidates.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedSep 28, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: matches need no keyword overlap, query-only-word ties are counted rather than ranked, and multi-phrasing calls return one deduped list. It stops short of describing the result row shape or paging behavior, which matters somewhat given there is no output schema.

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 the action and scope, then justification, then routing. Four sentences, all carrying weight. Slight deduction because the clause about a row tied only by a shared word being 'counted in the response rather than ranked' is compressed enough to be ambiguous on first read.

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?

For an 8-parameter semantic search tool with no output schema, the description covers the critical unknowns: cross-repo reach, non-lexical matching, dedup across phrasings, and sibling routing. Missing is any statement about what a returned row contains or how paging works, though the schema's offset/next_offset description partially compensates.

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 description coverage is 100%, so the baseline is 3; the description earns above that by clarifying that `query` takes a plain-English concept with no keyword overlap required, which is a semantic point the schema alone does not establish. Parameters that need the most care (also_phrased_as, top_k) are already fully documented in the schema and are not restated here.

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?

States a specific verb and resource (search functions) plus the distinctive scope: semantic search across the whole project including sibling repos not checked out. It explicitly separates itself from list_function_intents (browsing) and find_similar (sets of functions / audit), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use trigger ('before writing any helper, parser, validator or domain function') and a justification for why grep is insufficient, which is the key competing alternative. Names both sibling alternatives and the conditions that select them ('to browse instead', 'for a set of functions... use find_similar').

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

All Carrick tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.