AI Model Advisor MCP Server

Server Quality Checklist

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

Latest release: v2.3.0
Disambiguation4/5
Most tools have clearly distinct purposes: listing, getting details, comparing, recommending, estimating cost, etc. However, recommend_model and select_model_for_project overlap in that both provide recommendations; select_model_for_project is explicitly a higher-level aggregation tool, but agents could be uncertain which to use.
Naming Consistency4/5
The majority of tools follow a consistent verb_noun snake_case pattern (e.g., list_models, get_model_info, estimate_cost). The exception is whats_new, which deviates from the verb_noun structure but remains clear and fits the domain.
Tool Count5/5
With 9 tools, the set is well-scoped for an AI model advisor. Each tool addresses a distinct need, and the count is within the ideal range for a focused server.
Completeness5/5
The tool surface covers the full lifecycle of model advisory: discovery (list_models, whats_new), detailed info (get_model_info), recommendation (recommend_model, select_model_for_project), comparison (compare_models), pricing (batch_get_pricing, find_cheapest_provider), and cost estimation (estimate_cost). No significant gaps are apparent.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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?
With no annotations, the description must disclose behavioral traits, but it only says 'List and filter available AI models' without mentioning pagination, ordering, default limits, or return format. The schema covers the limit parameter, but the description adds no context about how results are presented or whether any side effects exist.
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 front-loads the core purpose and packs in filter examples compactly. It avoids fluff, but the parenthetical enumeration is slightly dense and partially duplicates schema content, keeping it from a perfect score.
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?
Given no output schema and no annotations, the description should explain return values or behavior, but it does not. It omits any mention of what model information is returned (e.g., model IDs, pricing), which is essential for an agent choosing whether to use this tool over sibling tools.
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 baseline is 3. The description repeats filter names (category, provider, capability, max price) but adds no new meaning beyond the schema's detailed parameter descriptions. It does reinforce that filters exist, but without extra semantic value.
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 'List and filter available AI models from all 5 providers', using a specific verb and resource. It distinguishes itself from siblings like get_model_info (single model) and compare_models (comparison) by emphasizing broad listing and filtering across providers.
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?
Usage is implied through 'List and filter' and the explicit filter categories, but there is no mention of when to prefer this tool over siblings like recommend_model or select_model_for_project. No exclusions or alternative tools are referenced, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool lists new models and supports filters, but it does not disclose what fields are returned, the default time window (though the schema mentions it), any sorting order, or whether it's a read-only operation. This is a notable gap for a tool with zero annotation support.
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: the first states the primary purpose ('Discover recently added AI models') and the second gives a use case and filter options. Every sentence earns its place, and the description is front-loaded with the core function, making it concise and efficient.
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?
The tool is simple (3 optional params, no output schema), but the description does not fully cover important context such as the shape of results or how it differs from the sibling list_models. It mentions 'recently added' which hints at a distinction from listing all models, but it doesn't explicitly state this, leaving some ambiguity for an agent comparing tools.
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 (limit, since, category). The description only restates the idea of filtering by time window and category, adding no extra semantic detail or value beyond the schema. Thus, the 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 ('Discover') and resource ('recently added AI models'), making the tool's core function immediately clear. It also includes a concrete example question ('what new models dropped this week?') and mentions filtering, which sets it apart from siblings like list_models or get_model_info.
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 by framing it as answering 'what new models dropped this week?' and supporting time-window and category filters. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full exclusion guidance.
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?
No annotations are provided, so the description must convey behavioral traits on its own. It does disclose the return content in detail (pricing breakdown, capabilities, speed metrics, etc.), but it does not explicitly state that the operation is read-only or non-destructive, nor does it mention error handling, authentication requirements, or whether the data is real-time or cached. This leaves some room for ambiguity.
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 action, and every sentence adds value. The first sentence tells exactly what the tool does, and the second efficiently lists the key contents of the model card. No fluff 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?
Given that there is no output schema and no annotations, the description carries the burden of explaining what the tool returns. It does this well by listing many expected fields (description, pricing, capabilities, quality tier, context length, speed metrics, benchmarks, tags, license). However, it is not fully complete because it ends with 'and more' without specifying what else, and it omits error behavior and input constraints beyond the schema. Still, it is adequately complete for a read-only single-parameter 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 schema already provides 100% coverage for the single parameter (model_id) with an example format, so the description does not need to add much. The description adds no additional meaning about the parameter itself beyond saying 'any AI model,' which is already implied by the schema. 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 uses a specific verb ('Get') and a clear resource ('a comprehensive model card') and states the scope ('for any AI model'). It also enumerates the content (pricing, capabilities, benchmarks, etc.), which distinguishes it from sibling tools like list_models (which lists models) and compare_models (which compares).
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 clearly implies the tool is used when you need detailed information about a single model, but it does not explicitly state when to use it versus alternatives or mention any exclusions (e.g., 'Use compare_models for side-by-side comparisons'). No direct guidance is given, so usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, error conditions, return format, or any side effects. It only covers input semantics, leaving a significant transparency gap.
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 concise sentences with a valuable example. It front-loads the main purpose, uses no unnecessary words, and is well-structured for quick comprehension.
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?
The tool has a nested usage object, no output schema, and moderate complexity. The description covers input requirements and provides an example, but it does not explain the return value, such as cost format or any potential errors, leaving a notable completeness gap.
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 schema already provides descriptions for both parameters with 100% coverage, so the baseline is 3. The description adds a concrete example and clarifies LLM vs media usage, going beyond what the schema states and enhancing parameter understanding.
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 estimates the cost of using an AI model, with a specific verb and resource. The example distinguishes it from sibling tools like compare_models or list_models by showing a single-model usage estimation.
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 input structure for LLMs vs media models, which helps the agent know how to format the usage parameter. It does not name alternatives, but the context implies single-model estimation, and the example reinforces this.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It mentions returning a compact table, which gives some idea of the return format, but does not disclose potential error behavior, rate limits, or whether data is live or cached. For a simple read-only batch tool, this is acceptable but not thorough.
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 action, and every sentence adds useful information. No filler or repetition.
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 simple input (one array parameter) and no output schema, the description covers the core use case and return behavior sufficiently. It could be more explicit about handling unknown model IDs or the exact response structure, but it is largely complete for this straightforward batch retrieval 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 schema has 100% coverage for the single parameter model_ids, including a description and example. The tool description adds no semantic detail beyond 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 tool gets pricing for multiple models in one call, which is a specific verb+resource. It also distinguishes itself from get_model_info by highlighting the batch aspect and speed advantage.
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 compares to get_model_info and states when this tool is preferable ('Much faster than calling get_model_info one at a time'). It does not list exclusions or alternative tools like estimate_cost, but the primary use case is clear.
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?
No annotations are provided, so the description carries the full burden. It discloses useful behavioral traits: searches all 5 providers, compares pricing, and uses fuzzy matching. However, it does not mention potential pitfalls like what happens if no provider matches, whether the operation is read-only, or the format of the result. Given no annotation support, this is a significant but not fatal gap.
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 primary purpose, followed by scope and a behavioral note. Every sentence adds value with no redundant or promotional language.
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 (one parameter, no output schema), the description covers the essential action and scope. However, since there is no output schema, the description does not explicitly describe the return value (e.g., whether it returns a provider name, price, or object). This minor gap prevents a perfect score, but 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 schema already fully describes the single 'model' parameter with examples, achieving 100% schema_description_coverage. The tool description repeats the same examples and adds the context of fuzzy matching, but does not add extra semantic detail about the parameter format beyond what the schema provides. The 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 clearly states a specific action: 'Find the cheapest provider for a given model.' It specifies the resource (provider), scope (across all 5 providers, compares pricing), and gives concrete model examples. This distinguishes it from siblings like 'compare_models' or 'estimate_cost' by focusing on a single model's cheapest provider.
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 context is clear: use this when you have a specific model in mind and need the cheapest provider. Although it doesn't explicitly name alternatives or exclusions, the description's scope ('given a model', 'across all 5 providers') implies appropriate usage compared to siblings like 'compare_models' (comparing models) or 'estimate_cost' (estimating usage costs).
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?
With no annotations provided, the description carries the full burden. It discloses that the output is a table, columns auto-adapt based on model types, and metrics (TTFT, tokens/sec, MMLU) are included 'when available,' giving a realistic expectation of data completeness. It does not mention error handling or rate limits, but for a read-only comparison tool this is acceptable.
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, each earning its place: it states the core function, the scope (across providers/categories), and the automatic column adaptation plus included metrics. The description is front-loaded with the main purpose and avoids 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?
For a tool with one parameter and no output schema, the description is largely complete: it explains what the tool does, the output format, the adaptability behavior, and what metrics are shown. Minor gaps remain around error handling and exact return structure, but the description covers the essential context.
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 for the single parameter is 100%, with an example list of model IDs. The description does not add parameter-specific details beyond what the schema provides, so the baseline of 3 is appropriate. It does clarify the intent of the parameter indirectly by describing the comparison functionality.
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 ('Compare') and resource ('AI models') with a clear output format ('in a table'). It distinguishes itself from sibling tools like list_models and get_model_info by emphasizing side-by-side comparison across providers and categories.
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 clearly implies when to use this tool (when needing to compare models side-by-side, including across categories) and mentions auto-adapting columns and available metrics. It does not explicitly name alternatives or exclusions, but the context is evident from sibling tool names.
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?
No annotations are provided, so the description carries the full burden. It discloses the search scope (1000+ models, 5 providers) and the ranking criteria (task match, capabilities, quality tier, price, speed, benchmarks). This goes beyond mere intent but does not explicitly state whether the operation is read-only or if any side effects exist. The implied read-only nature is clear enough for a recommendation tool.
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-loads the core purpose, and packs relevant details (providers, categories, ranking criteria) without repetition or fluff. Every sentence contributes useful 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?
The tool has 4 parameters, no annotations, and no output schema. The description explains the return value (ranked results) and the basis for ranking, covering the main need. It does not mention pagination, error handling, or exact output structure, but for a recommendation tool with a broad search, the description is sufficiently 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%, so the baseline is 3. The description adds general context about the search scope and ranking, which indirectly relates to the task and budget parameters, but it does not provide specific semantic value beyond what the schema already describes for each parameter. It fails to compensate or extend the parameter-level guidance.
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: recommend the best AI model for a task. It uses specific verbs ('Recommend', 'Searches'), defines the resource (AI models across 1000+ models from 5 providers), and distinguishes itself from siblings like compare_models or list_models by emphasizing task-based ranked 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 implies usage context: use when you need a task-based recommendation without preselecting models. It gives clear context (searches a broad catalog, ranks results) but does not explicitly mention when not to use it or reference alternatives like compare_models or select_model_for_project. There are no exclusions or alternative guidance, so it stops 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?
No annotations are provided, so the description carries the full burden. It discloses the output format ('concise markdown plus structured fields') and the decision dimensions (candidates, scores, reasons, pricing, tradeoffs). This adds useful behavioral context beyond the schema, though it doesn't discuss any potential side effects or limitations.
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 with no wasted words. The first sentence states the purpose, the second gives usage context and output summary. It is well front-loaded and earns every word.
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 tool with 7 optional parameters, nested objects, and an output schema, the description covers the core decision role, usage context, and return format. Combined with the output schema, the agent has sufficient context to invoke this tool correctly without major 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 100%, so the baseline is 3. The tool description does not add additional parameter-level meaning beyond the schema, which is acceptable given the schema fully documents all seven parameters with examples and enums.
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: 'Pick the best overall, cheapest acceptable, and best value AI model for a project.' It clearly distinguishes itself from sibling tools by framing it as the consolidated decision tool versus manually chaining recommend, compare, pricing, and cost tools.
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?
Explicitly states when to use: 'Use this when an agent has project context and needs one decision' and contrasts it with manually chaining other tools. While it doesn't name alternative sibling tools by name, the 'instead of manually chaining' provides clear usage context and implies the excluded approach.
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:

[![ai-model-advisor-mcp MCP server](https://glama.ai/mcp/servers/Semicolon-D/ai-model-advisor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Semicolon-D/ai-model-advisor-mcp)

Score Badge

Copy to your README.md:

[![ai-model-advisor-mcp MCP server](https://glama.ai/mcp/servers/Semicolon-D/ai-model-advisor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Semicolon-D/ai-model-advisor-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/Semicolon-D/ai-model-advisor-mcp'

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