Discover tools that other agents commonly use TOGETHER with a given tool (from real usage). Call this to find the complementary tools you'll likely need next for a task, or to discover better-fitting tools you didn't know existed.
| Name | Required | Description | Default |
|---|---|---|---|
| toolId | Yes | The tool to find companions for. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'from real usage' but does not explain if the tool is read-only, requires authentication, has rate limits, or what the output format is. This lack of detail leaves the agent uncertain about side effects and expectations.
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 two sentences, front-loaded with the primary purpose, and every word contributes meaning. It is efficient 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?
The tool has no output schema and no annotations. The description omits what the return value looks like (e.g., list of tool names, with confidence scores?), making it incomplete for the agent to anticipate the result. For a tool relying solely on description, critical details about output are missing.
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 'toolId' has a description 'The tool to find companions for,' which adds meaningful context beyond the schema's type constraint. Since schema coverage is 100%, baseline is 3, and the description adds moderate value by clarifying the role of the parameter.
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: discovering tools commonly used together with a given tool from real usage. It uses specific verbs ('Discover') and resource ('tools that other agents commonly use TOGETHER'), and distinguishes from sibling tools like 'find_alternatives' and 'discover_tools'.
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 advises when to call the tool: 'to find the complementary tools you'll likely need next for a task, or to discover better-fitting tools you didn't know existed.' It provides clear context but does not mention when not to use it or specify exclusions relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct, well-defined purpose: checking reliability, discovering tools, finding alternatives, getting recipes, routing tasks, etc. No two tools overlap in function.
All tool names follow a consistent verb_noun pattern with underscores (e.g., check_tool_reliability, route_task, watch_tool). The only minor deviation is 'how_to_use_glimind', which still follows a clear verb phrase convention.
With 15 tools, the set is well-scoped for a comprehensive meta-layer covering discovery, reliability checking, preparation, batch routing, reporting, and notifications. Each tool earns its place.
The surface covers the full workflow of discovering, checking, preparing, calling, and reporting on tools. A minor gap is the lack of a direct 'list all tools' catalog, but the discovery tools effectively fill this need.