bite
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
After you fix a bug, call check_fix before you tell the user it's fixed. To ask whether an earlier fix is guarded, call ask_bite.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_fixA | Call this after you change code to fix a bug, before you tell the user it's fixed. Bite takes your change back out of a copy of the project and runs the project's tests. If they still pass, no test shows your fix does anything: add a test that fails without your change and passes with it, then call this again. Free, needs no key, never touches the user's files. Can take as long as the tests do. |
| ask_biteA | Ask in plain words about a fix already committed, like "is last week's login fix guarded?". Bite finds the matching commit(s) by their messages, changed file names and the time named (today, yesterday, last week, the last 10 days...), takes each change back out of a copy and runs the tests. The answer opens in a few words (Yes, No or Partly), then a short block per commit, with its id. Free, needs no key, never touches the user's files. If nothing matches, ask again with words from the commit message. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools are cleanly separated by target: check_fix operates on the code change the agent just made, while ask_bite queries already-committed fixes described in plain language. Each description explicitly states its trigger condition ('after you change code' vs 'about a fix already committed'), leaving no realistic selection ambiguity.
Both names are snake_case verb_object constructions (check_fix, ask_bite), which is consistent. Minor deviation: ask_bite embeds the server name as its object, so the second token is not a domain entity like the first.
Two tools is thin for a general-purpose server, though bite's scope is genuinely narrow (revert-and-test verification). Each tool earns its place, but the surface offers no room for adjacent operations such as listing matchable commits.
The core lifecycle is covered: verify a new fix has a failing-without/passing-with test, and interrogate history for whether an old fix is guarded. The only rough edge is the dead end when ask_bite finds no commit match, requiring the agent to rephrase with commit message words rather than browse candidates.