ComOS Federation

federation_solvency

Read-onlyIdempotent

Is the Com float actually backed? Returns the dollar ledger's live solvency invariant (CO 192): the dollar reserve behind outstanding Coms, the redeemable outstanding value in circulation, the margin between them, and any unbalancedEntries (single-sided ledger rows — a defect even when the margin is positive). solvent requires BOTH conditions. Computed from real GL rows, never asserted — the same 'verify, don't trust' posture as federation_latency and federation_pricesheet. Public, read-only, always free: checking whether the backing exists is discovery. CO 385. Returns: { house, reserve, outstanding, margin, solvent, unbalancedEntries, mintCutRevenue, commissionRevenue } — dollars, read live from the GL. Example: call federation_solvency with arguments {}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

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

First observedAug 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent), the description adds crucial behavioral details: it is public, read-only, always free, computed from real GL rows, never asserted, and notes that unbalanced entries are a defect even when margin is positive. This significantly enhances transparency about side effects and data provenance.

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 thorough but somewhat repetitive (e.g., 'public, read-only, always free' and 'same verify, don't trust posture'). It includes an example call and all necessary field definitions. While not overly verbose, the content could be slightly tightened without loss of information.

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?

The description fully explains the tool's domain: the meaning of each returned field (reserve, outstanding, margin, unbalancedEntries), the solvent condition requiring both conditions, the computation source (real GL rows), and the example output. Even without an output schema, the description provides complete context for the return values.

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?

The input schema has zero parameters (empty properties), so schema coverage is 100% and there is nothing to describe. The baseline for 0 parameters is 4, and the description correctly omits parameter details since none exist.

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 explicitly states the tool's purpose: it returns the live solvency invariant for a federation's dollar-backed currency, detailing the reserve, outstanding, margin, and unbalanced entries. It clearly identifies the resource (dollar ledger) and action (returns invariant), and distinguishes itself from sibling tools focused on latency or pricesheet.

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?

The description implies when to use the tool (to check solvency or backing existence) and clarifies it is computed from real GL rows, never asserted. It does not explicitly contrast with alternatives, but the sibling context makes the use case clear. The 'verify, don't trust' posture and 'checking whether backing exists is discovery' provide implicit guidance.

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

All ComOS Federation tools Inspect

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

Need Help?