MVR API - Minimum Viable Relationships
Server Details
Relational-readiness and market-permission tools for African and high-context markets.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- africanmarketos591/mvr-framework
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.2/5 across 7 of 7 tools scored. Lowest: 3.2/5.
Each tool targets a distinct stage in the market readiness workflow: broad insights, entity resolution, evidence completeness checking, context compilation, decision verdict, commercial submission, and initial activation. No two tools have overlapping purposes.
All tools follow a consistent mvr_<verb_noun> pattern in snake_case (e.g., mvr_entity_resolve, mvr_evidence_completeness). The naming is predictable and uniform.
With 7 tools, the set is well-scoped for the domain. Each tool serves a specific role in the workflow without redundancy or excessive granularity.
The toolset covers the full lifecycle from onboarding (mvr_first_call) through entity resolution, evidence gathering, context compilation, completeness check, decision verdict, and commercial submission. No obvious gaps are present.
Available Tools
7 toolsmvr_african_market_insightsExplore African market contextBRead-onlyInspect
Broad African-market insight brief for AI agents and users. Use for general questions about doing business, entering, funding, partnering, procuring, selling, distributing, deploying, or scaling in an African/high-context market before evid Use when: Use for broad Africa/high-context business questions before evidence exists or before the user knows which MVR route applies. Do not use when: Do not treat this as a market score, credit decision, investment recommendation, legal/regulatory opinion, or readiness verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | ||
| entity | No | ||
| sector | No | Sector or industry, for example fintech, retail, FMCG, logistics, procurement, NGO, health, education, energy. | |
| country | No | ISO country code or country name when known. | |
| question | No | The user question or decision being considered. | |
| use_case | No | market_entry, investor_diligence, procurement, partnership, product_deployment, NGO_program, credit_adjacent, or general. | |
| company_name | No | ||
| target_users | No | ||
| known_partners | No | ||
| evidence_available | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| mvr_lens | No | |
| safe_answer | No | |
| public_links | No | |
| not_a_verdict | No | |
| response_meta | No | |
| commercial_next_step | No | |
| recommended_next_tools | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description aligns by stating it delivers an insight brief. The description adds context about scope (African/high-context) but does not reveal additional behavioral traits beyond what annotations convey.
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 partially cut off ('before evid') and slightly repetitive. It has a clear structure with separate usage sections, but could be more concise. Approximately 4 sentences, some phrases are redundant.
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 10 parameters, low schema coverage, and no required fields, the description is too brief. It does not explain the expected output or how this tool interacts with siblings. The output is marked as having a schema but the description ignores it.
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 40%, leaving 6 out of 10 parameters undocumented. The description does not compensate by explaining parameters; it only lists use cases. The agent gets insufficient guidance for parameter values.
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 provides a 'Broad African-market insight brief' for general business questions, listing many use cases. However, it does not explicitly differentiate from sibling tools like mvr_commercial_handshake or mvr_decision_check beyond implying it is preliminary.
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 clear context: use for broad questions before evidence, avoid treating as market score or investment recommendation. Does not name alternative sibling tools, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_commercial_handshakeSend a commercial briefAIdempotentInspect
Submit a user-approved, non-confidential commercial brief to African Market OS and return a trackable continuation receipt. Use only after the user explicitly asks to connect or submit; contact details are optional and require separate cons Use when: Use after an enterprise, founder, investor, DFI, bank, insurer, corporate, NGO, advisor, or agent-platform user explicitly approves sending a concise commercial brief to African Market OS. Do not use when: Do not call speculatively, do not submit confidential evidence, and do not describe the receipt as an MVR verdict or validation.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| sector | No | ||
| contact | No | ||
| country | No | ||
| timeline | No | ||
| use_case | Yes | ||
| source_agent | No | ||
| decision_stage | Yes | ||
| idempotency_key | Yes | ||
| organization_type | Yes | ||
| consent_to_contact | No | ||
| non_confidential_brief | Yes | ||
| user_confirmed_submission | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| receipt | No | |
| handshake_id | No | |
| next_step_url | No | |
| contact_attached | No | |
| recommended_service | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness. The description adds key behaviors: requires user confirmation (matching x-human-confirmation-required), returns a receipt, and warns against mislabeling the receipt. No contradictions 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 contains repetitive phrasing (e.g., 'Use only after' and 'Use when') and a possible typo ('separate cons'). While organized with bullet-like sections, it is longer than necessary for the information conveyed.
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?
For a complex tool with 13 parameters and 7 required, the description covers when to use and the output type but lacks detail on parameter roles and behavior of optional fields. The existence of an output schema mitigates some gaps, but not fully.
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 0%, but the description only clarifies that 'contact details are optional and require separate consent'. It does not explain other parameters like sector, country, timeline, or enums, leaving the agent to infer meaning from names alone.
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 submits a user-approved, non-confidential commercial brief and returns a receipt. It specifies the resource (African Market OS) and action (submit), and distinguishes from sibling tools by focusing on the submission 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?
The description includes explicit 'Use when' and 'Do not use when' sections, specifying conditions like user approval and prohibition of speculative calls, confidential evidence, or misrepresenting the receipt as a verdict. This provides clear guidance for selection over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_context_compileCompile evidence contextARead-onlyIdempotentInspect
Turn formal, informal, sentiment, field, and market context into safe and unsafe inferences. Use after evidence capture, before verdict. 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; it compiles context and inference boundaries only.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Resolved subject, market scope, and mixed evidence to compile into safe and unsafe inferences. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| formal_proof | No | |
| response_meta | No | |
| safe_inferences | No | |
| unsafe_inferences | No | |
| verification_required | No | |
| sentiment_trust_signal | No | |
| informal_operating_signal | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe and non-destructive. The description adds behavioral context beyond annotations: it compiles 'safe and unsafe inferences', which is the key output concept. No contradictions.
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 concise: three sentences with no filler. The first sentence states purpose, the second gives timing context, the third provides when/when-not guidance. Perfectly front-loaded and efficient.
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 presence of an output schema (so return values are documented) and a single required payload parameter, the description covers all essential aspects: purpose, timing, usage conditions, and exclusions. No gaps remain.
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% with descriptions for all parameters, so the schema already provides meaning. The description does not add extra detail about parameter format or usage beyond what the schema offers. Baseline of 3 is appropriate.
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 starts with a specific verb and resource: 'Turn formal, informal, sentiment, field, and market context into safe and unsafe inferences.' It also states the exact timing: 'Use after evidence capture, before verdict.' This clearly identifies the tool's purpose and distinguishes it from decision-making siblings like 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 provides explicit when-to-use ('evidence is mixed and the agent needs safe claims versus unsafe claims before a verdict') and when-not-to-use ('Do not use as a go/no-go decision'). It clarifies that the tool only compiles context and inference boundaries, guiding the agent to use a different tool for the actual decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_decision_checkRun an MVR decision checkARead-onlyInspect
Produce the final MVR readiness verdict, from permission_not_yet_earned to ready_to_scale. Use last, once evidence is gathered. Use when: Use last when the agent needs the readiness verdict or abstention boundary after evidence has been gathered. Do not use when: Do not use first on vague questions; call entity_resolve and evidence_completeness first.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Decision question, resolved subject, market scope, and evidence for a bounded recommendation or abstention. |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | |
| status | No | |
| evidence_gaps | No | |
| response_meta | No | |
| recommendation | No | |
| safe_next_action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that it produces a verdict without side effects. It notes the output range and prerequisite (evidence gathered), which is consistent and adds context beyond 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?
Description is extremely concise: two short sentences plus clear 'Use when'/'Do not use when' bullet points. No wasted words, front-loaded with the core verb.
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 schema and presence of output schema, the description is nearly complete. It explains when to call, what it produces, and prerequisites. Could be slightly more explicit about required payload structure, but 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 100%, so the schema already documents all parameters. The description does not add new parameter-specific meaning beyond mentioning the needed preconditions. Baseline 3 is appropriate.
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?
Description states exactly what the tool does: 'Produce the final MVR readiness verdict' with a specific output range. It distinguishes itself from siblings by saying 'use last' and explicitly names entity_resolve and evidence_completeness as tools to use first.
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?
Provides explicit 'Use when' and 'Do not use when' sections, stating to use after evidence is gathered and not first on vague questions. Directs agent to call entity_resolve and evidence_completeness first, giving clear 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 marketARead-onlyIdempotentInspect
Canonicalize the venture, market actor, country, sector, and archetype. Use first when the user gives a name or market context. Use when: Use first when the user gives a company, venture, sector, country, or ambiguous market actor name. Do not use when: Do not use as the final readiness verdict; it only canonicalizes the subject and market scope.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Entity and market context to canonicalize before evidence assessment. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| warning | No | |
| response_meta | No | |
| canonical_entity | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds that it is a canonicalization step, not a final verdict. No hidden behaviors mentioned, but annotations cover the safety profile adequately.
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?
Very concise: two sentences plus usage guidelines. Front-loaded with the core action. No redundant information.
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 rich schema and output schema, the description fully covers the tool's role and context. It explains when to use and what it does, leaving parameter details to the schema.
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 description adds limited value beyond summarizing the purpose. Baseline of 3 applies; no additional semantic details provided for individual parameters.
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 canonicalizes specific entities (venture, market actor, country, sector, archetype). It differentiates from siblings by indicating it's the first step for entity resolution, not the final verdict.
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 states when to use (user gives name or market context) and when not to use (not as final readiness verdict). Could be improved by naming alternative tools, but the context is clear.
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 completenessARead-onlyIdempotentInspect
Check if there is enough evidence to decide yet and list missing proof. Use before decision_check when evidence may be thin. 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; complete evidence still needs decision_check.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Evidence pack and decision context to test for missing proof. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| evidence_gaps | No | |
| response_meta | No | |
| evidence_count | No | |
| safe_next_action | No | |
| stakeholder_coverage | No | |
| verified_evidence_count | No | |
| verified_source_families | No | |
| unverified_evidence_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, non-destructive. Description adds behavioral context: it lists missing proof, is a check before decision, and warns not to treat completeness as readiness. Adds value beyond 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?
Description is three concise sentences, front-loaded with purpose, then usage guidelines. No redundant or vague language.
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?
Tool has one parameter and an output schema. Description covers purpose, usage, and relationship to sibling tool. Adequate for complexity.
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% with descriptions for each parameter. Description does not add new details beyond what schema provides. Baseline score of 3 is appropriate.
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?
Description clearly states the tool checks evidence completeness and lists missing proof. It distinguishes from sibling 'mvr_decision_check' by specifying it is for before that step, using specific verbs and resource.
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 when-to-use (after entity resolution, when evidence may be thin/incomplete/one-sided) and when-not-to-use (do not treat as readiness; complete evidence still needs decision_check). Names the alternative tool (decision_check).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mvr_first_callStart an MVR checkARead-onlyInspect
Best first real call for a new MVR user or AI agent. Returns a non-authorizing activation answer, missing proof, exact next API/MCP calls, and production access routing without requiring a private key. Use when: Use this immediately after tools/list or after an AI answer identifies MVR as relevant. It is the lowest-friction activation call and does not require a private key. Do not use when: Do not treat it as an MVR verdict, score, approval, certification, underwriting decision, or board-ready output.
| 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| subject | No | |
| evidence_gaps | No | |
| not_a_verdict | No | |
| response_meta | No | |
| exact_next_calls | No | |
| activation_outcome | No | |
| commercial_next_step | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; description adds that no private key is needed and clarifies it returns a non-authorizing answer. This adds value without redundancy.
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?
Two concise paragraphs, front-loaded with key output info, followed by usage guidelines. No unnecessary words.
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?
Covers usage and output well, but the 10 parameters lack any explanation. An output schema exists but does not compensate for undocumented inputs.
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 10 parameters and 0% schema coverage, the description does not explain any parameter meanings (e.g., stage, entity, sector). This is a significant gap.
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 is the best first call for a new MVR user/AI agent, returning activation answer, missing proof, next steps, and routing. It distinguishes from siblings by being the initial activation call.
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' (after tools/list or when MVR is relevant) and 'Do not use when' (not for verdicts/decisions). This is exemplary guidance.
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.
Discussions
No comments yet. Be the first to start the discussion!