Code-Fundi MCP Server

Official

by Code-Fundi

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation4/5
Most tools have clearly distinct purposes, but a few pairs could cause confusion: code-fundi-search vs. code-fundi-research (research wraps search with AI analysis), code-fundi-usage-stats vs. code-fundi-activity-stats, and the deprecated code-fundi-repo-readme overlapping with code-fundi-repo-blueprint. Descriptions are detailed enough to disambiguate, but the overlaps are noticeable.
Naming Consistency2/5
All tools share the 'code-fundi-' prefix, but the remainder follows inconsistent patterns: some use verb_noun (list-repos, index-repo, list-files), others are noun phrases (repo-map, repo-blueprint, file-docs), and some are noun_verb (auth-authenticate, auth-verify). This mix of conventions makes it harder to predict tool names.
Tool Count2/5
At 27 tools, the server exceeds the 25-tool threshold for 'too many'. The count is inflated by a deprecated tool (code-fundi-repo-readme) and a set of six auth-related tools that could be consolidated. While the broad scope partly justifies the number, the presence of redundant/deprecated tools makes it feel overbuilt.
Completeness4/5
The tool surface covers the core Code-Fundi workflows: repository indexing and listing, search/research, file and blueprint retrieval, stats, history, auth, API key management, chat, and model limits. Missing operations include repository removal (de-indexing) and more granular repo configuration, but these are minor gaps for the primary use cases.
Average 4.2/5 across 27 of 27 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the safety profile is known. The description adds little beyond that—it does not disclose possible status values, whether stale data might be returned, authentication requirements, or any other behavioral traits. It only restates the input format already present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the essential purpose and input in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema, so the description should indicate what the response contains (e.g., an indexing state, a boolean, or an error). It merely says 'check status' without specifying what information will be returned or what the possible statuses are. This leaves the agent uncertain about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'url' described as 'Git clone URL to check status for'. The description simply echoes this ('by its clone URL') without adding any extra meaning. Given the high schema coverage, a baseline of 3 is appropriate.
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?
The description uses a specific verb ('Check') and clearly identifies the resource ('indexing status of a repository') and the input ('by its clone URL'). This unambiguously distinguishes it from sibling tools like code-fundi-index-repo, which likely initiates indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you need to know if a repository is indexed, provide the clone URL. However, it does not explicitly state when to use this tool versus alternatives such as code-fundi-index-repo, nor does it give any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the qualifier 'your' (scope to user's own history) and mentions filters, but does not disclose pagination behavior, return format, ordering, or any potential side effects. With annotation coverage, the description adds some context but not rich behavioral detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('List your Code-Fundi query history') and then summarizes the optional filters. Every word is informative and there is no redundancy or filler. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 10 parameters and no output schema, the description is somewhat thin. It does not explain the return shape, pagination behavior, or how to choose between this and sibling tools. However, the schema covers parameters and the readOnlyHint annotation covers safety. The description gives adequate context for the tool's primary purpose but leaves gaps in usage guidance and output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 10 parameters are documented in the schema. The description mentions a subset of filters (date range, category, endpoint, repository) but does not add additional semantics beyond the schema. It does not explain the meaning or formatting of limit, offset, query_type, or conversation_id, though those are covered in the schema. Baseline 3 is appropriate because the schema handles the heavy lifting.
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?
The description uses the specific verb 'List' with a clear resource ('your Code-Fundi query history') and mentions optional filters. This clearly distinguishes it from siblings like code-fundi-history-item (which likely handles a single item) and code-fundi-usage-stats/activity-stats. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as code-fundi-history-item, code-fundi-conversation, or code-fundi-usage-stats. It does not mention exclusions or prerequisites. The only implied context is that it lists query history, but no explicit comparative guidance is given, which is a notable gap given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description aligns by using 'Get' and 'Shows', adding context about the output content (queries per day with credit costs). However, it does not disclose additional behavioral aspects such as timezone handling, aggregation specifics, or any limits, so it adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with two clearly related clauses: what it gets and what it shows. It is front-loaded with the core action and contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-documented optional parameter and no output schema, the description adequately states the purpose and output content. It could be more complete by mentioning sibling tools, but the core context is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'range' parameter, including an enum and default. The tool description only repeats the notion of a 'date range' without adding syntax or format details, so it provides no extra value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Get') and resource ('daily activity statistics'), and specifies that it shows queries per day with credit costs. However, it does not distinguish this from sibling tool code-fundi-usage-stats, which likely covers similar usage metrics, so it misses the sibling differentiation that would merit a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when daily activity stats for a date range are needed, but it provides no explicit guidance on when to use this tool over alternatives like code-fundi-usage-stats. There are no exclusions or alternative tool mentions, so usage guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares a safe read operation, and the description aligns perfectly. The description adds the specific scope of 'all messages in a conversation thread', but does not disclose any additional behavioral aspects such as ordering, pagination, or potential size limits. With annotations covering the safety profile, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and immediately understandable. It front-loads the action and resource, with no redundant words or filler. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description sufficiently describes what the agent will get ('all messages in a conversation thread'). It does not explain the return format or pagination, but such details are not critical for basic invocation given the low complexity. The description is complete enough to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'conversation_id' is documented as 'Conversation thread UUID'. The description only restates this as 'conversation ID', adding no new semantic meaning. The parameter is simple and fully explained by the schema, so the baseline of 3 applies.
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?
The description clearly states the action ('Get all messages') and the resource ('conversation thread'), with a specific lookup key ('conversation ID'). It is distinct from siblings by focusing on retrieving messages from an existing conversation, unlike chat (which sends) or history tools likely listing conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. For example, it does not mention that this should be used after obtaining a conversation ID, nor does it differentiate from 'history-item' or 'list-history'. The description tells what it does but not when it is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description aligns with that. It adds context about what the response includes (subscription tokens, model limits, account limits) and the endpoint. However, it does not disclose additional behavioral traits like authentication requirements, rate limits, or error scenarios, but given the annotations cover safety, a 3 is appropriate.
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?
The description is a single sentence that packs relevant information: the action, the resource, and the categories of data returned. It is front-loaded with the main purpose and includes the endpoint in parentheses for precision. No fluff, though the enumeration at the end is a bit dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values. It does this adequately by listing the major data categories. Given the tool's simple nature and read-only hint, this is reasonably complete. It might miss a formal response format but covers the content scope.
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?
There are no parameters, so schema coverage is trivially 100%. Baseline for 0 params is 4. The description adds no parameter explanations, but none are needed. It does clarify the meaning of the resource (limits), which is useful.
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?
The description clearly states the tool retrieves AI model limits and tier configuration for the account, naming specific categories (subscription tokens, context/knowledge limits, account limits). It uses a specific verb 'Get' with a clear resource, and the endpoint reinforces the action. This distinguishes it from sibling tools like code-fundi-list-models, which likely lists model IDs rather than limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this over alternatives, but it provides clear context that this is for account-level limits and tier configuration. There is no mention of sibling tools or exclusions. Usage is implied based on the content described, but an agent might need to infer whether to use list-models or this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds context about return content ('summaries, functions, dependencies, and code analysis') and the 'AI-generated' nature, which implies processing. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose, the second states the return contents. Front-loaded and concise with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by explaining return contents ('summaries, functions, dependencies, and code analysis'). It also mentions the indexed-repository prerequisite. However, it does not explain the 'fields' preset options (basic/summary/full) or error behavior; the schema partially covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds no new semantic info beyond referring to 'specific file' and 'indexed repository', which map to existing schema descriptions. Baseline 3 is appropriate.
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?
The description clearly states 'Get AI-generated documentation for a specific file in an indexed repository', with a specific verb and resource. It distinguishes from repo-level tools like code-fundi-repo-readme and listing tools like code-fundi-list-files by focusing on file-specific, AI-generated content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via 'in an indexed repository' and 'specific file', but it does not explicitly state when to use this tool over alternatives or provide exclusions. The schema field for file_id references code-fundi-list-files, but the main description lacks this guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds meaningful context by specifying that the result includes 'the complete response and knowledge sources,' which goes beyond the schema and gives the agent a clearer expectation of the returned data. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, the resource, and the key included fields. There is no redundant or filler content; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description is sufficiently complete. It specifies the main return contents, and the schema covers the parameter. While it does not elaborate on potential errors or exact return structure, the low complexity and the readOnlyHint annotation keep this from being a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter history_id is fully described in the schema as 'History entry UUID,' and the description repeats 'by its ID' without adding further semantic detail. Since schema coverage is 100%, the baseline of 3 applies; the description does not add extra guidance such as where to find the ID.
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?
The description clearly states the tool's function: 'Get the full details of a single history entry by its ID' with specific content ('complete response and knowledge sources'). It clearly distinguishes from sibling code-fundi-list-history, which lists entries, by focusing on a single item's detail retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need full details of a specific history entry after obtaining its ID, which is a natural companion to the list-history sibling. However, it does not explicitly state when to use it versus alternatives or mention that you should first list history entries to obtain the ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds the behavioral consequence that files become searchable and mentions updating existing repos, but it does not disclose details like authentication requirements, whether re-indexing overwrites previous data, or any rate limits. It provides some additional context, but not deeply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and includes a follow-up consequence. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple indexing tool with three parameters and no output schema, the description covers the main side effect (searchability) and the create/update duality. It lacks information about how to verify indexing completion or whether indexing is asynchronous, but given the tool's low complexity and rich schema, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description. The tool description adds little beyond restating the 'update' behavior, which is already captured in the 'update' parameter. The description does not provide additional syntax or format details, so baseline 3 is appropriate.
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?
The description clearly states the tool's function: 'Index a new GitHub repository in Code-Fundi, or update an existing one.' It uses a specific verb (index) and resource (GitHub repository), and also mentions updating, which distinguishes it from siblings like search or list-repos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to add a new repo or update an existing one, with the outcome that files become searchable via code-fundi-search. It does not explicitly state when not to use it or name alternative tools, but the context is sufficient to differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation. The description adds that only 'indexed' repositories are returned and mentions supported filters, but does not disclose additional behavioral details like rate limits, auth requirements, or pagination specifics beyond the schema. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences: the first states the core purpose clearly, and the second lists key features. No unnecessary words or repetition of schema details, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers the essential aspects: purpose, account scope, indexing, pagination, filtering, and search. It is complete enough for an agent to know when to use it, though it does not mention ordering parameters, which are already documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have descriptions in the schema, achieving 100% coverage. The description only summarizes the capabilities (pagination, scope filtering, name search) without adding deeper semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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?
The description clearly states the tool lists all indexed repositories in the user's Code-Fundi account, using a specific verb (list) and resource. It distinguishes from sibling tools like list-public-repos by emphasizing 'indexed' and account scoping, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for retrieving repositories from your account, with filtering options. It does not explicitly mention when to use alternatives like list-public-repos or search, but the scope is well-defined as 'all indexed repositories,' which implies typical usage for listing repos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the GET /v2/models endpoint, which reinforces the read-only nature. However, it does not disclose additional behavioral traits like return format, pagination, or any prerequisites. The description provides some context beyond the annotation but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('List'), includes the endpoint, and lists the key output attributes. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity, the description is largely complete: it names the resource, the endpoint, and the returned fields. Without an output schema, this provides a solid mental model. It could mention authentication requirements, but that is a minor gap for a read-only catalog listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The description goes beyond by explaining what the response will contain (providers, required tier, context length), adding meaningful context despite the absence of parameters. This exceeds the baseline of 4 for zero-parameter tools.
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?
The description uses a specific verb ('List') and identifies the resource ('curated Code-Fundi chat model catalog'), while also specifying the output fields (providers, required tier, context length). This clearly distinguishes it from related siblings like code-fundi-model-limits, which focuses on limits rather than the catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to see available models, but it does not explicitly state when to prefer this tool over alternatives such as code-fundi-model-limits. No exclusions or alternative guidance are provided, so it only meets the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint and openWorldHint, but the description adds useful behavioral detail beyond that: it performs a search and then 'streams an AI response.' This discloses the streaming nature and the two-step execution model, which is valuable context not available from annotations alone. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose. Every sentence earns its place: the first gives the action and result, and the second clarifies the workflow and selection criterion. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (16 parameters) and absence of an output schema, the description provides adequate high-level context for choosing the tool but leaves invocation details to the schema. It mentions streaming and analysis but does not describe output structure or how to use the many filter parameters. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, which is moderate but not high. The description itself does not explain any parameter semantics, but the input schema already provides descriptions for 10 out of 16 parameters. The remaining unspecified parameters (e.g., min_lines, file_paths, visibility) are not addressed, so the description adds no extra value here.
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?
The description uses a specific verb+resource+outcome structure: 'Search Code-Fundi repositories AND get an AI-synthesized analysis of the results.' It clearly distinguishes this tool from the sibling code-fundi-search by emphasizing the AI analysis and summary functionality, making the tool's unique value obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this when you need both code context and an intelligent summary/explanation.' It does not, however, mention when not to use it or point to alternatives like code-fundi-search for search-only use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include readOnlyHint: false, so the description carries some burden. It adds the POST method and default type context, but does not disclose potential side effects (e.g., sending an email, rate limits) or error behaviors. The added flow information is useful but not deeply behavioral, so a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that each serve a distinct purpose: what the tool does, when to use it, and a key parameter default. It is front-loaded with the action and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers purpose, usage timing, and parameter default sufficiently. It lacks details on failure modes or response handling, but given the simplicity and schema coverage, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already includes the default for 'type' ('signup') and the purpose of each parameter. The description's mention of default type is redundant with the schema, so it adds no additional meaning beyond what is already structured.
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?
The description clearly states the tool's function with a specific verb ('Resend') and resource ('OTP email'), and includes the endpoint. It also differentiates from siblings by placing it within the auth flow ('after authenticate, before verify'), making its purpose unambiguous.
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?
The description explicitly specifies when to use the tool ('when the previous code expired or was not received') and gives sequencing instructions relative to sibling tools ('Use after code-fundi-auth-authenticate, before code-fundi-auth-verify'). This provides clear guidance on placement in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that responses are streamed and returned as plain text (or JSON), and it highlights features like embeddings memory and voice mode. It does not contradict the readOnlyHint and openWorldHint annotations, and adds useful behavioral context without needing to cover every safety detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core function, followed by key capabilities and output format. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description adequately covers the output (streaming text/JSON) and mentions major features. It lacks explicit details on error handling or rate limits, but given the full schema coverage and available annotations, it is largely complete for a chat tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 8 parameters (100% coverage), so the description does not need to compensate. It does add high-level context for knowledge_id and embed, but this does not go beyond what the schema already conveys, hence a baseline score of 3.
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?
The description clearly states 'Send a message to Code-Fundi AI' with a specific verb and resource. It also lists distinguishing features like threading, code context, and knowledge integration, which sets it apart from sibling tools such as code-fundi-conversation and code-fundi-search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool by enumerating supported capabilities (threading, code context, knowledge, memory, voice). However, it does not explicitly mention when not to use it or name alternative sibling tools, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which already conveys the read-only safety. The description adds scope context ('across all indexed repositories') but does not disclose return format or other behavioral details. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any fluff. Every word contributes value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, read-only annotation), the description provides sufficient context to understand its function. However, it does not specify the exact statistics format or metrics (e.g., lines, bytes, file counts), leaving slight ambiguity in the expected output.
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?
The tool has zero parameters, so the baseline is 4. The description appropriately explains what the tool does without needing to elaborate on parameter specifics, as none exist.
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?
The description states a specific verb ('Get') with a clear resource ('programming language usage statistics') and scope ('across all indexed repositories'). It distinguishes itself from sibling tools like usage-stats and activity-stats by specifying the subject (language) and global scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool returns aggregate language statistics across all indexed repositories, implying it is not for per-repo queries. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the read-only nature. The description adds useful behavioral context: the repository must be indexed, and the tool supports search and pagination, returning file IDs for downstream use. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the main verb and resource. It covers purpose, capabilities, and a follow-up action without any wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list-files tool, the description covers the essential context: it must be an indexed repo, search/pagination are supported, and file IDs can be used with another tool. However, since there is no output schema, it does not fully describe the response format beyond implying the presence of file IDs, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters (100% coverage), including search and pagination-related fields. The description's mention of 'search by file name/path' and 'pagination' is a high-level restatement, adding no new semantic detail beyond what the schema provides.
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?
The description clearly identifies the tool's purpose: listing files in an indexed Code-Fundi repository. It uses a specific verb+resource (list files) and distinguishes itself by mentioning search and pagination capabilities, as well as linking downstream use to code-fundi-file-docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to list files in an indexed repository, with options for search and pagination. It also provides a clear next step (use file IDs with code-fundi-file-docs), but does not explicitly mention when not to use it or compare with alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral detail: it consumes credits and returns structured JSON. There is no contradiction between the description and annotations, and the added credit consumption is important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences. The first sentence states the core function and options; the second covers return format and credit cost. No wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core build operation, optional inputs, return type, and credit consumption. While there is no output schema, the 'Returns structured JSON' statement is minimal but acceptable for a read-only mapping tool with fully described parameters in the input schema. It is not exhaustive about output shape, but it is complete enough for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter having a description. The tool description only echoes the optional compare repos and public index features, adding no new parameter-level semantics or syntax details beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation load.
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?
The description opens with a specific verb phrase 'Build a cross-repository dependency map' and a clear resource (dependency map across repositories). It distinguishes this tool from siblings by emphasizing cross-repo mapping and optional public index inclusion, which no sibling name suggests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool's scope (source repo, optional compared repos, optional public index) and notes credit consumption, giving clear contextual usage. It does not explicitly name alternatives or state when not to use this tool, but the context is sufficiently clear among the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds critical behavioral details: 'consumes credits' and the tier requirement. This goes beyond the structured hints and helps the agent anticipate costs and access restrictions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and purpose. The second sentence concisely covers return values and access constraints. No redundancy or filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers intent, returns, and prerequisites. It does not explain differences between single vs. multiple file/dependency parameters or how credits are metered, but the schema fully documents parameters, making the description sufficient. The high-level return types are mentioned, which helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'files or dependencies' which loosely maps to the file/files/dependency/dependencies parameters, but it does not add details about parameter formats, relationships, or the use of limit/include beyond what the schema already provides. Credit is given for matching the schema coverage.
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?
The description begins with a specific verb+resource: 'Run blast-radius / file impact analysis for one or more files or dependencies.' It clearly states the action, the resource, and the outputs ('projected data flows, entry points, and call edges'), distinguishing it from sibling tools like repo-map or file-docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by defining when this tool is appropriate (impact analysis for files/dependencies) and includes a prerequisite (PRO/ENTERPRISE/ADMIN tier, STARTUP not eligible). However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral context that keys are masked and scoped to the authenticated account, which goes beyond the annotation. No output format is disclosed, but for a simple list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the verb and includes only essential qualifiers.
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?
Given the tool's simplicity (zero parameters, no output schema), the description fully covers the necessary context: what it lists, the masking, and the account scope. It is complete for this tool.
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?
The tool has zero parameters, and schema coverage is trivially 100%. The description adds no parameter details, but none are needed. Baseline for zero-param tools is 4.
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?
The description clearly states the action ('List'), the resource ('Code-Fundi API keys'), and specific scope ('masked', 'for the authenticated account'). This distinguishes it from sibling tools like regenerate/disable and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing API keys but does not explicitly state when to use it instead of alternatives like regenerate or disable. No exclusions or alternative tool references are provided, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds valuable behavioral context: the key is shown only once and is automatically configured for subsequent calls. This warns the user about key recovery and broader impact, going beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action. The second sentence provides essential caveats without waste. Every word earns its place.
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 a simple zero-parameter tool with annotations and no output schema, the description fully covers the purpose, the irreversible nature of the action, and the automatic reconfiguration effect. Nothing critical is missing.
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?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Per guidelines, a baseline of 4 is appropriate since there are no parameter semantics to clarify.
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?
The description clearly states the action: 'Regenerate the Code-Fundi API key.' It uses a specific verb and resource, distinguishing it from sibling tools like list-api-keys and disable-api-key. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a new API key) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The caveat 'full key is shown only once' hints at caution but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral context beyond that: it consumes credits, has a PRO+ tier restriction, and supersedes an older tool. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every clause adds value: content list, successor relationship, PRO+ caveat, and credit consumption. No fluff or redundancy.
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?
Despite having no output schema, the description lists the main return components (README, dependencies, functions/variables, conventions). It also covers important contextual factors like PRO+ restriction and credit usage. Combined with the thorough parameter schema and read-only annotations, the description is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters (repo_key, demo, conventions_path_prefix). The description adds context about what data is returned but does not materially enhance parameter understanding beyond the schema, so a baseline 3 is appropriate.
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?
The description clearly states a specific verb ('Get') and a concrete resource ('canonical repository intelligence overview'), and enumerates the included content (README, dependencies, functions/variables, conventions). It also explicitly distinguishes itself from the sibling tool `code-fundi-repo-readme` by calling itself the successor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by framing this as the successor to `code-fundi-repo-readme`, signaling when to prefer it over that sibling. It also notes the PRO+ restriction for conventions and that credits are consumed, but it does not explicitly state alternative tools or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already signals a safe read operation. The description adds what output to expect (breakdown by query type with counts, credit costs, average durations), giving useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action and followed by a clear summary of the returned breakdown. No wasted words.
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 a simple read-only stats tool with one optional parameter and no output schema, the description adequately explains what the tool returns and its scope. The schema handles the parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single parameter 'range' fully documented (enum values, default). The description mentions 'date range' but adds no new meaning beyond the schema, so baseline 3 applies.
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?
Description uses specific verb 'Get' with resource 'query-type usage statistics', clearly scoped to a date range. It lists the breakdown dimensions (counts, credit costs, average durations), which distinguishes it from sibling tools like activity stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States clear context: for a given date range. Does not explicitly mention when not to use it or name alternatives, but the specificity of 'query-type usage statistics' implies its purpose relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral details: no API key required, supports pagination, an 'updated_since' cursor, and optional embedding of largest files. This goes beyond the annotations without contradicting them, providing useful context about access and response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every word earns its place. It covers scope, features, and authentication without any fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list endpoint with no output schema, the description is largely complete: it states the access requirement, the global scope, and key features. However, it does not hint at the response format or mention the optional `internal_secret` parameter's purpose beyond the schema, which leaves slight ambiguity for an agent.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by summarizing parameter behavior: 'pagination' maps to limit/offset, 'updated_since cursor' maps to `since`, and 'embedding of each repo's largest files' maps to `file_count`. This high-level framing strengthens understanding beyond the schema's individual parameter descriptions.
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?
The description clearly states the tool's purpose: 'Browse the global catalog of indexed public repositories (across all Code-Fundi users)' with a specific verb and resource scope. It distinguishes from siblings like code-fundi-list-repos by noting it covers all users and requires no API key, making it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (browsing public repos without authentication), but does not explicitly mention alternative tools or when not to use it. The phrase 'across all Code-Fundi users' and 'does not require an API key' gives enough guidance for basic selection, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the output structure (similarity scores, paths, optional documentation) and explains the difference between vector-based semantic search and substring grep modes. This adds useful behavioral context without needing to restate the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with front-loaded purpose and a concise explanation of the mode selection mechanism. Every clause adds meaningful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with no output schema, the description adequately summarizes the core function and return format while leaving filter details to the schema. It does not cover edge behavior like pagination or result limits, but given the open-world hint and read-only nature, this is acceptable.
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?
The input schema already describes all 15 parameters with 100% coverage, setting a baseline of 3. The description adds value by explaining the scan_mode enum values semantically (semantic vector search vs substring on docs/code) and clarifying the return payload, going beyond mere parameter listings.
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?
The description clearly states the tool performs searches across indexed Code-Fundi repositories, with three distinct modes (semantic, grep_docs, grep_code) and returns matching files with similarity scores/paths/docs. This distinguishes it from sibling list/file retrieval tools and directly conveys the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on selecting scan_mode for the three search types, which teaches the agent when to use each mode. However, it does not contrast this tool against sibling tools such as code-fundi-list-files or code-fundi-file-docs, so the alternative guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds valuable context that disabling the active key does not rotate it unless that specific key is disabled, which is a nuanced behavior beyond the annotation. It could have mentioned reversibility or permission requirements, but the rotation caveat is a significant addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and endpoint, followed by a useful sibling reference and a behavioral caution. Every word earns its place; no fluff.
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 a single-parameter destructive tool with annotations and schema, the description is fully sufficient. It explains what the tool does, how to find the key, and the rotation behavior. No output schema exists, so no return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter, including its type and description. The description's reference to 'by UUID' is redundant with the schema. No additional parameter semantics are provided, so the baseline of 3 applies.
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?
The description clearly states the tool's action ('Disable a Code-Fundi API key by UUID') and specifies the HTTP endpoint. It distinguishes itself from siblings like code-fundi-list-api-keys and code-fundi-regenerate-api-key by explicitly focusing on disabling.
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?
The description provides explicit guidance to use code-fundi-list-api-keys to find key IDs before disabling, and warns about rotation behavior. This gives clear context for when to use the tool and directs to a sibling for prerequisite steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the crucial deprecation behavior plus the relationship to the replacement tool. This is meaningful beyond the annotation, though it does not detail return format or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and every sentence earns its place—purpose, input, and deprecation warning. No fluff.
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 a simple tool with one parameter, a read-only annotation, and no output schema, the description adequately covers what the tool does, how to invoke it, and its current deprecated status. Complete for the agent to use or avoid correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters, and the tool description merely repeats the repo_key meaning without adding new details, examples, or constraints. Thus it does not add value beyond the schema.
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?
The description clearly states the action ('Get') and the resource ('parsed README documentation for a repository'), and explicitly distinguishes itself from the sibling tool code-fundi-repo-blueprint by noting its deprecated status.
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?
It provides explicit input guidance ('Provide either a repository UUID or a clone URL') and direct alternative guidance: 'Deprecated in favor of code-fundi-repo-blueprint', which tells the agent when not to use this tool and what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description reveals key behavioral details: it sends a 6-digit email OTP (not a magic link), the password is sent via X-CodeFundi-Auth-Password header, and on success the API key is configured in-memory for the MCP session only. It also notes the side effect of sending an email and the need for human interaction with the OTP.
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?
The description is slightly longer than the typical two-sentence ideal, but each sentence carries distinct information: endpoint, prerequisite, OTP flow, password mode, and session-scoped key storage. It is structured logically by mode and is front-loaded with the core purpose.
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?
Given the complexity of an authentication flow, the description is remarkably complete. It covers both authentication modes, the OTP delivery mechanism, the required next step (call verify), the header for password, and the session-limited key configuration. No output schema exists, but the description doesn't need to explain return values because the flow and side effects are clearly described.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining how should_create_user relates to signup vs sign-in, clarifying that password is only used in password mode, and describing the behavior of auth_mode values. This enriches the parameter documentation, though the schema already provides adequate descriptions.
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?
The description clearly states the tool's function: 'Start Code-Fundi authentication (POST /v2/auth/authenticate)'. It specifies the resource and action, differentiates from sibling tools like code-fundi-auth-verify (which is referenced as the next step), and covers both OTP and password modes.
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?
The description provides explicit usage scenarios: 'Use auth_mode otp for new or returning users' with should_create_user true/false, and 'Password mode... should_create_user false for sign-in'. It also names the alternative/next tool (code-fundi-auth-verify) and states that no existing API key is required, giving clear context on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects beyond the readOnlyHint=false annotation: 'On success, activates the API key and configures it in-memory for all subsequent tools in this MCP session.' It also advises on persistence for restarts, adding meaningful behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and endpoint. Every sentence provides essential information: what it does, prerequisite, human involvement, success behavior, and persistence advice. No fluff.
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?
Given the tool's role in an auth flow, the description covers prerequisites, the human-in-the-loop requirement, success effects, and optional persistence. Without an output schema, it sufficiently addresses what the agent needs to know to execute and handle the outcome.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by linking the token to the email verification step and emphasizing that the human user must supply it, which helps the agent understand where the values come from and how to obtain them.
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?
The description clearly states the tool's purpose: 'Complete OTP sign-in (POST /v2/auth/verify)'. It specifies the exact action and endpoint, and distinguishes it from sibling tools by referencing the preceding authenticate step and the follow-up activation of API keys.
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?
Provides explicit usage sequencing: 'Requires the 6-digit code from the user's email after code-fundi-auth-authenticate.' It also instructs the agent to ask the human user for the token and explains the effect of success (activates the API key for the session), giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![code-fundi-mcp MCP server](https://glama.ai/mcp/servers/Code-Fundi/code-fundi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Code-Fundi/code-fundi-mcp)

Score Badge

Copy to your README.md:

[![code-fundi-mcp MCP server](https://glama.ai/mcp/servers/Code-Fundi/code-fundi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Code-Fundi/code-fundi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Code-Fundi/code-fundi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server