Skip to main content
Glama

FLOCORE Governed MCP

by tech.flocore
OverviewDiscussionsAdmin

Server Details

Governed MCP front door to FLOCORE; write calls need human approval and signed receipts.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.3% over 52 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct action: screening text, registering an onboarding request, asking a support question, and verifying a counterparty receipt. There is no overlap in intent and the descriptions make the boundaries explicit. An agent can pick the right tool without hesitation.

Naming Consistency4/5

Three tools follow a consistent 'flocore_verb_noun' snake_case pattern, and 'aegis_inspect' uses the same verb_noun shape with a different product prefix. The mix of a two-segment name against three-segment names is a minor deviation, not a readability problem.

Tool Count4/5

Four tools is on the lean side but each maps to a distinct governance/trust capability (screen, onboard, support, verify), so nothing feels redundant. Slightly thin for a full governance lifecycle, but well-scoped for a public, tokenless surface.

Completeness3/5

Onboarding returns a request id and sandbox token but there is no tool to query request/approval status or check whether a live token has been issued, leaving a dead end in the primary workflow. Screening, support, and verification are self-contained, but the create-without-status gap is notable.

Available Tools

4 tools
aegis_inspectScreen for prompt injectionA
Idempotent
Inspect

Screen a prompt or text for injection, jailbreak and exfil intent. Free, public, defensive-only: returns a risk score (0..1), the detected intents, and whether it is suspicious. No token needed, no tenant data. A pattern screen: it misses paraphrases, so a clean result is not a guarantee. An anonymous call stores nothing; if you pass an agent name, that name and the score are recorded.

NameRequiredDescriptionDefault
textYesthe prompt or text to screen
agentNooptional: your agent name or a contact; if given, it is recorded with the score
referred_byNooptional: the agent id that referred you, so the referral is attributed to them

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the return payload (risk score 0..1, detected intents, suspicious flag), the no-token/no-tenant-data posture, the paraphrase blind spot, and precise data handling (anonymous calls store nothing; passing an agent name records the name with the score). This is exactly the retention and reliability information the annotations cannot convey.

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

Conciseness5/5

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

Four tight sentences, front-loaded with purpose, then outputs, then limitation, then data handling. No filler and no repetition of the title.

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?

There is no output schema, and the description fully compensates by enumerating the return fields and their meaning. Combined with the privacy and reliability disclosures, an agent has everything needed to call and interpret this correctly.

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 100%, so the baseline is 3, but the description adds real meaning about the privacy consequence of the optional 'agent' parameter (it becomes a recorded identifier) and clarifies that omitting all identity params keeps the call anonymous. It does not elaborate on 'referred_by' beyond the schema.

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?

States a specific verb and resource ('Screen a prompt or text for injection, jailbreak and exfil intent') and immediately scopes it as free, public and defensive-only. The function is unambiguous and clearly distinct from the flocore_* account/verification siblings.

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?

Gives clear context for invocation (defensive screening of untrusted prompts, no token or tenant data required) and a real caveat that a pattern screen misses paraphrases so a clean result is not a guarantee. It stops short of naming alternatives or explicit when-not-to-use conditions.

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

flocore_onboard_requestRequest governance onboardingAInspect

Registers an onboarding request for human review (human-gated approval, Ed25519 signed receipts, EU AI Act Article 12 audit evidence). Public: no token needed. Returns a request id and a sandbox token (fc_test_...) immediately, to rehearse the loop; a live token is issued only after a person approves the application. Set rehearsal_only to true to get a sandbox token without applying.

NameRequiredDescriptionDefault
orgNooptional: the organisation the agent acts for
agentYesyour agent name or identifier
sourceNooptional: where you found us, for example a registry or the pitch (letters, digits, dots and dashes)
public_keyNooptional: your agent's own Ed25519 PUBLIC key, raw 32 bytes as base64url or a public JWK as JSON text. Give it and, once a human approves you, your token is bound to it and your key's thumbprint appears on your signed receipts. Never send a private key.
referred_byNooptional: the governed agent or partner that sent you here (recorded as the referral)
intended_useNooptional: what world-affecting actions you want governed
jurisdictionNooptional: the legal jurisdiction that brought you here, a code from the Advatar pitch (eu, coe, za, kr, us, vn, ng, ke, mx, oecd). Recorded so we learn which law matters to builders
owner_contactNothe email address of the person who owns the agent, so a person can approve it and be sent its token (required unless rehearsal_only is true)
rehearsal_onlyNooptional: true to get ONLY a sandbox token to rehearse the approval loop. Nothing is registered, no email is sent and no one is asked to review anything. Limits: 3 per hour per connection. To apply for real, call again without it and give owner_contact

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false). The description goes well beyond that: human-gated approval, Ed25519 signed receipts, EU AI Act Article 12 audit evidence, the fact that a live token is issued only after a person approves, and the 3-per-hour rehearsal rate limit. That is exactly the kind of behavioral context annotations cannot carry.

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?

Front-loads the core action and the immediate return value, then handles the rehearsal variant. Dense with parentheticals but each sentence carries distinct information; slightly packed, though nothing is genuinely redundant.

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?

There is no output schema, so the description carries the return-value burden — and it does: a request id plus an fc_test_ sandbox token immediately, with a live token only after human approval. Combined with the auth note ('no token needed') and the approval gating, an agent has everything needed to call this correctly.

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 schema already documents all nine parameters in detail. The description reinforces the owner_contact/rehearsal_only dependency and names the sandbox token prefix (fc_test_...), but adds little syntax or constraint information beyond what the schema already states. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ('Registers an onboarding request for human review') and immediately distinguishes itself from siblings by describing a registration/approval flow rather than inspection, verification, or support. An agent can tell what this tool does without opening the schema.

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?

Gives clear operational context: 'Public: no token needed', and explicitly routes between two modes — 'Set rehearsal_only to true to get a sandbox token without applying' versus applying for real with owner_contact. It does not, however, contrast itself against the sibling tools (aegis_inspect, flocore_verify_counterparty), so the when-not-to-use case is left implicit.

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

flocore_support_askAsk FLOCORE support, agent to agentA
Read-only
Inspect

Ask a plain-English support/product question about FLOCORE itself, agent to agent, instead of a helpdesk. Public, no token needed. Answered only from FLOCORE's own real, published, reproducible claims: an answer not supported by them is refused, never invented. Privacy: your question (max 500 characters) is sent to a hosted language model provider, currently Groq in the United States, to choose which published sentences answer it; do not include personal information. See https://humanseal.world/privacy.html.

NameRequiredDescriptionDefault
questionYesyour plain-English question about FLOCORE

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, openWorld, non-idempotent, non-destructive). The description adds substantially beyond that: no token required, answers restricted to published reproducible claims with refusal rather than invention, a 500-character input limit, and explicit disclosure that the question is sent to a hosted model provider (Groq, US) with a PII warning and privacy link. This is unusually rich disclosure.

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?

Front-loads the purpose, then layers trust model and privacy. Every clause is substantive, though the privacy/provider sentence is dense and the length pushes the limit of what is warranted.

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?

For a single-parameter, no-output-schema read tool, the description covers purpose, trust behavior, input limits, and privacy/legal context. Nothing essential to correct invocation is missing.

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?

There is only one parameter and schema coverage is 100%, so the baseline is 3. The description still adds value the schema lacks: the max 500-character constraint and the plain-English framing of what the string should contain.

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?

States a specific verb (ask) and resource (a plain-English support/product question about FLOCORE itself) and immediately frames the mechanism ('agent to agent, instead of a helpdesk'). An agent can tell this apart from the sibling tools (inspect, onboard, verify) because those are actions on a counterparty, not Q&A about FLOCORE.

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?

Gives clear context: use this for support/product questions about FLOCORE rather than a helpdesk. It frames the domain of applicability well but never names a sibling tool or states exclusions for when another tool should be preferred.

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

flocore_verify_counterpartyVerify a counterparty agentA
Read-onlyIdempotent
Inspect

Before transacting with another agent, check whether it is FLOCORE-governed (a human-approval gate on its world-affecting actions, Ed25519 signed receipts) and, if it handed you a receipt, verify that receipt independently. Public, no token needed. A sandbox receipt is reported as a rehearsal and never as valid proof.

NameRequiredDescriptionDefault
agent_slugYesthe counterparty's FLOCORE agent/tenant slug
receipt_canonicalNooptional: the receipt's `canonical` field, if the counterparty handed you one to check
receipt_signature_ed25519Nooptional: the receipt's `signature_ed25519` field, required together with receipt_canonical to verify it

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds genuinely new context: no token/auth is required, and a sandbox receipt is reported as a rehearsal and never as valid proof. That sandbox-handling rule is a non-obvious output behavior the agent could not get from annotations.

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

Conciseness5/5

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

Three sentences, zero filler: the trigger, the action with its mechanism, and the constraint. The most important information (do this before transacting) is front-loaded, and each sentence carries distinct content.

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 public, read-only verification tool with no output schema, the description covers purpose, trigger, auth posture, and sandbox caveat. It does not say what a negative result looks like (e.g., a non-governed agent, or a receipt that fails signature verification), leaving some result interpretation to inference.

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 all three parameters are already documented in the schema. The description only alludes to the receipt pair without adding format or syntax detail beyond what the schema states, so the baseline 3 applies.

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 names two specific operations — checking whether a counterparty is FLOCORE-governed and independently verifying a handed-over receipt — with the concrete mechanism (human-approval gate, Ed25519 signed receipts). It is clearly distinguishable from siblings like aegis_inspect or flocore_onboard_request, which handle different concerns.

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 triggering condition is explicit and front-loaded: 'Before transacting with another agent...'. The conditional part ('if it handed you a receipt') also tells the agent when the optional parameters apply. It stops short of naming alternate tools or stating when NOT to call this one.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedflocore_onboard_request3 fields changed
      • changedInput schema / properties / owner_contact / description
        Previous value: -"an email or handle we can reach to confirm onboarding"New value: +"the email address of the person who owns the agent, so a person can approve it and be sent its token (required unless rehearsal_only is true)"
      • addedInput schema / properties / rehearsal_only
        Added value: +{
+  "description": "optional: true to get ONLY a sandbox token to rehearse the approval loop. Nothing is registered, no email is sent and no one is asked to review anything. Limits: 3 per hour per connection. To apply for real, call again without it and give owner_contact",
+  "type": "boolean"
+}
      • changedInput schema / required
        Previous value: -[
-  "agent",
-  "owner_contact"
-]New value: +[
+  "agent"
+]
  2. 2 tool updates
    • Changedaegis_inspect1 field changed
      • changedInput schema / properties / agent / description
        Previous value: -"optional: your agent name or a contact, to register interest and be onboarded to governed (human-gated, signed-receipt) actions"New value: +"optional: your agent name or a contact; if given, it is recorded with the score"
    • Changedflocore_onboard_request1 field changed
      • changedInput schema / properties / referred_by / description
        Previous value: -"optional: the governed agent or partner that sent you here (so credit flows to whoever brought you)"New value: +"optional: the governed agent or partner that sent you here (recorded as the referral)"
  3. 1 tool update
    • Changedflocore_onboard_request2 fields changed
      • addedInput schema / properties / jurisdiction
        Added value: +{
+  "description": "optional: the legal jurisdiction that brought you here, a code from the Advatar pitch (eu, coe, za, kr, us, vn, ng, ke, mx, oecd). Recorded so we learn which law matters to builders",
+  "type": "string"
+}
      • addedInput schema / properties / source
        Added value: +{
+  "description": "optional: where you found us, for example a registry or the pitch (letters, digits, dots and dashes)",
+  "type": "string"
+}
  4. 11 tool updates
    • Removedflocore_ask
    • Removedflocore_create_ticket
    • Removedflocore_gate_action
    • Removedflocore_list_tenants
    • Removedflocore_list_tickets
    • Removedflocore_mesh_lanes
    • Removedflocore_ontology_entities
    • Removedflocore_orch_board
    • Removedflocore_queue_summary
    • Removedflocore_recall
    • Removedflocore_sandbox_approve
  5. 2 tool updates
    • Addedflocore_gate_action
    • Addedflocore_sandbox_approve
  6. 1 tool update
    • Changedflocore_onboard_request1 field changed
      • addedInput schema / properties / public_key
        Added value: +{
+  "description": "optional: your agent's own Ed25519 PUBLIC key, raw 32 bytes as base64url or a public JWK as JSON text. Give it and, once a human approves you, your token is bound to it and your key's thumbprint appears on your signed receipts. Never send a private key.",
+  "type": "string"
+}
  7. 1 tool update
    • Addedflocore_support_ask
  8. 3 tool updates
    • Changedflocore_create_ticket3 fields changed
      • addedInput schema / properties / description / description
        Added value: +"optional: full ticket detail"
      • addedInput schema / properties / tenant_slug / description
        Added value: +"the tenant this ticket belongs to"
      • addedInput schema / properties / title / description
        Added value: +"a short summary of the ticket"
    • Changedflocore_queue_summary1 field changed
      • addedInput schema / properties / tenant_slug / description
        Added value: +"optional: scope to one tenant"
    • Changedflocore_recall3 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"optional: max results to return"
      • addedInput schema / properties / query / description
        Added value: +"what to recall, in plain English"
      • addedInput schema / properties / scope / description
        Added value: +"optional: narrow the recall to a silo/scope"
  9. 1 tool update
    • Addedflocore_verify_counterparty
  10. 1 tool update
    • Changedflocore_create_ticket1 field changed
      • addedInput schema / properties / approval_id
        Added value: +{
+  "description": "after a person approved this exact call, the id of that approval; the call then runs once",
+  "type": "string"
+}
  11. 1 tool update
    • Addedflocore_ask
  12. 1 tool update
    • Changedaegis_inspect1 field changed
      • addedInput schema / properties / referred_by
        Added value: +{
+  "description": "optional: the agent id that referred you, so the referral is attributed to them",
+  "type": "string"
+}
  13. 1 tool update
    • Changedflocore_onboard_request1 field changed
      • addedInput schema / properties / referred_by
        Added value: +{
+  "description": "optional: the governed agent or partner that sent you here (so credit flows to whoever brought you)",
+  "type": "string"
+}
  14. 1 tool update
    • Addedflocore_onboard_request

Related MCP Connectors

Related MCP Servers

  • veor

    winterbim
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides a governed execution boundary for AI agents, enforcing deterministic policy, one-shot human approvals, and signed receipts for MCP tool effects.
    MIT
  • Verax by verax-ai

    Veraxofficial

    verax-ai
    A
    license
    A
    quality
    A
    maintenance
    Enables MCP-speaking agents to execute tool calls through an authorization gate, producing signed decision records and reconciled effect rows for accountability.
    6
    Apache 2.0

  • rails-mcp

    jaimenbell
    A
    license
    A
    quality
    C
    maintenance
    Default-deny action registry, append-only spend ledger, and human sign-off audit trail (MCP tools).
    6
    MIT

  • mcpclerk

    hishamalward
    A
    license
    Not graded
    quality
    A
    maintenance
    Provides a governance proxy layer for MCP servers, enforcing per-tool allowlists, human approval for write operations, quotas, secret redaction, and a hash-chained audit log of all calls.
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources