Get usage instructions for the MCP federation. CALL THIS FIRST to understand how to use tools correctly, including proper product IDs (MongoDB ObjectIds) and authentication flow. Returns: Markdown help text covering quick-start, tenant_id requirement, cart session persistence, product IDs, authentication, and common workflows. Example: call federation_help with arguments {}.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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?
Annotations already mark readOnly/idempotent/non-destructive, and the description aligns without contradiction. It adds value beyond the annotations by specifying the return type (Markdown) and the content topics (tenant_id, product IDs, auth, workflows), which gives the agent expectations for the response.
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 tightly packed sentences plus an example. It front-loads the purpose, states the critical usage guidance, summarizes the return payload, and gives an example call 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—no parameters, no output schema, read-only help content—the description covers purpose, usage priority, return format, content areas, and an invocation example. Nothing essential is missing for an agent to select and invoke it 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?
There are zero parameters, and the schema coverage is 100% (empty object), so there is little to add. The description explicitly notes 'call federation_help with arguments {}', confirming the expected invocation and satisfying the 0-param baseline.
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 'Get usage instructions' with resource 'MCP federation', and the 'CALL THIS FIRST' directive positions it as the meta-help tool distinct from the many federation_* siblings. It clearly communicates its role as an onboarding/instruction tool rather than a domain operation.
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 instructs to call this first to learn correct usage, including product IDs and authentication flow, which serves as a clear when-to-use. It doesn't name alternatives or exclusions, but because this is a unique help tool, 'CALL THIS FIRST' provides sufficient contextual guidance.
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.
Most tools have clearly distinct purposes with detailed descriptions. A few pairs like federation_catalog_search_multi and federation_catalog_search_grouped_multi could be confused, but descriptions explicitly delineate when to use each. Overall, the boundaries are clear.
The federation_* tools follow a consistent verb_noun pattern, but many tools use other prefixes (introspection_, moltbook_, llm_, web_, cohort_, legal_, about_us_, how_to_), breaking overall consistency. Within the main federation domain naming is predictable, but across the full set it's mixed.
72 tools is far beyond the typical 3-15 for a coherent set. While the federation scope is broad, the sheer number makes the surface unwieldy and increases the risk of misselection, even if each tool individually earns its place.
The tool surface covers lifecycle management (create/update/delete/suspend tenants), manager operations, agents, catalog search, governance, introspection, legal, and auxiliary functions like email and web research. Platform-specific actions are exposed via federation_enter_tenant, so no critical dead ends are apparent.