Skip to content
FlowMCP v4

Eligibility

Conformance language (MUST/SHOULD/MAY) follows BCP 14 [RFC2119]/[RFC8174] as defined in 00-overview.md. The binding source is the FlowMCP Schemas Specification v4.2.0.

Purpose

Section titled “Purpose”

This chapter defines what is allowed to be part of a gradable schema. Eligibility is the upstream gate: an endpoint that is not eligible MUST NOT appear in a schema. The maximalism principle in 01-default-journey.md operates inside the eligibility boundary — “all admitted endpoints” means “all endpoints that pass the rules in this chapter”.

Read Focus (SHOULD)

Section titled “Read Focus (SHOULD)”

The core focus of a FlowMCP schema is reading data. Write, update, and delete operations are not categorically forbidden, but they SHOULD NOT appear in a schema.

  • Graders MUST NOT execute state-changing calls during grading. All grader-driven test invocations MUST be read-only.
  • Schema authors SHOULD restrict the schema surface to read endpoints.

A schema that contains write/update/delete tools without an explicit, documented justification will be flagged under Exclusion Criteria below.

Exclusion Criteria (MUST NOT appear in a schema)

Section titled “Exclusion Criteria (MUST NOT appear in a schema)”

The following endpoints MUST NOT be included in a gradable schema:

  1. Legally non-public endpoints — endpoints that, by law or by the provider’s published terms, are not permitted for public use.
  2. Non-general endpoints — customer- or tenant-specific administration APIs (e.g. account-management endpoints scoped to a single tenant).
  3. Write/update/delete endpoints without justification — write operations that lack a specific, documented reason for inclusion.
  4. Reachable but undocumented endpoints — endpoints that are publicly reachable but not actually documented. These MAY indicate a provider-side defect (an endpoint that was unintentionally exposed) and MUST NOT be included on the assumption that “reachable = public-intent”.

The undocumented-endpoint exclusion is a distinct, named exclusion ground. Reachability is not documentation.

Empty-Context Convention (NEW in 1.1.0)

Section titled “Empty-Context Convention (NEW in 1.1.0)”

A grading is performed in an empty LLM context (/clear before start). This obligation is conventional — it is not machine-checked, but is ensured through the entry-point prompt (see 20-entry-point-prompt.md) and the responsibility of the grader. By starting the prompt, the grader confirms that no relevant prior context from earlier sessions is present.

Rationale: pre-loading the context (e.g. through prior research on the domain) systematically biases the persona evaluation upward. Empty context is the operational precondition for the persona Lens (see 12-personas-contract.md) to evaluate genuinely from the assigned persona rather than from the prior knowledge of the grader LLM.

AspectValue
Obligation typeConvention (organisational, not technical)
AnchoringEntry-point prompt in the grading repository (20-entry-point-prompt.md)
Checkable?No — trust-based
Consequence of violationEvaluation drift (the persona Lens escapes into the LLM’s prior knowledge)

Reference: 20-entry-point-prompt.md (entry-point prompt template).

Access Classes

Section titled “Access Classes”

A schema’s endpoints fall into one of three access classes:

ClassStatusConditions
Free, no API keyPermittedEndpoint is callable without any credential.
API key (static)PermittedAPI key is passed at runtime start as a static parameter (e.g. requiredServerParams).
Commercial with free tierPermittedAt least a partial free tier exists; otherwise the endpoint is treated as non-eligible.

OAuth — MUST NOT

Section titled “OAuth — MUST NOT”

OAuth-based access is out of scope for gradingSpec/1.0.0. Endpoints whose only access path is OAuth (interactive consent flow, user-bound tokens) MUST NOT be part of a gradable schema. This is a hard exclusion, not a soft “currently unsupported” — implementers MUST treat it as MUST NOT per BCP 14.

OAuth support MAY be introduced in a later spec version. Until then, no exception.

Schema Splitting (MUST)

Section titled “Schema Splitting (MUST)”

If a single API exposes both freely accessible and API-key-only endpoints, the freely accessible endpoints and the API-key-only endpoints MUST be split into separate schemas.

  • One schema MUST NOT mix free and API-key-only endpoints.
  • The split MUST be reflected in the schema metadata (e.g. distinct namespaces or distinct schema files).
  • This split is independent of the maximalism principle: both schemas — the free schema and the API-key schema — MUST individually be maximalist under 01-default-journey.md.

The reason for the split is twofold: it lets the free schema be used without credentials, and it lets the grader run the free schema fully autonomously while gating the API-key schema on credential availability.

Target Audience for Data Sources

Section titled “Target Audience for Data Sources”

The primary target audience for FlowMCP data sources is public interfaces:

  • Public-sector authorities.
  • Public institutions (universities, statistical offices, regulators).
  • Private parties offering public data (open-data publishers).

The secondary target audience is commercial providers with a free tier.

Selection of data sources SHOULD reflect this priority order. Commercial APIs without a free tier do not belong in the FlowMCP corpus.

Verification

Section titled “Verification”

The eligibility rules of Exclusion Criteria–Target Audience for Data Sources are verified during the grading areas defined in 04-phases-single.md:

The detailed verification method belongs to the grader implementation and is out of scope for this chapter.

Cross-References

Section titled “Cross-References”
Section titled “Related”