performance suggestions from Claude when using

[philpennock]

Should definitely prioritize getting --format=text reliably available across all MCP tools.

All the rest are valid complaints too.

❯ Before we do so, spot check: feedback on aifr and anything you'd like done differently by it?  Some of the responses are very verbose, should there be options to emit responses non-json, or better guidance on doing so if format text is available already?

● A few concrete things:

  aifr_search JSON envelope is the main pain point. Every match includes file, line, column, match, context_before, context_after, plus top-level metadata (is_regexp, source,
  files_searched, truncated, complete). Column is almost never useful for Go code searches. A format="text" option outputting path:line: content (ripgrep style) would cut tokens
  significantly on the common case of "find this pattern, show context."

  aifr_read same issue. The response wraps content in a JSON object with path, ref, total_lines, lines_returned, complete, source before the actual content. For a focused line-range
   read where I just want the code, that envelope is overhead. format="text" would be useful here too.

  "file": "." in single-file searches is confusing. When searching within a specific file, each match shows "file": "." instead of the actual filename. It's clear in context but
  looks like a bug.

  The format="text" + divider="xml" guidance for aifr_cat is good and well-documented in the skill. That pattern worked well. The gap is that equivalent format options aren't
  available (or aren't documented) for aifr_read and aifr_search, which are the higher-frequency tools.

  Minor: the skill routing table is comprehensive but I had one case early on where aifr_read on a large range caused a token overflow before I'd thought to use lines. An explicit
  note in the aifr_read description about defaulting to lines for anything over ~200 lines would help.

❯ Thank you. The CLI mode uses `--format=text` as a global flag, and that works with `aifr read` and `aifr search`, so check to see if it's in the schema for the MCP tool calls?

● The schemas I already have for aifr_read and aifr_search (fetched earlier in the session) don't include a format parameter — aifr_read has path, lines, chunk_id; aifr_search has
  pattern, path, context, continuation, exclude, ignore_case, include, max_matches, regexp. No format field in either.

  So it's a gap between CLI and MCP: --format=text exists in the CLI but isn't exposed in the MCP tool schemas. Adding format as an optional "text" | "json" parameter to at least
  aifr_read and aifr_search would close that.