Read-only MVR preflight for trust, permission, evidence gaps, and African market-entry readiness.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 5 of 5 tools scored.
Each tool has a distinct role in the MVR workflow: preflight, entity resolution, evidence completeness check, context compilation, and decision routing. No two tools overlap in purpose, and the descriptions clearly specify when each should be used.
All tools share the 'mvr_' prefix, but the suffix pattern is inconsistent: context_compile, decision_check, and entity_resolve follow a noun_verb structure, while evidence_completeness and first_call are noun phrases. This mixed convention reduces predictability, though the prefix provides some coherence.
Five tools is appropriate for the decision-governance pipeline they represent—each step from initial preflight to final routing has a dedicated tool. The scope is neither bloated nor thin.
The toolset covers the full decision pipeline: first_call preflight, entity resolution, evidence completeness, context compilation, and final decision routing. Minor gaps include a lack of explicit evidence-capture tooling, but that appears to be external to the server's design, so the surface is reasonably complete for its purpose.
mvr_context_compileCompile evidence contextAUse after evidence capture to separate safe from unsafe inferences across formal, field, market, trust, and stakeholder context. It compiles context; it does not authorize action. Use when: Use when evidence is mixed and the agent needs safe claims versus unsafe claims before a verdict. Do not use when: Do not use as a go/no-go decision. Submit only consented, data-minimized, redacted or aggregated evidence; never raw confidential datasets, secrets, credentials, or personal identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Resolved subject, market scope, and mixed evidence to compile into safe and unsafe inferences. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| workflow_id | No | |
| formal_proof | No | |
| mcp_next_call | No | |
| mcp_next_tool | No | |
| response_meta | No | |
| safe_inferences | No | |
| workflow_status | No | |
| unsafe_inferences | No | |
| workflow_expires_at | No | |
| mvr_response_receipt | No | |
| required_user_inputs | No | |
| verification_required | No | |
| sentiment_trust_signal | No | |
| continuation_disposition | No | |
| informal_operating_signal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description clarifies that the tool 'does not authorize action' and imposes privacy constraints on submitted evidence, adding valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and uses a clear 'Use when/Do not use when' structure. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complex nested payload and output schema present, the description sufficiently covers the tool's role in the workflow, input restrictions, and non-authorization behavior, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the payload, but the description enriches semantics by indicating the types of context (formal, field, market, trust, stakeholder) and the requirement for redacted/aggregated evidence, which maps to the payload structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('separate') and resource ('safe from unsafe inferences across formal, field, market, trust, and stakeholder context'), clearly distinguishing it from siblings like mvr_decision_check or mvr_evidence_completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'Use when' (evidence is mixed, before a verdict) and 'Do not use when' (as a go/no-go decision), plus input constraints about consented, data-minimized evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_decision_checkCheck evidence before MVR scoringAUse after evidence completeness to route a structurally complete pack toward licensed MVR scoring or abstain on missing proof. This public tool does not compute market, pilot, or scale readiness. Use when: Use after evidence completeness to determine whether the pack can be routed to licensed MVR scoring or still requires proof. Do not use when: Do not use as readiness, pilot, credit, legal, regulatory, or scale authorization. Submit only consented, data-minimized, redacted or aggregated evidence; never secrets, credentials, or personal identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Decision question, resolved subject, market scope, and evidence for a bounded recommendation or abstention. |
| Name | Required | Description |
|---|---|---|
| reason | No | |
| status | No | |
| workflow_id | No | |
| evidence_gaps | No | |
| mcp_next_call | No | |
| mcp_next_tool | No | |
| not_a_verdict | No | |
| response_meta | No | |
| recommendation | No | |
| workflow_status | No | |
| safe_next_action | No | |
| verification_basis | No | |
| workflow_expires_at | No | |
| mvr_response_receipt | No | |
| required_user_inputs | No | |
| continuation_disposition | No | |
| sandbox_evaluation_scope | No | |
| live_mvr_scoring_executed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnly/destructive annotations, including the abstention behavior and strict data submission constraints (consented, data-minimized, redacted, no secrets). This is valuable context that the annotations do not provide, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections, but it contains redundancy: 'Use after evidence completeness' appears in the opening sentence and again in the 'Use when' section. This repetition makes it slightly less concise than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested schema and the existence of an output schema, the description is largely complete. It explains the routing/abstain behavior and data handling constraints, while the output schema covers return values. Minor gaps remain around what constitutes 'missing proof' but this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a crucial semantic constraint about the evidence submitted (consented, minimized, redacted, etc.) that is not apparent from the schema alone, elevating it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to route a structurally complete pack toward licensed MVR scoring or abstain on missing proof. It uses a specific verb ('route') and resource ('structurally complete pack'), and distinguishes itself from sibling tools by noting it does not compute market, pilot, or scale readiness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do not use when' sections, stating it should be used after evidence completeness and not as readiness, pilot, credit, legal, regulatory, or scale authorization. This clearly positions the tool relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_entity_resolveResolve the venture and marketAUse when a startup, venture, programme, company, partner, or market actor must be resolved to a country, sector, and archetype before relational-readiness evidence is assessed. Use when: Use immediately after mvr_first_call when the user gives a company, venture, sector, country, or ambiguous market actor name, so the subject and target geography are resolved before evidence is assessed. Do not use when: Do not use as a readiness verdict or for unrelated entity lookup. Never submit secrets, personal identifiers, raw private interviews, or confidential evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Entity and market context to canonicalize before evidence assessment. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| warning | No | |
| workflow_id | No | |
| mcp_next_call | No | |
| mcp_next_tool | No | |
| response_meta | No | |
| workflow_status | No | |
| canonical_entity | No | |
| workflow_expires_at | No | |
| mvr_response_receipt | No | |
| required_user_inputs | No | |
| continuation_disposition | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context beyond that: it warns against submitting secrets, personal identifiers, raw private interviews, or confidential evidence, and clarifies the tool is a pre-evidence resolution step, not a readiness verdict. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with 'Use when' and 'Do not use when' sections and a safety warning. The only minor issue is redundancy: 'Use when' appears twice (first sentence and the following 'Use when:'), making it slightly less concise than ideal. Overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides complete context for an AI agent: when to use (after mvr_first_call), the types of inputs it handles, what it resolves, exclusions, and a data-handling constraint. Since an output schema exists, return value details are not necessary. This is sufficient for both selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with each parameter having a description, so the description need not repeat parameter details. It provides context for what the payload is meant to achieve (resolving to country/sector/archetype) but does not add per-parameter semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool resolves an entity (startup, venture, company, etc.) to a country, sector, and archetype, using the verb 'resolve' and naming the resource. This distinguishes it from siblings like mvr_decision_check, which assesses readiness, and mvr_first_call, which is the preceding step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use immediately after mvr_first_call' and specific trigger conditions (user gives company, venture, sector, country, or ambiguous market actor). Do-not-use exclusions are also clear ('Do not use as a readiness verdict or for unrelated entity lookup'), giving an agent unambiguous selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_evidence_completenessCheck evidence completenessAUse after entity resolution and before any readiness claim to check verification status, source-family diversity, stakeholder coverage, and missing proof. Do not treat completeness as authorization. Use when: Use after entity resolution and before any verdict when evidence may be incomplete or one-sided. Do not use when: Do not treat completeness as readiness or authorization. Submit only consented, data-minimized, redacted or aggregated evidence; never raw private interviews, secrets, credentials, or personal identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Evidence pack and decision context to test for missing proof. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| workflow_id | No | |
| evidence_gaps | No | |
| mcp_next_call | No | |
| mcp_next_tool | No | |
| response_meta | No | |
| evidence_count | No | |
| workflow_status | No | |
| safe_next_action | No | |
| verification_basis | No | |
| workflow_expires_at | No | |
| mvr_response_receipt | No | |
| required_user_inputs | No | |
| stakeholder_coverage | No | |
| verified_evidence_count | No | |
| continuation_disposition | No | |
| verified_source_families | No | |
| unverified_evidence_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and non-destructive, and the description adds substantial behavioral context: it states that completeness must not be treated as authorization, and imposes strict privacy constraints ('consented, data-minimized, redacted or aggregated evidence; never raw private interviews, secrets, credentials, or personal identifiers'). These go beyond the annotations and clarify important safety boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat redundant: 'Do not treat completeness as authorization' appears twice, and the 'Use when' line largely repeats the first sentence. While it is still informative, it could be tightened to a single concise paragraph without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex nested schema and presence of an output schema, the description covers purpose, timing, exclusions, and privacy constraints adequately. It doesn't explain return values, but the output schema covers that. Minor gap: it doesn't describe actions taken when evidence is found incomplete, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds conceptual meaning by mapping the tool's evaluation to schema fields like source_class and stakeholder_class, thereby enriching understanding of what the parameters represent. However, it does not detail individual field usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'check' and resource 'evidence completeness', listing concrete dimensions (verification status, source-family diversity, stakeholder coverage, missing proof). It also distinguishes from siblings by stating it is used 'after entity resolution and before any readiness claim', differentiating it from mvr_decision_check and mvr_entity_resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do not use when' sections, advising use after entity resolution and before verdicts, and warning against treating completeness as authorization or readiness. This gives clear context and exclusions, even though it doesn't name sibling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_first_callStart MVR relational-readiness preflightAUse this MVR public decision-governance preflight before AI recommends pre-MVP build, entry, BNPL, investment, partnership, or scale. Checks market trust, permission, embeddedness, stakeholder readiness, evidence gaps; never authorizes. Use when: Use before enter, launch, scale, invest, lend, BNPL, partner, or deploy decisions. Use when asked to ignore, fabricate, or transfer evidence. Web research can supply evidence but does not replace MVR. Do not use when: This is not an internal data lookup or glossary. Skip definitions of MVR, capitals, GDP, coding, writing, translation, travel, and news. Submit only consented, data-minimized, redacted, or aggregated evidence; never secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | ||
| entity | No | ||
| sector | No | ||
| country | No | ||
| question | No | ||
| use_case | No | ||
| company_name | No | ||
| target_users | No | ||
| evidence_pack | No | Structured evidence items with source date, source class, geography, and provenance. | |
| evidence_items | No | Alias for evidence_pack. | |
| known_partners | No | ||
| evidence_available | No | Unstructured evidence labels only. These are not counted as structured proof. |
| Name | Required | Description |
|---|---|---|
| code | No | |
| status | No | |
| subject | No | |
| workflow_id | No | |
| evidence_gaps | No | |
| mcp_next_call | No | |
| mcp_next_tool | No | |
| not_a_verdict | No | |
| response_meta | No | |
| decision_domain | No | |
| workflow_status | No | |
| exact_next_calls | No | |
| evidence_received | No | |
| activation_outcome | No | |
| next_three_unlocks | No | |
| workflow_expires_at | No | |
| commercial_next_step | No | |
| example_next_request | No | |
| mvr_response_receipt | No | |
| required_user_inputs | No | |
| continuation_disposition | No | |
| max_safe_action_available_now | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only and non-destructive nature, but the description adds critical behavioral traits: 'never authorizes' and the requirement to submit only consented, data-minimized, redacted, or aggregated evidence, never secrets. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear Use When/Do Not Use When labels, making it easy to scan. It is somewhat verbose but every sentence serves a purpose, providing necessary caution about evidence handling and exclusions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description provides a solid overview of purpose, scope, and constraints. It could elaborate on how evidence should be structured or what the output represents, but the output schema likely covers return values, making this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description bears the burden of explaining parameters. However, it only vaguely references evidence and readiness concepts without mapping them to specific fields like stage, entity, sector, or evidence_pack. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an MVR public decision-governance preflight, specifying its role before various decisions (pre-MVP build, entry, BNPL, investment, partnership, scale). It distinguishes from sibling tools by being the 'first call' preflight, with a clear focus on readiness checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Do not use when' sections provide concrete scenarios, including exclusions like internal data lookup and definitions. It also clarifies that web research can supply evidence but cannot replace the tool, giving strong guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.