Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ask-another Ask GPT-4o about recent AI breakthroughs."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives your AI assistant access to other LLMs. Query hundreds of models across OpenAI, Google, and OpenRouter through a single interface — with model discovery, usage-based favourites, and automatic enrichment (Elo ratings, pricing, knowledge cutoffs). Includes deep-research jobs and image generation across multiple model families.
Install uv — brew install uv (macOS / Linux with Homebrew) or winget install astral-sh.uv (Windows). See docs/install.md for other platforms.
Download the latest ask-another.mcpb from Releases.
Double-click the .mcpb file — Claude Desktop opens an install dialog and prompts for your API keys.
Paste at least one provider key — OpenAI (sk-…), Google AI Studio (Gemini), or OpenRouter (sk-or-…). Leave the others blank.
Click Enable. First launch downloads Python dependencies via uv (~30s); after that, sub-second.
Related MCP server: Index9 MCP Server
Install uv — brew install uv (macOS / Linux with Homebrew) or winget install astral-sh.uv (Windows). See docs/install.md for other platforms.
Add the marketplace and install:
/plugin marketplace add matthewgjohnson/ask-another
/plugin install ask-another@ask-anotherEnter your keys: open /plugin → ask-another → Configure options, paste at least one provider key, and Save. Run /reload-plugins to apply.
Optional: enable auto-update at /plugin → Marketplaces → matthewgjohnson/ask-another so future versions install on CC startup.
For clients without MCPB or plugin support, add the server manually. Example config:
{
"mcpServers": {
"ask-another": {
"command": "uvx",
"args": ["--from", "git+https://github.com/matthewgjohnson/ask-another", "ask-another"],
"env": {
"PROVIDER_OPENAI": "sk-your-openai-key",
"PROVIDER_GEMINI": "your-google-key",
"PROVIDER_OPENROUTER": "sk-or-your-openrouter-key"
}
}
}
}"Ask GPT-5.2 what it thinks about this architecture" → completion
"What Gemini models are available?" → search_models
"Research the state of WebAssembly in 2026" → start_research
"Generate a logo for my project" → generate_image
"Note that DeepSeek is good for creative writing" → annotate_models
See all 10 tools in the Reference.
Installation Guide — Linux/Windows setup, Claude Code, Cursor, Windsurf, and other MCP clients, all configuration options
Reference — tools, annotations & enrichment, architecture, development
git clone https://github.com/matthewgjohnson/ask-another
cd ask-another
make mcpb # builds ask-another.mcpbThen double-click the .mcpb to install in Claude Desktop.
Add or update a personal note on a model. Notes appear in search_models results and in the favourites list in server instructions.
Args: model: Full model identifier (e.g. 'openai/gpt-5.2'). note: Your note about this model. Overwrites any existing note.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| model | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool overwrites any existing note and that notes appear in search results and favourites, but does not mention authentication, rate limits, error behavior, or whether notes are private to the user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short paragraphs. The first sentence front-loads the purpose, and the args list is structured. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple annotation tool with 2 parameters and an output schema, the description is nearly complete. It explains the operation, side effects (overwrite), and where notes appear. It could mention whether the model must exist or if errors occur for invalid models, but overall it's thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully describes both parameters: 'model' with format and example ('e.g. openai/gpt-5.2'), and 'note' with purpose and overwrite behavior. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add or update a personal note on a model.' It uses specific verbs and resource, and distinguishes itself from sibling tools by explaining that notes appear in search_models results and favourites list, which clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when wanting to annotate a model) but lacks explicit 'when not to use' or alternatives. It provides context on where notes appear, but no guidance on conditions like model existence or permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running research task. Use check_research first to find the job_id of the task you want to cancel.
Args: job_id: The job to cancel.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the action is cancellation but does not describe consequences (e.g., irreversibility, state changes) or permissions needed. More transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action. Two sentences plus an Args line with no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and has an output schema. The description covers the core action and how to get the required parameter. It does not explain return values, but the output schema may handle that. Reasonably complete for a cancellation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameter. It says 'job_id: The job to cancel,' which adds meaning beyond the schema's type declaration. However, it could specify where to obtain the job_id (e.g., from check_research).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Cancel a running research task') and resource. It distinguishes from sibling tools like start_research and check_research by its specific cancellation function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs users to use check_research first to obtain the job_id, providing a clear prerequisite and usage flow. This is explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check on research tasks started with start_research.
Called with no arguments, returns a table of all research tasks with their job_id, model, status, query, and timing. Called with a job_id, returns the full results of a completed task including the research report and cited sources.
Use this after start_research was interrupted or timed out, or to poll a long-running task.
Args: job_id: A specific job to retrieve. Omit to list all jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses behavior: returns table of all tasks without args, returns full report with job_id. Implies it is read-only and non-destructive. Could explicitly state it has no side effects, but current description is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a summary, detailed behavior, usage context, and parameter documentation. Every sentence is necessary and adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently covers return values. It mentions the research report and cited sources for the detail mode. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains the job_id parameter: omitting it lists all tasks, providing it returns full results. This adds complete meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks on research tasks started with start_research, differentiating list mode from detail mode. It explicitly contrasts with sibling tools like cancel_research and start_research.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after start_research was interrupted or timed out, or to poll a long-running task. Provides clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a model for a quick completion. Use this for standard prompts that return in seconds — use start_research instead for deep research tasks that need web search and source synthesis.
Use a favourite shorthand (e.g. 'openai') or an exact model ID verified via search_models. Shorthands and favourite model IDs listed in the server instructions can be used directly without calling search_models first.
Args: model: Full model identifier (e.g. 'openai/gpt-5.2') or favourite shorthand (e.g. 'openai' → resolves to your most-used OpenAI model). Use search_models to find other valid identifiers. prompt: The user prompt to send to the model system: Optional system prompt temperature: Sampling temperature (0.0-2.0). Omit to use model default. Some models reject non-default values — omit unless needed.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| prompt | Yes | ||
| system | No | ||
| temperature | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: quick completion, model selection, temperature warning. However, does not mention response format, error handling, or whether it's synchronous. With no annotations, slightly lacking but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage guidelines, then parameter details. Slightly lengthy but every sentence adds value. Could be more concise, but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers model selection, parameter details, sibling differentiation. Missing expected response format or error states, but output schema exists and not needed. Adequate for a completion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: model (full ID or shorthand), prompt, system, temperature (range, default, warning). Adds meaningful context beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Call a model for a quick completion' with a specific verb and resource. It distinguishes from sibling tool start_research by contrasting quick vs deep research tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('standard prompts that return in seconds') and when not to (use start_research instead). Provides guidance on model selection using shorthands or search_models.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Help us improve ask-another by sharing your experience. Call this whenever you're unsure how to proceed, receive confusing output, or a tool doesn't behave as expected. We also welcome suggestions — if a workflow felt more complex than it should be, if you had to guess at parameter values, or if something could simply work better.
Every piece of feedback helps us make ask-another more useful. This tool is lightweight and safe to call at any time.
Args: issue: Share what happened and what you expected. For suggestions, describe what could work better and why. tool_name: Which tool was involved, if applicable
| Name | Required | Description | Default |
|---|---|---|---|
| issue | Yes | ||
| tool_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool is 'lightweight and safe', which reinforces safety but does not contradict annotations. No additional behavioral traits are needed, so 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded purpose, clear examples, and an 'Args' section. Every sentence adds value, and there is no redundancy or unnecessary text. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feedback tool, the description covers purpose, usage scenarios, parameter semantics, and safety. Although the output schema exists and is not described, the description is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains both parameters: 'issue' (what happened, expected, suggestions) and 'tool_name' (which tool involved). Since the input schema has 0% description coverage, the description carries the full burden and does so effectively, adding clear meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to provide feedback for improving ask-another. It uses specific verbs ('share', 'call') and resources ('experience') and distinguishes itself from sibling research/model tools by being a feedback mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('whenever you're unsure...', 'receive confusing output', 'tool doesn't behave as expected') and that it is 'safe to call at any time'. It does not explicitly contrast with alternative tools, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt. The image is saved to disk (~/Pictures/ask-another by default), opened in the system default image viewer, and a preview is also returned in the tool result.
Where to view the generated image:
It pops open in your system image viewer automatically. Disable with OPEN_GENERATED_IMAGES=false if you don't want that.
The full-resolution file is at the path shown in the "Saved to:" message (open it directly for full quality).
In Claude Desktop, the inline preview lives inside the collapsed tool-use details — click to expand the tool call to see it. The chat does not render the preview as a top-level message.
Two model types are supported — the tool picks the right path automatically:
Dedicated image models (gpt-image-1, dall-e-3, imagen-4): best control over size and quality.
Native image-output models (gemini-*-image / "Nano Banana"): can interleave text and images, good for diagrams or annotated visuals.
Args: model: Model to use (e.g. 'openai/gpt-image-1', 'gemini/gemini-2.5-flash-image'). Use search_models with 'image' to find available image models. prompt: Text description of the image to generate. size: Image dimensions. Only used by dedicated image models — ignored by native image-output models. Common values: '1024x1024' (square), '1536x1024' (landscape), '1024x1536' (portrait). Valid options depend on the model. Omit to use the model's default. quality: Image quality. Only used by dedicated image models — ignored by native image-output models. For gpt-image-1: 'low', 'medium', 'high'. For dall-e-3: 'standard', 'hd'. Omit for the model's default.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| model | Yes | ||
| prompt | Yes | ||
| quality | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It covers key behaviors: file saving, auto-open, preview return, and model-specific behavior for size/quality. Minor gaps: no mention of error handling or file overwrite policy, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, where to view, model types, and parameter details. Every sentence adds value. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (multiple models, output behaviors) and no output schema, the description covers generation process, output locations, preview, and parameter constraints. Missing error handling or file naming details, but adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section thoroughly explains each parameter: model (with model search hint), prompt, size (with when used and examples), quality (with specific values per model). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an image from a text prompt and lists specific actions: saves to disk, opens in viewer, returns preview. It distinguishes from sibling tools (e.g., search_models) which are unrelated to image generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives or when not to use it. While it explains model types and viewing options, it does not provide context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force a re-scan of all configured providers and re-fetch enrichment data from LMArena arena-catalog and LMArena metadata. Use this if model data seems stale or after adding a new provider.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions re-scan and re-fetch but does not disclose potential side effects like long runtime, network dependency, or state changes. This is insufficient for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; concise and front-loaded. Could be slightly tighter but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no parameters, the description is somewhat complete but lacks details about the operation's behavior (e.g., sync/async, return type). Output schema exists but description doesn't reference it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds no parameter info but doesn't need to. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forces a re-scan of providers and re-fetches enrichment data from LMArena. It uses specific verbs and resources, and distinguishes from siblings like search_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: if model data seems stale or after adding a provider. Does not mention alternatives or exclusions, but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse available provider groupings (e.g. 'openai', 'openrouter/deepseek'). Use this to explore what's available before drilling into specific models with search_models.
Args: search: Substring filter applied to family names zdr: Filter OpenRouter models to Zero Data Retention (ZDR) compatible only. Defaults to the server's ZERO_DATA_RETENTION setting. Set explicitly to override.
| Name | Required | Description | Default |
|---|---|---|---|
| zdr | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only operation ('browse') and explains filtering, but doesn't explicitly state no side effects or safety profile; no annotations to rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, efficient parameter descriptions in docstring format, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and parameters adequately; output schema exists so return values need not be explained, but lacks mention of output format or potential pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description fully explains both parameters: search as substring filter and zdr as ZDR filter with default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Browse available provider groupings' with examples ('openai', 'openrouter/deepseek'), distinguishing it from sibling search_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool before drilling into specific models with search_models, providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find exact model identifiers. Always call this to verify a model ID before passing it to completion or start_research — do not guess IDs.
Args: search: Substring filter applied to full model identifiers zdr: Filter OpenRouter models to Zero Data Retention (ZDR) compatible only. Defaults to the server's ZERO_DATA_RETENTION setting. Set explicitly to override.
| Name | Required | Description | Default |
|---|---|---|---|
| zdr | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It explains the zdr parameter's default behavior (server setting) but does not disclose other behavioral traits such as whether it returns multiple results, pagination, or error handling. The existence of an output schema may cover return format, but it is not visible here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. The arguments are listed clearly in a structured format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional parameters, substring search) and the presence of an output schema, the description covers essential usage. It could mention whether results are deduplicated or if multiple matches are returned, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning to both parameters: search is a substring filter on model identifiers, zdr filters by ZDR compatibility with a default from server setting. This compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find exact model identifiers.' It distinguishes itself from siblings by explicitly instructing to call this before completion or start_research, and by implying it's different from search_families and annotate_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Always call this to verify a model ID before passing it to completion or start_research — do not guess IDs.' This tells the agent exactly when and why to use this tool, and warns against guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a deep research task. This submits a research query to a model that will search the web, read sources, and synthesize a cited report.
Research tasks can take minutes to complete. This tool will wait for results and return them directly if the task finishes in time. If it is interrupted or the task times out, the research continues in the background — use check_research to retrieve results later.
Args: model: Model to use (e.g. 'openrouter/perplexity/sonar-deep-research'). Use search_models with 'deep-research' to find available models. query: The research question or topic to investigate. timeout: Max seconds to wait for results (default 300). If exceeded, the task continues in the background.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| query | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: tasks take minutes, waits for results, returns if in time, continues in background on timeout. Does not cover rate limits or auth but adequate for a research tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well structured with paragraphs, front-loaded purpose, then behavior, then parameters. Slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async, multiple parameters, sibling tools), the description is comprehensive. It covers usage, behavior, parameters, and fallback mechanism. Output schema exists so return values are not needed in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must explain parameters. It does: model (with example and reference to search_models), query (research question/topic), timeout (default 300, max seconds). Adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool starts a deep research task, submits a query, and distinguishes itself from siblings like check_research by explaining the async behavior and fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to start research) and suggests using search_models to find models. Mentions timeout and background continuation with check_research as alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0annotate_modelscancel_researchcheck_researchcompletionfeedbackgenerate_imagerefresh_modelssearch_familiessearch_modelsstart_researchEach tool has a clearly distinct purpose: annotate_models manages notes, research tools handle lifecycle, completion for quick completions, generate_image for images, search tools for browsing providers/models, and feedback for user input. No overlapping functions.
Most tools follow a verb_noun pattern (e.g., search_models, start_research), with exceptions like 'completion' and 'feedback' being single words. The naming is mostly consistent and readable, using lowercase and underscores for compounds.
10 tools is well within the ideal range for a focused server. Each tool serves a distinct function without redundancy or clutter, covering model interaction, research, image generation, and feedback.
The tool set covers the full lifecycle for research tasks (create, check, cancel), model discovery (search_families, search_models), annotations, image generation, and user feedback. No obvious gaps are present for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Image, video, music and text generation across 100+ models through one endpoint.
AI agent tools: web search, browser, 400+ LLMs, image gen, TTS, phone verify. Pay-per-use.
run any ai model. compose agents, stack knowledge, connect tools. one api, pay per run.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matthewgjohnson/ask-another'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
