Carrick

Browse indexed functions and intents

list_function_intents

Read-onlyIdempotent

List indexed functions with their one-line intents, paginated; filter by service or substring. The index covers every function with an intent, not just exported ones. Use it to browse what a service contains or compare what sibling repos have built. Pass file to answer "what can I call in this file" without reading it, with compact for signature-only rows. For concept queries ('dedupe users by email'), use search_by_intent instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_function_intents"
  }
}

Input Schema

Name	Required	Description
`file`	No	Path suffix of the file to list functions from (e.g. `src/oauth2/service.ts` or `service.ts`). Matched on whole segments, so `gin.ts` never matches `login.ts`.
`repo`	No	Your repo as owner/repo (git remote) or just the repo name. Resolves which Carrick project to query.
`limit`	No	Max functions per page (default 50, max 200). The full org haystack is too large to return inline.
`offset`	No	Number of functions to skip before this page (default 0). Pass the `next_offset` from a previous call to page through.
`compact`	No	Return signature-only rows (name, signature, line span, first sentence of the intent) instead of full detail. Use it with `file` to read what a file offers at a fraction of the source.
`project`	No	Carrick project slug to query. Omit to auto-resolve via `repo`, or omit both when the workspace has one project.
`service`	No	Filter to a specific service (omit for all services)
`typed_only`	No	When true, return only functions whose signature is fully explicit (every param and the return annotated).
`name_contains`	No	Case-insensitive substring filter on the function name.
`exclude_service`	No	Service to exclude from results (use this when looking for sibling-repo implementations of work in your current service)
`intent_contains`	No	Case-insensitive substring filter on the intent text.

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.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond them: the index covers every function with an intent, not just exported ones, and full-org results are too large to return inline. It doesn't mention auth or rate-limit behavior, keeping it just under a 5.

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 primary action and scope, then use cases, then the sibling alternative. Each sentence carries distinct information. It is dense but nothing is redundant; the only minor cost is that several filtering/parameter hints are packed into prose.

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?

For an 11-parameter browsing tool with no output schema, the description covers pagination, coverage semantics, the compact/file interaction, sibling alternatives, and result shapes (one-line intents, signature rows). An agent has everything needed to select and invoke 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?

With schema coverage at 100%, the schema already documents all 11 parameters thoroughly. The description still adds interpretive value by explaining the file+compact combination ('signature-only rows') and framing `file` as a way to answer 'what can I call in this file' without reading source, which goes beyond the schema's mechanical definitions.

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 ('List indexed functions with their one-line intents'), plus pagination and filtering scope. The description immediately distinguishes it from search_by_intent by naming that sibling and describing when concept queries route there instead.

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?

Explicitly names use cases: browsing a service's contents, comparing sibling repos, and answering 'what can I call in this file'. It also names the alternative ('For concept queries ... use search_by_intent instead'), so the routing decision is unambiguous.

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.