Agent Router
Server Details
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 18 of 18 tools scored. Lowest: 1.8/5.
Most tools have clearly distinct purposes (e.g., researchagent vs scientificresearchagent vs softwareengineeringexpert target different domains; reasoning agents are differentiated by effort level). However, constructivecritic and firstprinciplesanalyst both provide analytical feedback and could be confused without careful description reading.
Naming is highly inconsistent: some tools use snake_case (a2a_call_agent, discover_agents) while others use concatenated words (browsernavigationagent, constructivecritic). Additionally, not all tools end with 'agent', and verb/noun patterns vary significantly.
With 18 tools, the server is slightly over the typical well-scoped range (3-15), but the broad purpose of agent routing and delegation justifies the count. A few tools (exploitagent, testagent) feel redundant or underdeveloped, but overall the scope is reasonable.
The tool surface covers core agent discovery (discover_agents), invocation (a2a_call_agent, wait_for_task), and a variety of specialized agents (reasoning, research, coding, etc.). Minor gaps exist: lack of a tool to manage or create new platform agents, and potential dead-ends with testagent and exploitagent.
Available Tools
18 toolsa2a_call_agentAInspect
Call any public A2A-compatible agent directly by its endpoint URL.
Returns the agent's response immediately (synchronous — no task_id needed).
Get agent_url values from discover_agents (look for ENDPOINT in results).
Works with any agent on a2aregistry.org or any A2A JSON-RPC endpoint.
Free — no credits charged, no login required.
Args:
agent_url: The A2A endpoint URL (from discover_agents ENDPOINT field).
message: The message or task to send to the agent.
context_id: Optional — pass the context_id from a prior response to continue a multi-turn conversation.
timeout_seconds: Seconds to wait for a response (default 30, max 120).
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| agent_url | Yes | ||
| context_id | No | ||
| timeout_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It states the tool is synchronous, free, and requires no login, which is helpful. However, it does not cover error handling, rate limits, or idempotency.
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 and well-structured: a clear opening sentence, followed by key behavioral notes, then a bullet-like list of parameters. Every sentence serves a purpose with no 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?
The description covers purpose, parameters, synchronous nature, and refers to sibling tool. Missing error handling or response format details, but given an output schema exists, the description is mostly complete for a straightforward API call tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by providing detailed parameter descriptions: agent_url source from discover_agents, message definition, context_id for multi-turn, and timeout with default and max. Each parameter is clearly explained.
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 it calls any public A2A-compatible agent by URL and returns synchronous response. It distinguishes from sibling tools like discover_agents by referring to them for obtaining agent_url.
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 provides clear context on when to use: it directs users to discover_agents for agent URLs and mentions it works with any A2A endpoint. However, it does not explicitly exclude alternatives or state when not 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.
constructivecriticAInspect
Analyzes complex approaches and strategies by identifying strengths and weaknesses. Provides structured feedback with concrete suggestions for improvement and potential alternatives. Cost: 1 credits. Expected Runtime: ~30s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently states the tool analyzes and provides structured feedback, suggestions, alternatives, and includes cost and runtime. However, it does not detail side effects, output format, or limitations beyond the stated behavior.
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 plus cost/runtime line, no redundancy. Every part adds value: purpose, output, and operational details.
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 there is an output schema (not shown), return values need less explanation. The description covers the tool's purpose and behavior adequately, but the parameter documentation gap reduces completeness.
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% with one required parameter 'approache/strategie' having an empty description. The description mentions 'complex approaches and strategies' but does not explain the parameter's format, constraints, or examples, leaving ambiguity for correct invocation.
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 uses specific verb 'analyzes' and resource 'complex approaches and strategies', clearly distinguishing it from siblings like 'firstprinciplesanalyst' or 'exploitagent' by focusing on strengths, weaknesses, and constructive feedback.
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, nor any prerequisites or exclusions. The description implies use for feedback but does not provide decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_agentsAInspect
Find agents to call — both platform agents and public A2A registry agents.
Returns two types:
• TYPE=platform — built-in agents, call via their MCP tool name (async, returns task_id → use wait_for_task)
• TYPE=a2a_registry — public agents from a2aregistry.org, call via a2a_call_agent(agent_url=ENDPOINT, message='...') (sync, returns immediately)
Registry agents are filtered by the registry's own is_healthy flag.
Each result shows UPTIME and LATENCY from the registry's own reported metrics.
Free — no credits charged.
Args:
query: Keywords to filter by capability (e.g. 'weather', 'web scraping', 'research'). Leave empty to browse top agents.
limit: Max results to return (default 10, max 25).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, disclosing async/sync behavior for each agent type, free usage, registry filtering by is_healthy, and reporting of uptime/latency.
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 fairly concise and well-structured with sections for types and args, but could be slightly tighter. Front-loaded with purpose.
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 discovery tool with 2 optional params and an existing output schema, the description covers purpose, usage, types, calling instructions, and free status. Output schema presumably handles return values.
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 the description adds meaning: query for capability filtering (empty for browse), limit with default 10 and max 25. Adds value beyond 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 finds agents, distinguishes two types (platform vs. A2A registry) with specific calling instructions, and differentiates from siblings like a2a_call_agent which is for calling, not discovery.
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 explains when to use the tool (discover agents) and provides guidance on how to call found agents via appropriate methods. It does not explicitly state when not to use, 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.
exploitagentDInspect
Agent created via direct DB write Cost: 0 credits. Expected Runtime: ~30s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses cost (0 credits) and expected runtime (~30s), but fails to reveal behavioral traits such as whether it is destructive, what it modifies, or any authentication needs. Since no annotations exist, this is insufficient.
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 very short but at the expense of essential information. It fails to convey tool purpose or parameter details, making it under-specification rather than conciseness.
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 name (exploitagent) and the presence of many sibling tools, the description is gravely incomplete. It lacks clarity on the agent creation process, parameter semantics, and does not leverage the existing output schema for completeness.
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 input schema has 0% coverage, and the description does not explain the 'payload' parameter. The payload is a flexible object with no defined properties, and the description provides no guidance on its structure or purpose.
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 'Agent created via direct DB write' is vague and does not clearly state the tool's action. It fails to specify a verb and resource, leaving ambiguity about whether the tool creates, exploits, or modifies something.
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 usage guidance is provided. The description does not indicate when to use this tool versus siblings like a2a_call_agent or browsernavigationagent, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firstprinciplesanalystAInspect
Deconstructs complex tasks or problems using a first-principles approach. Identifies fundamental components, dependencies, and leverage points, and generates atomic-level insights and strategic perspectives. Provides guidance and clarity without delivering ready-made solutions, supporting the Main Agent in understanding and structuring the problem. Cost: 1 credits. Expected Runtime: ~30s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description details that the tool provides atomic-level insights and strategic perspectives without delivering ready-made solutions. It also discloses cost (1 credit) and runtime (~30s). With no annotations, this is decent disclosure, though it lacks specifics on error handling or failure modes.
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 concise with three sentences plus cost/runtime. It front-loads the core purpose, then adds detail, and finally clarifies role. No wasted words; efficient and 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?
Given that an output schema exists, return values are not needed in description. The description covers the tool's main function and behavior comprehensively for a guidance-oriented tool, though it could mention typical output form or integration hints.
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 the description does not elaborate on the single required parameter (task_description). While it mentions 'complex tasks or problems,' it fails to specify input format or expectations, leaving a gap for agent understanding.
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 it deconstructs complex tasks using first-principles approach, identifying fundamental components and generating insights. This distinguishes it from sibling tools like reasoning delegation or other agents that might execute or provide ready-made solutions.
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?
Description implies use for complex tasks needing deconstruction and guidance, but does not explicitly state when to use versus alternatives like reasoning delegations or other analysts. It notes it provides insights without ready-made solutions, offering some context but lacking direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillAInspect
Fetch a ClawHub skill by slug — metadata plus optional SKILL.md body.
Use the slug from search_skills results (e.g. 'agent-browser-clawdbot').
The response includes version, stats, install command, and the SKILL.md content
agents can follow to adopt the skill's behavior.
Free to use — no API key required.
Args:
slug: ClawHub skill slug (lowercase, from search_skills).
include_content: If true (default), include SKILL.md text. Set false for metadata only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| include_content | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 operation is a read (fetch), mentions the response includes version, stats, install command, and SKILL.md content, and states it's free to use. No contradictions.
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, well-structured, and front-loaded with purpose. Each sentence adds value, and the parameter section is clearly formatted. No redundant 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 the tool's simplicity (2 parameters, output schema exists), the description covers purpose, usage context, parameter semantics, authentication, and output content. It is complete for an agent to correctly select and invoke the 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?
Since schema coverage is 0%, the description must explain parameters. It does so clearly: slug is described as 'ClawHub skill slug (lowercase, from search_skills)' and include_content explains its effect and default value, adding 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 action ('Fetch a ClawHub skill by slug') and the resource. It distinguishes from sibling tools by referencing 'search_skills results' and specifying the content returned (metadata and optional SKILL.md body).
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 usage context: 'Use the slug from search_skills results' and notes that it's free without API key. However, it does not specify when not to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reasoningdelegationhighAInspect
The high-effort reasoning agent is built for complex tasks that require deep, multi-step analysis and robust problem-solving. It thoroughly evaluates alternatives, connects multiple sources of information, and carefully reasons through uncertainty before producing an answer. This agent is suited for challenging planning, architecture design, and analytical tasks where accuracy and depth are critical. Cost: 6 credits. Expected Runtime: ~60s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cost (6 credits), runtime (~60s), and behavioral traits (evaluates alternatives, connects sources, reasons through uncertainty). However, it doesn't fully explain the output format or error conditions; output schema exists but the description doesn't reference it.
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 (4 sentences) and well-structured, front-loading the purpose and followed by behavioral details, cost, and runtime. Every sentence adds value with no 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 complexity (one param, output schema exists), the description covers purpose, usage context, cost, runtime, and key behaviors. It misses explicit differentiation from siblings and parameter guidance, but overall it is fairly complete for decision-making.
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 the description does not elaborate on the 'query' parameter. While the tool's purpose implies the query is the task, no guidance is given on how to phrase or structure the input. For a simple single-param tool, this is a notable gap.
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 it is a high-effort reasoning agent for complex tasks requiring deep multi-step analysis. It distinguishes from siblings (low/medium) by specifying 'high' effort and listing use cases like challenging planning and architecture.
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 provides clear context on when to use (complex tasks where depth is critical) but does not explicitly state when not to use or mention alternatives. The context signals show siblings, so the inference is reasonable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reasoningdelegationlowAInspect
A low-effort reasoning agent designed to handle simple to moderate tasks by performing lightweight reflection and structured thinking. It provides quick, cost-efficient reasoning support when full deep analysis is not required. The agent can be called upon to clarify problems, outline steps, and make small to mid-level decisions with minimal computational overhead. Cost: 2 credits. Expected Runtime: ~45s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool's nature (low-effort, lightweight), cost (2 credits), and expected runtime (~45s), which are helpful for selection. It does not mention potential side effects or authorization needs, but for a reasoning agent, this is acceptable. The description adds value beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two meaningful sentences plus cost/runtime information. It front-loads the purpose and key differentiators (low-effort, lightweight) and avoids unnecessary detail. Every sentence contributes to understanding the tool's role and constraints, making it efficient for an AI agent 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?
Given the tool's simplicity (one parameter) and the presence of an output schema (not detailed but extant), the description provides sufficient context: purpose, scope, cost, runtime, and general behavior. It does not explain return values or error cases, but the output schema likely covers that. Overall, it is complete enough for an agent to decide whether to invoke this 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?
The input schema has one parameter ('task') with an empty description (0% coverage). The description does not detail what the 'task' parameter should contain, only that the agent can 'clarify problems, outline steps, and make decisions'. There are no examples, format hints, or constraints provided. The description adds minimal meaning beyond the schema's bare structure.
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 is a low-effort reasoning agent for simple to moderate tasks, providing lightweight reflection and structured thinking. It distinguishes itself by emphasizing low computational overhead and quick results, which implicitly differentiates it from its siblings (reasoningdelegationmedium, reasoningdelegationhigh). However, it does not explicitly compare to siblings or specify the exact boundary of 'simple to moderate'.
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 advises using the tool when 'full deep analysis is not required', implying a comparison to more intensive alternatives. It mentions handling 'simple to moderate tasks', but does not provide explicit when-not-to-use conditions or name alternative tools. The sibling tools exist but are not referenced, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reasoningdelegationmediumAInspect
The medium-effort reasoning agent is designed to handle moderate to complex tasks by applying structured, multi-step thinking and deeper analysis. It balances efficiency and depth, enabling reliable problem decomposition, evaluation of alternatives, and coherent decision-making. This agent is suitable for tasks that require thoughtful reasoning but do not justify maximum computational intensity. Cost: 4 credits. Expected Runtime: ~50s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 structured thinking, problem decomposition, cost (4 credits), and runtime (~50s), but lacks details on error handling, side effects, or specific behavioral traits beyond the high-level description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise paragraph with a clear front-loaded purpose. Every sentence adds value: describing the agent, its suitability, cost, and runtime. No wasted words.
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 (reasoning agent) and the presence of an output schema (meaning return values need not be explained), the description covers key aspects: purpose, cost, runtime. However, it could provide more guidance on expected output or limitations.
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%, and the description does not add semantic meaning to the 'task' parameter. It does not specify expected format, constraints, or examples. The parameter is self-explanatory, but the description fails to compensate for the missing 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 a 'medium-effort reasoning agent' for 'moderate to complex tasks', using structured multi-step thinking. It distinguishes from siblings like reasoningdelegationhigh and reasoningdelegationlow by specifying effort level, cost, and runtime.
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 provides clear context: suitable for tasks needing 'thoughtful reasoning but do not justify maximum computational intensity'. It implies when to use but does not explicitly state when not to or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
researchagentAInspect
Conducts thorough, iterative internet research on a given topic. Identifies key terms, subtopics, facts, studies, and current developments. Compares sources, validates information, and highlights uncertainties. Produces structured, high-quality insights and open questions to support the Main Agent’s understanding. Cost: 3 credits. Expected Runtime: ~60s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively conveys behavioral traits: it is iterative, compares sources, validates information, and highlights uncertainties. It also notes cost and expected runtime, giving the agent a clear picture of resource usage and behavior, though it could mention any side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose and then lists key research steps concisely. It includes cost and runtime in a separate line, which is efficient. Every sentence adds value, though it could be slightly more compact by removing minor redundancies.
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 has one straightforward parameter and no annotations, the description provides sufficient context: it explains the research process, output quality, and runtime. The output schema exists but is not shown, but the description mentions 'structured insights and open questions,' which compensates. It feels complete for the agent's decision-making.
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 input schema has 0% description coverage for the 'topic' parameter, and the description only mentions 'given topic' without adding format, examples, or constraints. While the parameter is simple and self-explanatory, the description adds minimal extra semantic value beyond stating that the research is 'on a given topic.'
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 conducts 'thorough, iterative internet research' and lists specific actions like identifying key terms, comparing sources, and validating information. It distinguishes itself by emphasizing structured outputs and open questions to support the Main Agent, and it includes cost and runtime, making its purpose unambiguous among siblings.
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 usage for in-depth research when the Main Agent needs structured insights, and the cost/runtime provide practical guidance. However, it does not explicitly contrast with similar siblings like scientificresearchagent or specify when not to use this tool, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sandboxcodingagentAInspect
Executes Python or JavaScript code in an isolated, stateless sandbox to validate, test, or solve tasks. Produces concrete, structured outputs from actual code execution, systematically tests logic and clearly identifies what is achievable within sandbox constraints. Supports the Main Agent with verified results and actionable insights. Cost: 2 credits. Expected Runtime: ~45s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: isolated, stateless execution; produces structured outputs; systematically tests logic; identifies constraints. It also includes cost and runtime. However, it omits details on error handling or sandbox limits.
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 informative sentences plus cost/runtime. It is front-loaded with the action, followed by outputs, then constraints. 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 existence of an output schema, the description does not need to explain return values. It covers core functionality, sandbox nature, and expected behavior. However, it could be more detailed about sandbox limitations (e.g., allowed libraries, time limits deeper than runtime).
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% for the single parameter 'task_description'. The description implies the parameter should contain the code or problem, but does not specify format, examples, or constraints. It provides some context but insufficient to fully understand parameter semantics.
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 that the tool executes Python or JavaScript code in an isolated sandbox to validate, test, or solve tasks. It distinguishes itself from sibling agents which are primarily reasoning or research oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like researchagent or exploitagent. The description only states it supports the Main Agent but does not provide when/not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scientificresearchagentAInspect
Analyzes tasks, questions, or problems strictly from a scientific perspective. Retrieves, synthesizes, and evaluates evidence from academic literature across relevant domains. Produces structured, expert-level insights while distinguishing established findings, emerging evidence, and uncertainties. Supports the Main Agent with scientifically rigorous reasoning and recommendations. Cost: 3 credits. Expected Runtime: ~60s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses behavior: retrieves, synthesizes, evaluates evidence, distinguishes findings from uncertainties. Also includes cost and expected runtime, adding valuable context beyond schema.
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?
Four sentences with no wasted words. First sentence states purpose, following sentences detail actions and output, final sentence adds cost/runtime. Well-structured and front-loaded.
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 tool with one parameter and an output schema, description covers purpose, behavior, output format, cost, and runtime. Distinguishes between established findings and uncertainties, which is comprehensive for a research agent.
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 has 0% description coverage, but description compensates by explaining the single parameter 'task_description' is the task to analyze from a scientific perspective. Provides context that the tool will retrieve and synthesize literature.
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 analyzes tasks from a scientific perspective, retrieves academic literature, and produces structured insights. Distinguishes itself from siblings like researchagent by specifying 'scientific perspective' and 'expert-level insights'.
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?
Describes when to use (scientific analysis) but does not explicitly state when not to use or provide alternatives among siblings. 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.
search_skillsAInspect
Semantically search the live ClawHub skills registry (clawhub.ai).
ClawHub hosts OpenClaw SKILL.md packages — behavior templates, tool integrations,
and agent capabilities. Results include slug, author, summary, install hint, and
canonical URL. Follow up with get_skill(slug) to read the full SKILL.md.
Free to use — no API key required.
Args:
query: Natural language description of the capability you need (e.g. 'browser automation', 'send emails via gmail').
top_k: Number of results to return (default: 5, max: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's free, requires no API key, returns specific fields, and defines top_k defaults/max. It implies real-time search against a live registry. However, it does not discuss rate limits, error behavior, or empty results.
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 front-loaded purpose and bullet-point arguments. Every sentence adds value—no redundancy or filler.
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 (not shown but indicated), the description need not detail return values. It covers result fields and suggests follow-up. Two parameters are explained, and no nested objects exist. Could mention edge cases (e.g., no results) but generally complete.
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 explains 'query' as a natural language description and 'top_k' as the number of results with default 5 and max 10. This adds full 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 it semantically searches the live ClawHub skills registry. It specifies what results include (slug, author, summary, install hint, canonical URL) and suggests following up with get_skill. This distinguishes it from siblings like get_skill and discover_agents.
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 explains when to use: to find skills via natural language query. It mentions follow-up with get_skill, but lacks explicit 'when not to use' or comparisons with sibling tools like discover_agents. The context is clear, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
softwareengineeringexpertAInspect
Performs expert-level software engineering analysis to solve tasks using repository and code evidence as the primary source. Investigates architecture, dependencies, design patterns, and code quality to generate structured technical insights, trade-offs, and strategic recommendations. Supports the Main Agent with actionable engineering guidance without speculation. Can't execute code. Cost: 3 credits. Expected Runtime: ~50s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: uses repository/code evidence, cannot execute code, costs 3 credits, expected runtime ~50s, and produces structured insights without speculation. No contradictions with missing annotations.
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 compact at three sentences with no wasted words. The first sentence front-loads the core purpose, and subsequent sentences add key constraints, cost, and runtime efficiently.
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 as an expert analysis agent, the description covers purpose, evidence source, limitation (no code execution), cost, and runtime. The presence of an output schema (not shown) accounts for return value documentation. However, the lack of parameter guidance is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'task_description' has 0% schema description coverage (its schema description is empty). The tool description does not elaborate on how to format or specify the task, leaving the agent with insufficient guidance on what the parameter should contain.
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 identifies the tool as performing 'expert-level software engineering analysis' using 'repository and code evidence as the primary source'. It specifies areas of investigation (architecture, dependencies, design patterns, code quality) and distinguishes from siblings like sandboxcodingagent (executes code) by stating 'Can't execute code'.
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 conveys support for the Main Agent with 'actionable engineering guidance' and emphasizes 'without speculation', implying evidence-based use. However, it lacks explicit when-to-use or when-not-to-use guidelines compared to siblings like researchagent or firstprinciplesanalyst, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
taskplannerAInspect
Generates structured, iterative execution plans from complex user requests or problems. Suggests task breakdowns, phase sequencing, and knowledge flow, but does not independently execute or delegate tasks to other agents. Supports the Main Agent in preparing actionable plans. Cost: 1 credits. Expected Runtime: ~30s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it generates plans without execution or delegation, and provides cost and runtime. It does not cover failure modes, but for a planning tool this is reasonably 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?
The description is three tight sentences plus cost/runtime, all front-loaded with the core action. No superfluous 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 an output schema exists (not shown) and one parameter, the description covers purpose, constraints, and performance. It adds context on plan content (task breakdowns, phases) but could detail output structure more.
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 input schema has 0% description coverage and the tool description does not mention the 'payload' or 'task_description' parameters. Despite being a single required parameter, the lack of any guidance on what to provide reduces usability.
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 structured, iterative execution plans from complex requests, and distinguishes itself by noting it does not execute or delegate tasks, which sets it apart from sibling tools like exploitagent or researchagent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the tool is for complex user requests or problems and supports the Main Agent in preparing plans. While it does not explicitly list when not to use or name alternatives, the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
testagentCInspect
Delegates a task to the specialized agent: TestAgent Cost: 1 credits. Expected Runtime: ~30s.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses cost and runtime, but with no annotations, it fails to explain the agent's behavior, side effects, permissions, or return value. The behavioral burden is unmet.
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 very short (two sentences) and efficiently includes cost and runtime. It is front-loaded but may be under-specified overall.
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 complex agent delegation tool, the description is too scant. It lacks details about the agent's capabilities, input requirements, output (despite an output schema existing), and integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'payload' has 0% schema description coverage and is defined as an empty object with additionalProperties: true. The description adds no meaning, leaving the agent completely unspecific about input structure.
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 it delegates a task to TestAgent, providing a verb and resource. However, it does not differentiate TestAgent from the many sibling agents (like researchagent, exploitagent), leaving the agent's specialization unclear.
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 guidance on when to use this tool versus alternatives. The description only mentions cost and runtime, without context on suitability or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_taskAInspect
Wait for a platform agent task to complete and return its result.
Only needed when a platform agent tool returned STATUS=RUNNING with a task_id
(i.e. the task was still running after the initial 50s inline wait).
NOT needed when the tool already returned STATUS=COMPLETED or STATUS=FAILED.
NOT needed for a2a_call_agent — that always returns directly.
Args:
task_id: The task UUID from a platform agent response with STATUS=RUNNING.
max_wait_seconds: Max seconds to wait (default 45, max 300).
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| max_wait_seconds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes waiting behavior with default and max wait time. Lacks details on polling intervals or timeout handling, 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: first sentence states purpose, then conditions in bullet-like sentences, then Args section. Every sentence adds value with no 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 that output schema exists, description needn't explain return values. Covers all necessary context: when to use, parameter semantics, and default behavior. Complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds crucial meaning: task_id is the UUID from a response with STATUS=RUNNING, max_wait_seconds defaults to 45 and max is 300. This compensates for lack of schema details.
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 it waits for a platform agent task and returns its result. It distinguishes from sibling tools like a2a_call_agent by specifying that this tool is only needed when STATUS=RUNNING.
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 STATUS=RUNNING with a task_id after initial wait) and when not needed (if already completed/failed or for a2a_call_agent). Provides clear conditions using bolded NOT markers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!