Provides discovery and fit-checking of GitHub repositories based on the user's coding-agent history, recommending projects that match recurring tasks and interests.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@repofit Recommend GitHub repos that fit my coding history"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Stop scrolling trending. Ask the agent that has watched you work.
Every week another wave of repositories hits ten thousand stars, and every "tools you should try" list is written for everyone at once. Meanwhile your coding agents have been taking notes on you for months: what you build, what keeps breaking, what you complained about at 2 a.m. repofit reads those notes on your own machine, from Claude Code, Codex, Cursor and a dozen more, and turns them into picks you have not heard of and will actually use. Every pick shows you the moment in your own history that earned it.
https://github.com/user-attachments/assets/b733c492-a527-4cb8-8954-8cc8aa59d218
pipx install repofitThen point the agents you use at repofit mcp. Most of them read the same MCP config:
{ "mcpServers": { "repofit": { "command": "repofit", "args": ["mcp"] } } }That line goes in ~/.cursor/mcp.json for Cursor, ~/.gemini/settings.json for Gemini CLI,
~/.qwen/settings.json for Qwen Code, and the MCP settings of Cline, Windsurf or Claude Desktop. Codex reads
TOML, and Claude Code adds servers from the command line:
# ~/.codex/config.toml
[mcp_servers.repofit]
command = "repofit"
args = ["mcp"]claude mcp add repofit -- repofit mcprepofit runs inside your agent, so your agent's own model does the thinking: no API key, no account, nothing
to host. To skip the install step, use uv and make the command uvx repofit mcp.
Related MCP server: suggest-skills
Open a new session in any agent you connected and talk to it like a colleague who has read your history:
"Use repofit to recommend some GitHub projects for me."
"Does github.com/owner/name fit me?"
"Is there a good tool for turning PDFs into Markdown?"
"Which of my installed skills do I never use?"
The agent shows you the picks in the chat, and the same list stays one command away:
The picks come from a sample history. The text is exactly what the CLI prints.
Every pick has a receipt. No "because you starred X": the seen in line points at the session where the need
showed up and quotes what you said. If repofit cannot point at your history, it does not make the pick.
The list at the bottom matters more than it sounds. Every skill and MCP server you installed and forgot still costs context on every single request, and repofit names the ones none of your sessions ever called.
Each agent stores its history differently, and the formats change every few months, so repofit ships one adapter per agent. The profile is written from a redacted, numbered evidence pack, and any claim that cites evidence that does not exist is thrown out by the code, not left to the model's good manners. Retrieval runs one query per task you actually do, with project names and search phrases the model adds, so it finds the library a task depends on even when you never typed its name. The ranker is told to skip the household names you already know. The candidate pool is rebuilt every Monday from the GitHub API: active repositories above 3,000 stars, new ones above 1,000, the agent ecosystem above 300, plus GitHub trending.
Everything runs on your machine. repofit reads the files your agents already keep and writes its own to
~/.repofit.
You choose the depth: installed tools only, plus memory and instruction files (the default), or plus your own messages and tool calls.
Before any model sees a line, API keys, tokens, passwords, emails, phone numbers and random-looking strings
(yes, including the password you once pasted after ssh) are stripped, and your home folder becomes ~.
With MCP, the text goes to the model your agent already uses. From the command line it goes only to the provider you name, after you confirm.
Your notes and other people's READMEs can hide instructions. repofit hands everything over as data, and the agent is told never to follow what it finds inside.
Agent | Sessions | Memory and instructions | Installed tools |
Claude Code | yes |
| skills, plugins, MCP servers |
Codex | yes, CLI and desktop |
| skills, plugins, MCP servers |
Cursor | yes | user rules, pending memories | MCP servers, extensions |
Hermes Agent | yes |
| skills, MCP servers |
Gemini CLI, Qwen Code | yes |
| MCP servers, extensions |
Cline, Roo Code, Kilo Code | yes |
| MCP servers |
Continue | yes |
| MCP servers |
VS Code Copilot | yes |
| MCP servers, extensions |
Kimi CLI, Aider | yes | ||
OpenCode | counted |
| MCP servers |
Windsurf, Claude Desktop, WorkBuddy, Trae | no local sessions | memories where present | MCP servers |
Project instruction files (AGENTS.md, CLAUDE.md, .cursorrules and friends) are read too. Run
repofit scan to see what it finds on your machine. If your agent hides its data somewhere else, open an
issue with the path and it gets an adapter.
Install with pipx install repofit, or put uvx in front of each command.
repofit scan # which agents are installed and what each one stores
repofit profile build --level L2 --provider deepseek
repofit recommend --provider deepseek --lang zhProviders: deepseek, openai, ollama, anthropic, or any OpenAI-compatible endpoint with
--provider compatible --base-url ... --model .... Keys come from DEEPSEEK_API_KEY, OPENAI_API_KEY or
ANTHROPIC_API_KEY, and repofit shows how much text it will send before it sends anything.
No provider at all? Each model step prints a prompt to paste into any chat and imports the answer:
repofit profile prompt --level L2 > prompt.md # then: repofit profile apply answer.json
repofit profile expand --prompt # then: repofit profile expand --apply answer.json
repofit recommend --prompt --lang en # then: repofit recommend --apply answer.json
repofit recommend --no-llm # keyword retrieval only, nothing leaves your machinegit clone https://github.com/pth2002/repofit && cd repofit
python -m pip install -e . pytest
python -m pytest
repofit index build # rebuild the candidate pool yourself; needs a GitHub tokenMIT
Judge whether one GitHub repository fits the user: its facts, whether they already use it, and which profile entries it matches. Looks the repo up on GitHub if it is not indexed.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | owner/name or URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety and network access are covered. The description still contributes beyond them by disclosing the on-demand GitHub lookup when the repo is not indexed (implying latency and external calls) and by outlining the content of the judgment returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by the fallback lookup behavior. No filler and nothing redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming the components of the evaluation (facts, existing usage, profile matches). It is nearly complete for a one-parameter read tool; only the return format and any caching or failure behavior are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully documented in the schema as 'owner/name or URL', and the description adds nothing about accepted formats or normalization. With 100% schema coverage the schema carries the parameter burden, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (judge) and a precisely scoped resource (one GitHub repository), and enumerates what the judgment covers: facts, whether the user already uses it, and matching profile entries. The word 'one' distinguishes it from plural siblings like find_candidates and search_repos, though those siblings are never named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: this is the tool for evaluating a single known repo, which contrasts with the discovery-oriented siblings. There is no explicit 'use this when / use search_repos instead' guidance, so the agent must infer the selection rule from the word 'one'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve candidate GitHub repositories for the profile and return them with ranking instructions. Long results come in parts.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | how many picks (default 10) | |
| part | No | which part to return; start with 1 | |
| pool | No | how many candidates (default 30) | |
| language | No | language for the explanations, e.g. English, Chinese |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=false and destructiveHint=false, so safety is mostly covered (though 'Retrieve' sits oddly against readOnlyHint=false). The description does add non-obvious behavior: results carry ranking instructions the agent is expected to act on, and long output is chunked ('Long results come in parts'). It omits what the ranking instructions look like, whether calls are cached/idempotent, and how parts relate to each other.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose before the output caveat; nothing is wasted. It is arguably too terse for a four-parameter, paginated tool, which costs it the top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a tool whose whole purpose is producing a ranked, paginated result set, the description should explain what 'ranking instructions' are, how parts are exhausted, and how pool and top interact. None of that is present, leaving the agent to discover the return contract by trial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters (top, part, pool, language) are already documented in the schema; baseline is 3. The description adds only marginal meaning, mainly the pagination hint tied to 'part'. It never explains the pool-vs-top relationship or what 'language for the explanations' produces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Retrieve candidate GitHub repositories for the profile', plus what comes back ('with ranking instructions'). It is clear what the tool does, but it never differentiates itself from siblings such as search_repos or check_repo, so the agent must infer which retrieval path applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given, and no alternative is named despite seven siblings including search_repos and get_evidence. The only contextual cue is the vague 'for the profile', which does not tell an agent at what point in the workflow this call belongs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect what the user's local coding agents know (installed tools, memory files and, at level L2, the user's own session messages), redacted and numbered, with instructions for writing a profile. Long results come in parts.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | only sessions from the last N days | |
| part | No | which part to return; start with 1 | |
| level | No | L0 installed tools; L1 adds memory and instruction files (default); L2 adds session messages and tool calls |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses two genuinely useful behaviors: results are redacted (a privacy guarantee) and numbered in parts (pagination). It leaves one gap: readOnlyHint=false suggests some state may be written (likely part caching), but the description never explains that, and it does not state how an agent knows when the parts are exhausted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb first and no filler; the parenthetical scope list is dense but earns its place. Slightly overloaded by combining scope, redaction, pagination, and the profile-writing hint in one breath.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry return-value burden: it says results are redacted, numbered, and split into parts, but does not describe the shape of what comes back or how completion across parts is signalled. The unexplained readOnlyHint=false also leaves the agent without a full behavioral picture for a three-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines days, part, and level. The description reinforces only the level semantics ('at level L2, the user's own session messages') and hints at part usage via 'long results come in parts'; it adds little beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Collect' plus a concrete resource ('what the user's local coding agents know') and an enumeration of what that includes (installed tools, memory files, session messages at L2) makes the purpose unambiguous. It implicitly positions itself as the evidence-gathering step feeding save_profile, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'with instructions for writing a profile' hints this is the read step before profile creation, but there is no explicit when-to-use, when-not-to-use, or named alternative among save_profile/show_profile/find_candidates. An agent must infer the pipeline position from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the search terms and project names written for each profile entry.
| Name | Required | Description | Default |
|---|---|---|---|
| expansion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a write (readOnlyHint=false) with closed-world scope, so the description adds little on the safety side. It does not disclose whether saving overwrites existing expansion data, whether it is idempotent, whether it fails when no profile entry exists, or what is returned — all material for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. Its brevity reflects genuine under-specification rather than tight editing, but nothing in the text is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool taking an opaque nested object with no output schema, the description should cover prerequisites, overwrite semantics, and expected payload structure. None of that is present, leaving an agent able to guess the intent but not to construct a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter "expansion" is an untyped nested object with zero schema description coverage, so the schema provides essentially no help. The description partially compensates by naming the contents (search terms and project names, per profile entry), which is the only structural hint available, but key names, shapes, and required sub-fields remain unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb is clear ("Save") and the description names the payload contents ("search terms and project names written for each profile entry"), but the core noun "expansion" is never defined, so an agent cannot confidently distinguish this from the sibling save_profile. It conveys a general intent without pinning down the resource precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus save_profile, save_recommendations, or show_profile, and no prerequisites such as whether a profile entry must already exist. The agent must infer the workflow position entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the profile JSON written from get_evidence. Refs that do not exist are dropped. Returns the profile and the instructions for the search expansion.
| Name | Required | Description | Default |
|---|---|---|---|
| synthesis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=false, so the mutation/closed-world profile is known. The description does add real value: it warns that non-existent refs are silently dropped (a data-modifying behavior an agent must anticipate) and states what is returned despite there being no output schema. It omits overwrite semantics, persistence scope, and failure behavior, which are the main remaining risks for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action, then the caveat about dropped refs, then the return value. Every sentence carries distinct information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested opaque object parameter, no output schema, and a mutation, the description covers the source of the payload and the return value reasonably. It still leaves the agent guessing at the accepted JSON shape and at whether a prior profile is replaced, which matters for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter, "synthesis", typed only as a bare object with 0% schema description coverage and no declared properties, nested-object structure being the only hint. The description's pointer to get_evidence as the source of the JSON is the sole semantic aid, and it gives no field names, required keys, or shape for the profile object it expects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Save the profile JSON") and ties the payload's origin to the sibling tool get_evidence, which distinguishes it from save_expansion and save_recommendations. It stops short of saying what a "profile" actually contains, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"written from get_evidence" implies the correct workflow order (call get_evidence first, then save), which is useful implied guidance. However, it never states when not to use it, whether it replaces or appends to an existing profile, or how it relates to show_profile and save_expansion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the ranking JSON written from find_candidates. Picks that name unknown candidates or profile entries are dropped. Returns the recommendations to show the user.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| answer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) and closed-world (openWorldHint=false). The description adds meaningful behavior beyond that: invalid picks naming unknown candidates or profile entries are dropped, and the tool returns recommendations to show the user. It does not state overwrite or concurrency behavior, keeping it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no wasted wording. The core action, validation behavior, and return value are each stated once and in a useful order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested required object, no output schema, and zero schema description coverage, the description covers the main flow but misses important details. It does not explain the 'top' parameter, the ranking JSON shape, or whether saving replaces prior recommendations. These gaps matter for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains that 'answer' is the ranking JSON from find_candidates, but it leaves 'top' completely unexplained, including its 1–20 limit and effect on saved recommendations. The nested object structure of 'answer' is also not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Save the ranking JSON') and ties it directly to the sibling tool find_candidates. This lets an agent distinguish it from siblings like save_expansion or show_recommendations, though it does not fully spell out the persistence target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the tool is used after find_candidates, since it saves 'the ranking JSON written from find_candidates.' The context is strong, but there are no explicit when-not-to-use conditions or named alternatives for other save paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the indexed GitHub repositories, leaving out what the user already uses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| include_used | No | also list repos the user already uses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, closed-world search. The description adds useful scoping behavior by saying it searches indexed repos and excludes already-used ones by default, but it does not disclose result ordering, freshness, pagination, or what the returned list contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted wording. It quickly establishes search target, scope, and default exclusion behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool this minimally covers the core scope and default filtering behavior. However, with no output schema and no explanation of returned results, ranking, limit defaults, or sibling-tool selection, an agent must infer several operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, so the description needs to carry more semantic weight. It clarifies that query is a keyword search and indirectly explains the default for include_used by saying used repos are left out, but it says nothing about limit or result-count behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: keyword search over indexed GitHub repositories. It also adds a scoping behavior, excluding repos the user already uses, which helps distinguish it from a plain candidate listing. It does not explicitly name sibling tools such as find_candidates or check_repo, so sibling differentiation is only partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the default exclusion of repos the user already uses, suggesting this tool is for discovering new repositories. However, it gives no explicit when-to-use guidance relative to find_candidates, check_repo, or unused_tools, and does not explain when the alternative behavior is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the saved profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the profile is 'saved,' implying persisted state, but it does not explain behavior when no profile exists or what the shown output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant or filler wording. For a zero-parameter read-only tool, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema, read-only annotations, and simple retrieval purpose, the description provides enough context for an agent to invoke the tool correctly. It could be slightly more complete by noting what the profile contains or what happens if none is saved, but the core call is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so there are no parameter semantics to clarify. The baseline for a no-parameter tool is 4, and the description does not create any misleading parameter expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and resource ('saved profile'), so the agent can tell it retrieves a persisted profile rather than saving one. It does not explicitly differentiate itself from siblings such as save_profile, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies the tool is used when the user wants to view the saved profile, but there is no explicit when-to-use guidance, no exclusions, and no named alternative. Usage must be inferred from the verb and the existence of save_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the last saved recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds one useful behavioral fact beyond that: only the most recent saved snapshot is returned, not history or all versions. It says nothing about what happens when nothing has been saved, or what the output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word earns its place. It is arguably too sparse for the amount of ambiguity left, but that is a completeness issue rather than verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no nesting), so little is required, but there is no output schema and the description never explains what a 'recommendation' record looks like or how an empty state is signalled. For a read tool whose whole value is its return payload, that is a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. 'Last saved' also conveys the implicit selection behavior (no filtering, no date range, no identifier), which is meaningful given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Show the last saved recommendations" gives a clear verb (show) and resource (recommendations) with a scope qualifier (last saved). An agent can distinguish it from save_recommendations by the verb, but the description never explicitly names that sibling or clarifies what 'recommendations' are in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'last saved' weakly implies a prior save_recommendations call must have happened, but there is no explicit when-to-use, when-not-to-use, or alternative named. With siblings like get_evidence and show_profile in the set, the agent gets no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed MCP servers and skills that no session ever called.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered by structured data. The description adds the semantic of "no session ever called" but does not say what counts as a session, over what time window, or where usage data comes from, which matters for interpreting "unused".
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the key qualifier ("no session ever called") is placed at the end where it sharpens rather than buries the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with no output schema, the definition covers the essentials. The only remaining gap is the imprecise definition of "unused" (all-time vs. a window), which an agent would otherwise have to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to clarify. The baseline of 4 applies; there are no argument semantics to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("List") on a specific resource ("installed MCP servers and skills") with an explicit scope ("that no session ever called"). It is immediately clear what the tool returns; there is no near-identical sibling among the save_/show_/search_ tools to disambiguate against, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use is only implied: the description tells you what the output means, so an agent can infer an auditing/cleanup scenario. It offers no explicit when-to-use, when-not-to-use, or alternative (e.g., a companion tool listing all installed tools including used ones).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1check_repofind_candidatesget_evidencesave_expansionsave_profilesave_recommendationssearch_reposshow_profileshow_recommendationsunused_toolsScored across 10 tools
The tools mostly represent distinct pipeline stages: evidence collection, profile saving/showing, candidate finding, recommendation saving/showing, repo checking, and repo searching. The closest overlap is between find_candidates, search_repos, and check_repo, but their descriptions distinguish profile-based retrieval, keyword search, and single-repo judgment.
Most names follow a clear verb_noun snake_case pattern such as save_profile, find_candidates, and show_recommendations. The only notable deviation is unused_tools, which is a noun phrase rather than an action verb.
Ten tools is well within a reasonable scope for a multi-step profile-to-recommendation workflow. Each tool appears to serve a specific step in that flow, with search and check helpers adding useful coverage.
The surface covers the core lifecycle: collecting evidence, saving/showing a profile, expanding searches, finding candidates, saving/showing recommendations, and checking or searching repositories. Minor gaps exist around deleting or resetting saved profiles/recommendations and explicitly viewing saved expansions.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Hosted MCP server and Agent Skills for specs, engineering threads, and project memory.
An MCP server that gives your AI access to the source code and docs of all public github repos
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
