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.3/5 across 7 of 7 tools scored.
Each tool has a distinct purpose with explicit 'use when' and 'do not use when' instructions, preventing overlap. For example, mvr_first_call is a preflight check, mvr_entity_resolve canonicalizes subjects, and mvr_decision_check routes to scoring.
All tools follow a consistent pattern: 'mvr_' prefix plus a descriptive snake_case name (e.g., mvr_entity_resolve, mvr_decision_check). The naming is uniform and predictable.
Seven tools is well-scoped for the domain of African market readiness. Each tool corresponds to a logical step in the workflow, and the count is neither too few nor too many for the stated purpose.
The tool set covers the full workflow from initial preflight (first_call) through entity resolution, evidence checking, context compilation, decision routing, and commercial submission. No obvious gaps are present for the public-facing API.
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 | |
| formal_proof | No | |
| response_meta | No | |
| safe_inferences | No | |
| unsafe_inferences | No | |
| mvr_response_receipt | No | |
| verification_required | No | |
| sentiment_trust_signal | No | |
| informal_operating_signal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint and non-destructive; the description adds context by clarifying it does not authorize action and mandates submitting only consented, data-minimized, redacted or aggregated evidence, and never raw confidential data. This discloses data-handling boundaries beyond annotation hints.
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 four sentences and front-loaded with the core purpose in the first sentence. It uses explicit 'Use when' and 'Do not use when' markers, which is structured but slightly verbose.
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 nested schema and output schema, the description sufficiently covers what the tool does, when to use it, when not to, and evidence-handling constraints. It also references 'before a verdict,' linking it to the decision workflow, making it contextually complete.
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 has 100% description coverage, so parameter semantics are largely handled by schema. The description adds a critical constraint on the evidence_pack parameter—'Submit only consented, data-minimized, redacted or aggregated evidence'—and positions usage after evidence capture.
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 'compile' and identifies the resource as 'evidence context,' explicitly stating it separates safe from unsafe inferences. It also distinguishes from siblings by framing it as 'after evidence capture' and noting it 'does not authorize action,' differentiating it from the decision_check tool.
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 clear use conditions: 'Use when evidence is mixed and the agent needs safe claims versus unsafe claims before a verdict.' It also gives a negative condition: 'Do not use as a go/no-go decision,' implying the mvr_decision_check sibling for that purpose.
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 | |
| evidence_gaps | No | |
| not_a_verdict | No | |
| response_meta | No | |
| recommendation | No | |
| safe_next_action | No | |
| verification_basis | No | |
| mvr_response_receipt | No | |
| sandbox_evaluation_scope | No | |
| live_mvr_scoring_executed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by stating the tool does not compute market, pilot, or scale readiness and imposes consent/minimization constraints on evidence submitted. No contradiction with annotations; the added context about abstention and data handling improves transparency.
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 front-loaded with the core purpose but becomes repetitive: the 'Use when' section restates the opening sentence, and 'Do not use when' duplicates the non-compute disclaimer. It would be more concise if these sections added new information instead of echoing the prior sentences.
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 complex nested input schema and available annotations, the description adequately covers purpose, usage boundaries, and data handling rules. Output behavior is presumably covered by the output schema, so the description need not explain return values. It is complete enough for an agent to select and invoke the tool correctly.
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 100%, so the baseline is 3. The description goes beyond schema by explaining that evidence packs must be consented, data-minimized, redacted or aggregated, and never contain secrets or personal identifiers, adding semantic guidance for the evidence-related fields.
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 routes structurally complete evidence packs toward licensed MVR scoring or abstains on missing proof. It uses specific verbs ('route', 'abstain') and distinguishes itself from computing market, pilot, or scale readiness, separating it from sibling tools.
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 tell the agent to use it after evidence completeness for routing decisions, and explicitly forbid using it as readiness, pilot, credit, legal, regulatory, or scale authorization. This provides clear context and exclusions 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 | |
| response_meta | No | |
| canonical_entity | No | |
| mvr_response_receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by stating never to submit secrets, personal identifiers, raw private interviews, or confidential evidence, and it clarifies the sequencing (resolve before evidence assessment). This goes beyond the annotations without repeating them.
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 relatively short but has a structural redundancy: 'Use when' appears twice, and the first sentence already conveys the primary condition while the second repeats the trigger with more specificity. While each part adds some information, the awkward repetition prevents a higher score for clarity and structure.
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 complex nested payload, existing output schema, and annotations, the description provides strong contextual guidance: it covers purpose, trigger, exclusions, privacy boundaries, and sequencing. It does not provide an example payload or explain how to handle ambiguous entities in different scenarios, but overall it is sufficiently complete for an agent to decide when and how to invoke the tool.
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 100%, giving a baseline of 3. The description adds meaning by explaining that the input can be 'a startup, venture, programme, company, partner, or market actor' and that bare sector or country names can be given, which helps the agent map ambiguous free-text queries to the payload fields. It also emphasizes resolving 'subject and target geography,' reinforcing the role of market_scope and country fields beyond their schema definitions.
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 resolves a startup, venture, programme, company, partner, or market actor to a country, sector, and archetype before relational-readiness evidence is assessed. It uses a specific verb (resolve) plus the resource (entity and market), and distinguishes itself from siblings by mentioning the sequencing after mvr_first_call and exclusion of readiness verdicts.
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 explicitly states when to use ('immediately after mvr_first_call' when the user gives a company, venture, sector, country, or ambiguous market actor name) and when not to use ('do not use as a readiness verdict or for unrelated entity lookup'). It names the predecessor sibling (mvr_first_call) but does not explicitly name alternatives for the 'do not use' scenarios, so it stops short of a 5.
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 | |
| evidence_gaps | No | |
| response_meta | No | |
| evidence_count | No | |
| safe_next_action | No | |
| verification_basis | No | |
| mvr_response_receipt | No | |
| stakeholder_coverage | No | |
| verified_evidence_count | No | |
| verified_source_families | No | |
| unverified_evidence_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses significant behavioral expectations: 'Submit only consented, data-minimized, redacted or aggregated evidence; never raw private interviews, secrets, credentials, or personal identifiers.' It also adds the boundary 'Do not treat completeness as authorization,' which is not implied by the 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 structured with 'Use when' and 'Do not use when' sections, making it scannable. However, it repeats 'Use after entity resolution' twice, and the opening sentence already covers the same ground as the 'Use when' clause, introducing minor 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?
Given the schema is rich with descriptions and an output schema exists, the description sufficiently covers timing, data-handling constraints, and exclusions. It fully clarifies the tool's role in the pipeline without needing to explain return values, which the output schema handles.
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?
With 100% schema description coverage, the schema already documents all parameters, including nested evidence objects and alias fields. The description does not add parameter-level detail, so it remains at the baseline without compensating beyond the schema.
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 'check[s] verification status, source-family diversity, stakeholder coverage, and missing proof,' which is a specific verb+resource. It also distinguishes itself by positioning usage 'after entity resolution and before any readiness claim,' separating it from siblings like mvr_entity_resolve and mvr_decision_check.
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 explicitly states when to use ('Use after entity resolution and before any verdict when evidence may be incomplete or one-sided') and when not to use ('Do not treat completeness as readiness or authorization'). This provides clear contextual boundaries and alternatives.
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 | ||
| known_partners | No | ||
| evidence_available | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| subject | No | |
| evidence_gaps | No | |
| mcp_next_tool | No | |
| not_a_verdict | No | |
| response_meta | No | |
| decision_domain | No | |
| exact_next_calls | No | |
| activation_outcome | No | |
| next_three_unlocks | No | |
| commercial_next_step | No | |
| example_next_request | No | |
| mvr_response_receipt | No | |
| max_safe_action_available_now | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses that the tool 'never authorizes' and imposes strict evidence submission rules: 'Submit only consented, data-minimized, redacted, or aggregated evidence; never secrets.' This adds useful behavioral context not captured by 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 repetitive, listing decision types twice ('pre-MVP build, entry, BNPL, investment, partnership, or scale' and 'enter, launch, scale, invest, lend, BNPL, partner, or deploy'). It also includes tangential exclusions (skip definitions of MVR, capitals, GDP, coding, writing, translation, travel, news), which muddy the focus. It is not poorly written but could be tightened.
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 has 10 parameters, no schema coverage, and sparse annotations, the description is insufficient for an agent to construct a valid invocation. It lacks explicit guidance on what each parameter means and doesn't clearly differentiate from sibling tools like mvr_context_compile or mvr_decision_check beyond the 'first_call' naming.
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?
With 0% schema description coverage and 10 parameters, the description provides no parameter-level guidance. It mentions that the tool 'Checks market trust, permission, embeddedness, stakeholder readiness, evidence gaps' but does not explain how to populate fields like stage, entity, sector, or question. The generic evidence-submission advice does not compensate for the lack of parameter explanation.
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 it is a 'relational-readiness preflight' used before AI recommends decisions like pre-MVP build, entry, BNPL, investment, partnership, or scale. It also explicitly says 'never authorizes', which distinguishes this tool as a non-decision-making preflight from decision-authorizing siblings.
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 includes explicit 'Use when' and 'Do not use when' sections, listing specific decision types and exclusions such as internal data lookup or definitions. It also warns that web research can supply evidence but does not replace MVR, providing clear context on when this tool is appropriate.
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.