Skip to main content
Glama

ToolRouter

by io.github.Humanleap

Use Tool

use_tool

Call a ToolRouter catalogue tool. Use discover first to find tools — then pass the tool name and skill here. IMPORTANT: "discover", "credits_balance", and other built-in tools are NOT catalogue tools — call them directly, never through use_tool. Long-running tools return a job_id — poll with job_get. If a skill needs an image_url or file URL and you have a local file or base64 image, use file_write first to get a hosted URL, then pass that URL to the skill. BRAIN: Some tools require you to consult brain_query first. If use_tool returns an error about brain_context, call brain_query with a relevant query, then pass the result text as brain_context in your use_tool input.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYesTool reference from discover results, e.g. "web-search"
inputYesSkill input parameters (see discover for schema). For persona-using tools, include persona_file_id from discover or persona_list. For scene-using tools, include scene_file_id from discover or scene_list. For product-using tools, include product_file_id from discover or product_list. For outfit-using tools, include outfit_file_id from discover or outfit_list. For style-reference tools, include style_reference_id (from discover or file_list), style_reference_query (semantic search), or style_reference_prompt (inline prose). For image-composition tools (e.g. generate-image image_to_image), pass any combination of scene_file_id, persona_file_id, product_file_ids[] (from file_list section "products"), outfit_file_ids[] (section "outfits"), and raw image_urls[] — the gateway resolves and merges them into a single image_urls array (max 4 by default).
skillYesSkill name from discover results, e.g. "search"
backendNoRoute the same model through interchangeable providers. order prioritises providers; only restricts; ignore excludes; allow_fallbacks defaults true.
billingNoWhich account to bill. "personal", "team" (auto-resolves if on one team), a team slug ("humanleap"), or a team ID ("team:m57df8c..."). Omit to use your default.
brain_contextNoBrain knowledge from brain_query. Pass at the top level of use_tool (alongside "tool", "skill", "input") — NOT inside input. Call brain_query first, then paste the result text here to clear the brain gate.
response_formatNoResponse verbosity. "concise" (default) strips noise, returns essential data only. "detailed" returns everything including raw metadata.concise

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is not read-only and not idempotent. The description adds meaningful behavioral context beyond annotations: long-running tools return a job_id to poll, brain_context errors require a brain_query round-trip, and backend/billing options affect execution. It does not contradict the annotations and adds useful operational detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. Critical routing rules are front-loaded with IMPORTANT and BRAIN markers, and the prose is structured around concrete workflows: discovery, invocation, long-running jobs, file handling, and brain_context resolution. There is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description covers the full lifecycle an agent needs: how to discover catalogue tools, how to call them, what to do with job_id, how to handle local files, how to satisfy the brain_context gate, and how to route providers and billing. The parameter schema is fully self-documenting, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description goes further by clarifying that brain_context must be passed at the top level, not inside input, and by explaining how image-composition tools merge multiple file IDs into a single image_urls array. These are semantics not fully captured in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Call a ToolRouter catalogue tool.' It clarifies the tool's role relative to discover, credits_balance, and other built-in tools by explicitly stating they are NOT catalogue tools and must never be called through use_tool. This clearly differentiates it from the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: use discover first, then pass the tool name and skill. It also states when NOT to use the tool (built-in tools should be called directly), and names alternatives such as job_get for polling long-running jobs, file_write for hosting local files, and brain_query for brain_context. This is thorough routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ToolRouter toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Tools are grouped by clear resource prefixes (account_, brain_, connector_, credential_, file_, job_, key_), and most actions have distinct purposes. A few boundaries overlap—brain_admin's lint action duplicates brain_lint, and account_preferences/setup/switch could momentarily confuse—but the descriptions resolve most ambiguity.

Naming Consistency3/5

The dominant pattern is resource_verb for actions (file_read, job_cancel, key_create) and resource_noun for state views (credits_balance, brain_settings, account_preferences), which is readable. However, exceptions like discover, use_tool, top_up_credits, and feedback_request_tool break the pattern, and the set is not consistently verb_noun.

Tool Count2/5

47 tools is well beyond the comfortable range; even though prefixes organize them, the agent faces a large selection surface with many narrowly scoped tools. A more consolidated set with action-based subcommands would be easier to navigate.

Completeness4/5

Core workflows are covered end-to-end: account setup and billing, connector and credential management, file CRUD, job polling, key lifecycle, brain knowledge management, and catalogue discovery/execution. Gaps are minor—outfit/persona/product/scene are list-only, connectors lack an update operation, and there is no explicit single-page brain get—but agents can generally work around them.

Resources