Skip to main content
Glama

ComOS Federation

by io.github.ronrey

introspection_system_coverage_gaps

Read-onlyIdempotent

Enumerate structural coverage gaps (silent tools, artifacts with no eval, un-probed tenants). scope_kind: federation | tenant; scope_id required if scope_kind=tenant. Optional limit caps the returned Gap rows; summary always reports total_gaps/returned/by_category for the full set. Returns {kind: "evidenced", value: Gap[], chain, summary} or {kind: "no_evidence_available", reason}. Returns: The set of known coverage gaps, with a summary (total_gaps, returned, by_category) that always reflects the full set even when limit truncates the rows. Example: call introspection_system_coverage_gaps with arguments {"scope_kind":""}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNo
limitNo
scope_idNo
scope_kindYes

Schema Changelog

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

  1. Changed1 schema field changed
    • addedInput schema / properties / limit
      Added value: +{
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / repo / maxLength
      Added value: +4000
    • addedInput schema / properties / scope_id / maxLength
      Added value: +4000
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already signal readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavior beyond that: limit truncates returned Gap rows while summary always reflects the full set, and it documents two return variants. This is useful and does not contradict the annotations.

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

Conciseness3/5

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

The description is front-loaded with the action and resource, but it repeats the return behavior twice ('Returns {kind...}' and 'Returns: The set of known coverage gaps...') and includes a placeholder example that adds little. It is compact but somewhat redundant.

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 read-only tool with no output schema, the description covers inputs, return shape, limit/summary invariants, and a fallback return case. It does not document the repo parameter or explain the structure/meaning of Gap and chain, but the core invocation and expected result behavior are adequately specified.

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 0%, so the description carries the burden. It explains scope_kind enum values, the conditional requirement for scope_id, limit's effect on returned rows and summary, and gives a usage example. However, the optional repo parameter is not described at all, leaving a small but clear gap.

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?

Description starts with a specific verb 'Enumerate' and a clear resource: 'structural coverage gaps' with concrete examples (silent tools, artifacts with no eval, un-probed tenants). It distinguishes this from sibling introspection tools by focusing on gap enumeration rather than probing, querying, or change tracking.

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

Usage Guidelines4/5

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

Provides clear operational context: scope_kind values, conditional scope_id requirement, optional limit behavior, summary semantics, and an example invocation. It does not explicitly name sibling tools or state when not to use it, but the conditions for correct usage are sufficiently clear.

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

All ComOS Federation 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.6/5.0
Disambiguation4/5

Tools are grouped by clear domain prefixes (federation_*, introspection_*, moltbook_*) with each targeting a distinct resource+action (bond_post/release/status, key_challenge/bind/status, journal_append/read). The primary near-overlap — catalog_search_multi vs catalog_search_grouped_multi — is explicitly disambiguated in descriptions. Minor confusion risk exists among the four knowledge tools (federation_help, federation_why, about_us_about, how_to_about) but their purposes (how/why/manual/walkthrough) are distinct enough.

Naming Consistency3/5

The dominant `federation_<verb>_<noun>` pattern (create_tenant, list_agents, bond_release) is strong, but it's mixed with bare-noun tools (federation_arena, federation_offer, federation_solvency, federation_pricesheet, federation_help) and noun-noun variants (federation_manager_tree, federation_tenant_info). Non-federation tools use a loose `<domain>_<verb>` or single-token convention (legal_get, web_research, about_us_about). Readable overall, but conventions are noticeably mixed across the surface.

Tool Count2/5

At 72 tools this crosses the 50+ threshold for an extreme count. While the federation's scope is genuinely broad (manager lifecycle, tenants, catalog, agents, bonds, keys, journal, canon, introspection, social, email, research), the surface is bloated — roughly 15 bare introspection tools (list_nodes, probe, confidence, diff, coverage_gaps, co_decisions, climb_history, change_graph, change_reach, corpus_*) cover meta-self-knowledge that could plausibly collapse into fewer verbs. Agents would face a very large selection space.

Completeness5/5

The tool surface is exhaustively complete for the federation domain: applicant and operator sides of admittance, full manager lifecycle (create/list/freeze/attest/bond/key), full tenant lifecycle (create/list/info/update/suspend/delete/enter), catalog discovery with change-detection, pricing, solvency, latency, journaling, governance, legal, and even external outreach (email/moltbook/research). No dead ends exist — every write has a corresponding read/status path, and branched platform tools are intentionally deferred behind enter_tenant rather than omitted.

Resources