Skip to main content
Glama

ateam-mcp

by io.github.ariekogan

ateam_get_widget_catalog

Get the live catalog of widgets (UI plugins) available in this tenant's solution. Returns platform-bundled + solution-bundled + skill-declared widgets, each with a paste-ready how_to_use block (solution.json snippet + opener_call + persona_phrasing + binding_notes).

Use this when wiring widgets into a skill or solution — the how_to_use block is designed to be copied verbatim into the solution.json ui_plugins[] entry and into the persona's opener phrasing, so you don't have to hand-roll either. The catalog reflects what is actually deployed in the tenant right now, not the abstract spec (for the spec itself, use ateam_get_spec topic='widgets').

Origins: • 'platform' = widgets bundled with the platform (always available). • 'solution' = widgets bundled with this tenant's solution. • 'skill' = widgets declared by a specific skill in the solution.

Auth: forwards your authed api_key to Core (no master-secret involvement). Tenant scope is pinned by the key itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoOptional. 'full' (default) returns each widget with its paste-ready how_to_use block (solution.json snippet, opener_call, persona_phrasing, binding_notes). 'summary' returns just id/name/origin/description for a quick overview.
originNoOptional. Filter by widget origin. 'all' (default) returns everything. 'platform' = platform-bundled only. 'solution' = solution-bundled only. 'skill' = skill-declared only.
solution_idNoOptional. The solution to query. Defaults to the tenant's current solution.
include_unusedNoOptional. If true, includes widgets that are available but not currently referenced by any skill or ui_plugins entry. Default false (only widgets actually wired into the solution).

TDQS

A4.3/5.0
Behavior4/5

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 catalog reflects live tenant deployment (not spec), explains the auth model (forwards api_key, no master-secret, tenant scope pinned), and details the three origin types. It does not explicitly state it's read-only, but 'Get' plus the factual tone strongly imply so. Minor gaps like rate limits are not mentioned, but overall the behavior is well clarified.

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

Conciseness4/5

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

The description is well-structured with clear sections (purpose, usage, origins, auth) and front-loads the key value proposition. It is slightly longer than strictly necessary, but every sentence provides useful context and the bullet list for origins aids scanability. No fluff or redundancy.

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

Completeness4/5

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

For a tool with no output schema and four optional parameters, the description covers the return content (paste-ready how_to_use blocks with specific fields), usage context, origin semantics, and auth behavior. It lacks a detailed return schema, but the description provides enough for an agent to understand the tool's output shape. The tool is simple enough that this is sufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already fully documents all four parameters with detailed explanations. The description adds context about the how_to_use block and origins, but does not add meaning beyond the schema for the parameters themselves. This meets the baseline for high coverage without extra contribution.

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 clearly states the tool's purpose with a specific verb ('Get') and resource ('live catalog of widgets (UI plugins) available in this tenant's solution'). It enumerates what is returned (platform/solution/skill widgets with how_to_use blocks) and explicitly distinguishes itself from the related ateam_get_spec tool, making its scope unambiguous.

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?

It explicitly states when to use this tool ('Use this when wiring widgets into a skill or solution') and provides a clear alternative ('for the spec itself, use ateam_get_spec topic=\"widgets\"'). It also emphasizes real-time deployment status versus abstract spec, which helps the agent choose correctly.

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

All ateam-mcp 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

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that differentiate similar functions like chain polling vs. chain inspection. However, there is slight overlap between ateam_design_advisor, ateam_get_spec, and ateam_spec_search, which all serve design guidance, potentially causing confusion if descriptions are not read carefully.

Naming Consistency4/5

The naming mostly follows a consistent verb_noun pattern with the 'ateam_' prefix (e.g., ateam_get_solution, ateam_create_connector, ateam_test_skill). Minor deviations include ateam_patch (missing object) and ateam_redeploy (verb only), but overall the pattern is predictable and clear.

Tool Count3/5

With 47 tools, the count is high and exceeds the typical 15-tool threshold for a well-scoped set. However, the tools cover a broad and complex platform (auth, deployment, testing, GitHub integration, scaffolding), and each tool appears to have a distinct role, making the count borderline acceptable rather than excessive.

Completeness4/5

The tool set covers the full lifecycle of building, deploying, testing, and managing A-Team solutions, including design, GitHub integration, and verification. Minor gaps exist, such as no explicit tool for deleting individual files (though patching can overwrite) and no standalone skill listing, but these are not critical dead ends for an agent.

Resources