MCP server providing access to the GeniusFlow Federation API for entity dossiers, reports, claims verification, and grounding checks.
This server has significant definition quality gaps. Tool names lack action verbs (gf_status, gf_dossier, gf_cite are domain-specific prefixes, not verb_noun patterns). Descriptions are present but often cryptic and domain-jargon-heavy ('Darshan', 'proof_shape', 'ledger-backed claims[]') without explaining WHEN to use each tool or WHAT the LLM should expect. Most parameters lack descriptions entirely (gf_status, gf_darshan, gf_openapi have empty properties; gf_cite's 'kind' and 'id' lack descriptions; gf_package's 'claim' is minimally described). Output schemas are completely undocumented, no tool declares what fields it returns. Error handling is absent from definitions. The server is a thin HTTP wrapper around a remote API, so tool semantics depend entirely on backend behavior, which is not visible here.
GET cite catalog, or POST one cite packet {kind,id,claim?}.
GET public Darshan (refuse/admit samples + provenance rail).
GET entity dossier card (claims[] when ledger-backed).
GET OpenAPI 3 document for federation endpoints.
Package disposition admit/refuse over a published claim object. Returns disposition + versioned proof_shape.
GET bundled report feed for an entity.
GET return-wire consumption ack ring (read).
Tool names do not follow verb_noun convention. All 9 tools use domain-specific prefixes (gf_*) without action verbs. LLMs cannot infer intent from names alone. Examples: 'gf_status' should be 'get_federation_status', 'gf_dossier' should be 'get_entity_dossier', 'gf_cite' should be 'get_cite_catalog' or 'post_cite_packet'.
Output schemas completely undocumented. No tool declares what fields it returns. LLMs cannot plan downstream calls or extract data. gf_status, gf_darshan, gf_openapi have empty inputSchema properties and no outputSchema at all.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 30 | 2026-07-28+ | v2 |
Federation SLA/status: build_id, bake time, endpoint health, honest tier.
Re-check grounding: source_url + expected must come from published claims[]. Do not invent expected from report HTML. Returns proof_shape.
Parameter descriptions missing or minimal. gf_cite 'kind' and 'id' have no descriptions. gf_package 'claim' is described as 'Published claim from dossier claims[]' but does not explain structure or required fields. gf_verify 'location' has no description. LLMs cannot validate inputs without explicit guidance.
Descriptions use domain jargon without explanation. 'Darshan', 'proof_shape', 'ledger-backed claims[]', 'registry_ref limb', 'honest tier' are unexplained. LLMs cannot determine WHEN to call these tools or what they return. Descriptions should be 50-200 chars, clear, and actionable.
No error handling guidance in tool definitions. No indication of retryable vs fatal errors, no recovery suggestions, no validation rules. The _http() function catches exceptions but returns generic error dicts without actionable guidance for LLMs.