Carrot AI PM
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CARROT_PROJECT_ROOT | Yes | The root directory of the project for Carrot to analyze. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| setup_carrotD | – |
| add_routeD | – |
| grow_specD | – |
| grow_ui_specD | – |
| grow_db_specD | – |
| grow_cli_specD | – |
| run_testsD | – |
| format_codeD | – |
| search_codeD | – |
| commit_changesD | – |
| check_spec_complianceD | – |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review_diff | Review a git diff and provide structured feedback |
| draft_pr | Generate a pull request description based on a diff |
| explain_file | Explain a file's purpose and public API surface |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| vibe.yaml | OpenAPI specification for the API |
| README.md | Repository documentation |
| Issue #9559 | carrot_core |
| Issue #9697 | [WIP] carrot_impl |
| Issue #736 | standard location for user binaries like ~/bin/, so installers don't write to oshrc/oilrc |
| Issue #9337 | [seraphis] async: add async framework |
| Issue #469 | argparse builtin: Replacement / enhancement for getopts |
| Issue #453 | use builtin: for "first word lookup" |
| Issue #848 | Run every kind of binary (coprocesses, containers, VMs, remote versions of them ...) |
| Issue #1085 | Introspection for everything |
| Issue #852 | interactive shell: notice about failed commands |
| Issue #750 | mechanism to build shell scripts into the binary |
TDQS
Scored across 11 tools
Most tool names are distinct, but the multiple 'grow_*_spec' tools (grow_spec, grow_cli_spec, grow_db_spec, grow_ui_spec) could overlap in purpose. Without descriptions, agents may struggle to choose the correct one. A few other tools like 'add_route' and 'format_code' seem unrelated, but overall ambiguity is moderate.
All tools follow a consistent verb_noun pattern in snake_case (e.g., add_route, check_spec_compliance, grow_cli_spec). There are no deviations or mixed conventions, making the naming predictable and easy to interpret.
With 11 tools, the count is well within the ideal range of 3-15. Each tool appears to serve a distinct purpose related to spec management, code operations, and testing, justifying its presence.
The tool set covers spec growth, code formatting, testing, and compliance, but lacks read/list operations for specs and code. There are no tools for deleting or updating existing entities, which could lead to agent failures in workflows requiring retrieval or modification.