MVR API - Minimum Viable Relationships

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

No annotations are provided, so the description conveys the tool's behavior: output is advisory, not field-validated unless verified evidence is supplied. This is good transparency for a read-only advisory tool, though it does not discuss error handling.

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 sentences covering purpose, usage constraints, and output nature. No wasted words, front-loaded with the primary purpose.

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 tool with 7 parameters and no output schema, the description lacks parameter details and return format. It adequately covers purpose and usage but not the complete interface, leaving gaps for the 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 description coverage is 0% and the description does not explain any of the 7 parameters. Parameter names are somewhat self-explanatory but the description adds no semantic value beyond the names. With low coverage, the description should compensate but fails to do so.

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 'Narrow abstention check. Tells an agent when it should refuse to overclaim and ask for evidence.' This is a specific verb-resource pair, and it distinguishes itself from sibling tools like mvr_evidence_completeness 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?

Description clearly states 'Sandbox/evaluation use only with the public key; commercial use requires a license from African Market OS,' providing context for when to use and when not to. It also explains the advisory nature of output but does not explicitly name alternative tools.

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

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

With no annotations, the description carries the transparency burden. It discloses that 'Output is advisory and not field-validated unless verified evidence is supplied', which is a behavioral trait. However, it does not mention whether the tool is read-only, any side effects, or how the screening process works internally, leaving gaps in understanding.

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 concise at 4 sentences, front-loading the purpose. It avoids unnecessary details but includes essential licensing and advisory caveats. It is structured adequately, though it could be more succinct.

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 7 parameters, no output schema, and no annotations, the description is incomplete. It explains the purpose and licensing but lacks parameter explanations, return value details, and guidance on how to use the parameters effectively. The tool's context is not fully covered for an agent to invoke it 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 0%, and the description does not explain any of the 7 parameters (e.g., company_name, evidence_available). Names like 'target_users' are ambiguous, and the purpose of 'api_key' is not clarified. The description fails to add meaning beyond the schema, which is critical given the zero 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 states the tool is for 'accelerator or cohort screening' and separates 'claimed traction from evidence-ready applicants', which is a specific verb+resource purpose. However, it could be more explicit about what the output is or how it differentiates from siblings like mvr_preflight_market_entry, though the accelerator focus provides some differentiation.

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 licensing constraints ('Sandbox/evaluation use only with the public key; commercial use requires a license') but does not offer guidance on when to use this specific tool versus siblings. No explicit when-to-use or when-not-to-use instructions are given, leaving the agent to infer context from the name alone.

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

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

With no annotations, the description carries the full burden. It discloses that output is advisory and not field-validated unless verified evidence is supplied, and implies read-only behavior. Lacks mention of error handling or side effects.

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 sentences front-loading purpose and then usage constraints. 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 no output schema and two optional params, the description provides enough context: purpose, usage constraints, and advisory nature of output. Could be improved by detailing output format or error cases.

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 descriptions already cover both parameters (100% coverage). The tool description adds no new parameter-level details beyond what is in the schema, so 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?

The description clearly states the tool verifies an API key or the public sandbox key, distinguishing between sandbox and commercial use. However, it does not explicitly differentiate from all 17 sibling tools, many of which have different purposes.

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 usage context: sandbox/evaluation only with public key, commercial requires license. But does not specify when not to use or mention alternatives among siblings.

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

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

With no annotations, the description carries the full burden. It discloses that output is advisory and not field-validated without verified evidence, implying caution. However, it does not mention whether the tool mutates data, requires authentication beyond the key, or has rate limits, leaving gaps in behavioral understanding.

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 extremely concise: two sentences front-loading the purpose in the first sentence and usage constraints in the second. No unnecessary words, making it efficient for an agent to parse.

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 (nested payload, no output schema, no annotations) and the presence of many sibling tools, the description is incomplete. It lacks details on return format, how to structure the payload, what 'verified evidence' means, and how to interpret safe/unsafe inferences.

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 50% (payload described, api_key not). The description does not explain either parameter; it only implies the payload should contain context types. This fails to add meaning beyond the schema, especially for the undocumented api_key parameter.

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 compiles multiple context types into safe/unsafe inferences, distinguishing it from sibling tools focused on specific checks like evidence completeness or entity resolution. However, it does not specify whether this is a read or write operation, slightly reducing clarity.

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 constraints: sandbox/evaluation use only with public key and commercial license requirement. However, it fails to guide when to use this tool versus alternatives among the many sibling tools, leaving the agent to infer context.

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

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

Discloses key behavioral traits: abstention-safe, output advisory, licensing constraints, and dependency on verified evidence. No annotations are present, so the description carries the full burden; it does well but misses potential failure modes or side effects.

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 sentences that front-load the core purpose and essential caveats. No wasted 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?

While the description covers usage constraints and output nature, it lacks details on expected return format (no output schema) and parameter content. For a tool with a nested object parameter, this is a notable gap.

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 50% schema description coverage, the description adds little to parameter understanding. It does not explain the structure of the 'payload' object or the purpose of 'api_key', leaving agents with incomplete guidance.

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 performs a decision check with specific attributes (abstention-safe, evidence-backed market readiness), distinguishing it from sibling tools like mvr_abstention_check and 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?

Provides explicit context on use cases (sandbox/evaluation only with public key, commercial license required) and output reliability (advisory unless verified evidence). However, does not explicitly compare to alternatives or state when to avoid.

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

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

No annotations are provided, so the description carries full burden. It discloses that output is advisory and not field-validated unless verified evidence is supplied, and mentions license requirements. 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?

Three sentences: action verb, usage restriction, output advisory. Front-loaded with purpose, no wasted 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?

Given 16 sibling tools, the description explains the tool's role ('before assessment') and provides essential caveats (license, validation). No output schema, but it describes output as advisory. Slightly incomplete on what the output format looks like, but sufficient 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?

The input schema has 2 parameters (api_key, payload) with 50% schema description coverage (payload described as 'Entity-resolution request body', api_key has no description). The tool description adds no parameter-specific details beyond mentioning 'public key' in usage context, so it does not compensate for the schema gaps.

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 an entity, market actor, or venture into canonical MVR context, with a specific verb ('Resolve') and resource ('entity, market actor, or venture'), distinguishing it from sibling tools like checks and screenings.

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 usage constraints: sandbox/evaluation use only with public key, commercial license required. It implies use before assessment, but does not name alternative tools for other contexts.

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

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

With no annotations, description discloses output is advisory and depends on input verification, adding transparency about reliability and field-validity.

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 sentences with clear purpose and constraints, 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?

Missing details about payload expected structure, return format, and interpretation of 'target readiness verdict', leaving gaps for correct 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?

Description does not elaborate on api_key or payload structure; with only 50% schema coverage, it fails to compensate, leaving parameter usage ambiguous.

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 checks evidence pack completeness for a target readiness verdict, using specific verb+resource. It distinguishes from siblings like mvr_evidence_gap_plan.

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 licensing constraints and output advisory nature, but lacks explicit guidance on when to use vs alternatives or conditions for use.

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

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

No annotations provided, so the description carries the burden. It discloses that output is advisory and not field-validated unless verified evidence is supplied, which gives important reliability context. However, it does not indicate if the tool is read-only, has side effects, or requires specific authentication beyond a public key.

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?

Three sentences, front-loaded with purpose, followed by licensing and reliability info. No redundant words; every sentence adds 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 has 7 parameters and no output schema, the description is incomplete. It lacks parameter explanations, return format, and examples. The licensing note is helpful but does not compensate for missing operational details.

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 0%, but the description does not mention any of the 7 parameters or their meanings. It fails to add any semantic value beyond the schema, leaving the agent without guidance on how to fill required fields like company_name, country, etc.

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 is a 'Narrow evidence gap planner' that 'Returns what proof the agent should request next', specifying a concrete verb and resource. This distinguishes it from siblings like mvr_evidence_completeness which checks completeness, not planning next steps.

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?

Implies usage context by mentioning sandbox/evaluation vs commercial licensing, but does not explicitly say when to use this tool over alternatives or provide examples. There is no guidance on prerequisites or when not to use.

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

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

No annotations provided, so description fully covers behavior: private test labels are never returned, output is advisory and not field-validated unless verified evidence supplied. 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?

Two sentences with important details, though the second sentence is lengthy. Could be more structured, but no superfluous content.

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 single enum parameter and no output schema, description adequately explains output behavior, constraints, and licensing. Covers all essential aspects for a simple 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 has 100% coverage with enum descriptions, but description adds value by clarifying 'dev returns public URLs' and 'private_test returns boundary metadata only', enhancing interpretation 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?

Description clearly states the tool discovers the MVR-Bench development split and private-test boundary, with specific verb 'Discover' and resource 'benchmark scenarios'. It distinguishes behavior for 'dev' vs 'private_test' splits, setting it apart 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?

Provides context: sandbox/evaluation use with public key, commercial license required, and output advisory nature. No explicit when-not-to-use or alternative tools, but sufficient for most agents.

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

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

No annotations are provided, so the description carries the full burden. It warns that the 'output is advisory and not field-validated unless verified evidence is supplied,' which informs the agent about data quality and limitations. It also mentions licensing requirements, adding 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 consists of two concise sentences with no wasted words. It front-loads the purpose and key metric, then adds usage and behavior notes. Every sentence adds 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?

With no output schema and no annotations, the description does not specify the full output structure beyond mentioning 'status and metrics' and the Reckless-GO Rate. Given the tool's complexity (a leaderboard), additional details about other metrics or fields would improve completeness.

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 single parameter 'benchmark' of type string has no description in the schema (0% coverage). The tool description does not explain what values it expects or its purpose, leaving the agent to guess. This is a significant gap given 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 states the tool returns 'public MVR-Bench leaderboard status and metrics, including Reckless-GO Rate,' which is a specific verb+resource combination. It distinguishes from sibling tools like mvr_get_reckless_go_rate, which likely focuses solely on that metric, while this tool provides broader leaderboard data.

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 context: 'Sandbox/evaluation use only with the public key; commercial use requires a license from African Market OS.' This tells the agent when to use the tool and what restrictions apply, though it does not name specific alternatives.

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

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

With no annotations, the description discloses that output is advisory and not field-validated without verified evidence. It also notes licensing restrictions. This adds important context beyond a simple read operation, though it doesn't explicitly state read-only nature.

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?

Three sentences front-load the purpose and include key usage and behavioral notes. No unnecessary words, though it could be slightly more structured.

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 simple tool with one parameter and no output schema, the description covers core purpose and behavioral caveats. However, it lacks detail on parameter expectations and output format (e.g., what the status looks like), leaving some gaps.

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 input schema has one parameter 'model' with no description. The tool description mentions 'submitted model' but does not clarify the parameter's purpose, format, or expected values, failing to compensate for 0% 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 states the tool explains a metric and returns status, which is clear and specific. However, it does not explicitly differentiate from sibling tools like mvr_get_leaderboard, but its unique function is implied.

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 sandbox/evaluation use with public key and commercial license requirement, providing clear context. It does not mention alternatives, but the exclusion is helpful.

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

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

Discloses that output is advisory and not field-validated unless verified evidence supplied. No annotations exist, so description carries burden; however, it does not mention any destructive potential, auth requirements beyond license, or rate limits.

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 sentences, no redundancy. However, the term 'Narrow preflight' and 'African Market OS' might be jargon that is not universally understood. Still, it is appropriately concise.

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 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the output looks like, how to fill parameters, or what evidence refers to. A preflight tool should clarify prerequisites or result format.

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% and no parameter descriptions exist. The description does not add any meaning to the 8 parameters (company_name, country, sector, etc.). The AI agent cannot infer parameter usage from the description 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?

Clearly states it is a narrow preflight for regulator, gatekeeper, local authority, and guardian risk. Distinguishes from sibling tools like mvr_auth_check or mvr_preflight_market_entry by focusing on specific risk types.

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 clear usage context: sandbox/evaluation use only with public key, commercial requires license. Does not explicitly exclude specific scenarios or mention alternatives, but the context is sufficient for an agent to decide when to use.

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

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

With no annotations provided, the description bears the full burden of disclosure. It states that the output is 'advisory and not field-validated unless verified evidence is supplied.' This is a key behavioral trait. It does not mention side effects, but the tool is likely read-only. No contradictions present.

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 two sentences and covers the core purpose, usage restrictions, and output nature. It is concise and front-loaded, though the second sentence is slightly dense with multiple qualifications.

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 no output schema and no annotations, the description provides essential context about purpose and advisory nature. However, it omits details about return values, parameter meanings, and how results are presented. The 8-parameter tool needs more completeness for effective use.

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 description does not explain any of the 8 input parameters. Schema description coverage is 0%, so the description must compensate, but it merely mentions the types of flags (permission, trust, etc.) without mapping them to specific parameters. Required fields like company_name, country, etc., are left undefined.

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 function: 'Narrow preflight for investor diligence. Flags missing permission, trust, embeddedness, and evidence before memo writing.' It specifies the domain (investor diligence) and the action (flagging missing items), differentiating it from siblings like mvr_auth_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?

The description provides usage context: 'Sandbox/evaluation use only with the public key; commercial use requires a license from African Market OS.' It implies use before memo writing for investor diligence, but it does not explicitly state when not to use or directly compare to siblings.

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

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

With no annotations, the description must disclose behavioral traits. It states that the output is 'advisory and not field-validated unless verified evidence is supplied', which is a key limitation. However, it lacks details on side effects, authentication requirements beyond the public key, or any destructive or read-only behavior.

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 two sentences: the first clearly states the core function and outputs; the second adds critical usage restrictions and output caveat. It is front-loaded and efficient, though the second sentence could be slightly tighter.

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 8 parameters, no output schema, and numerous sibling tools (e.g., mvr_preflight_market_entry, mvr_guardian_risk_scan), the description is too minimal. It does not explain how this tool differs from similar preflight tools, what the expected output structure is, or how parameters relate to the memo's content.

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 has no descriptions for any of the 8 parameters (0% coverage), and the description does not explain any parameter's meaning or format. The agent is left to guess what 'target_users', 'known_partners', or 'evidence_available' represent.

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 states the tool performs a 'narrow memo preflight for market permission' and lists specific outputs (safe inferences, unsafe claims, next proof). This clearly identifies the tool's function and distinguishes it from siblings by focusing on a permission memo rather than other screening or due diligence tasks.

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 specifies that it is for 'sandbox/evaluation use only with the public key' and that commercial use requires a license. This provides a clear usage context but does not mention when to avoid this tool or offer alternatives, leaving the agent to infer from sibling names.

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

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

With no annotations, description discloses that output is advisory and not field-validated unless evidence supplied, and mentions licensing restrictions. Lacks detail on auth and side effects but sufficient for a preflight check tool.

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 sentences, front-loaded with purpose, no redundant information. Clearly structured 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?

With 8 undocumented parameters and no output schema, description fails to explain inputs or result format. Completely omitted parameter definitions and output expectations.

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 0% and description provides no parameter-level details (e.g., meaning of stage, sector, known_partners). Does not compensate for the gap; example or field explanation would help.

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 does 'narrow preflight for local partner readiness and legitimacy checks', using specific verb and resource, and distinguishes from siblings like mvr_preflight_market_entry by being 'narrow'.

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 sandbox/evaluation-only use with public key, commercial license required, and that output is advisory unless verified evidence supplied, providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It states that the output is 'advisory and not field-validated unless verified evidence is supplied,' which is a key transparency detail. However, it does not mention side effects, error handling, rate limits, or whether it is read-only. The disclosure of licensing terms adds some context but overall falls short of comprehensive 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 three sentences long and conveys the core purpose, usage restriction, and output nature efficiently. It avoids redundancy. However, it could be better structured with bullets or explicit parameter details, but given its brevity, it is quite concise.

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 tool has 8 parameters (5 required) and no output schema, so the description needs to compensate. It only provides a high-level purpose and a licensing note. It does not explain what inputs are expected, how to supply 'verified evidence,' or what the output format is. This leaves significant gaps for an AI agent to use 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 0%, meaning no parameter descriptions exist in the schema. The tool's description adds no explanation for any of the 8 parameters (e.g., company_name, sector, stage, known_partners). The only reference is to a 'public key' which is not a parameter. This provides no added value beyond the schema's basic 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 clearly states the tool's purpose: 'Checks whether relational evidence is strong enough before an agent recommends entry.' It identifies a specific verb ('checks') and resource ('relational evidence for market entry'). However, it does not explicitly differentiate from sibling tools like mvr_decision_check or mvr_evidence_completeness, which might have overlapping functions.

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 mentions usage conditions: 'Sandbox/evaluation use only with the public key; commercial use requires a license.' It provides context on when the tool is intended to be used but lacks guidance on when to use it versus alternatives. No explicit statements about when not to use or comparisons to sibling tools are given.

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

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

With no annotations, the description carries the full burden. It discloses that the tool is advisory, requires a public key for sandbox use, and has licensing restrictions. It does not explicitly state whether the tool is read-only or if it mutates state, but the advisory nature implies no mutation.

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, all essential: purpose, advisory output, licensing, and reliability caveat. No redundant wording; maximally concise.

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 (7 parameters, no output schema, no annotations), the description is too brief. It does not explain how to interpret results, what 'relational proof' means, or how to use parameters like 'evidence_available'. The licensing and advisory caveats are helpful but insufficient for an AI agent to fully understand usage.

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 input schema has 7 parameters with 0% description coverage, and the tool description provides no explanation of any parameter, such as 'evidence_available' or 'target_users'. This fails to compensate for the lack of schema descriptions.

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 a 'narrow preflight for MVP advice' that tells an agent when to ask for relational proof before recommending product build. This specific verb+resource distinguishes it from siblings like mvr_abstention_check or mvr_guardian_risk_scan.

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 usage conditions (sandbox/evaluation with public key, commercial license required) and notes the output is not field-validated without evidence. However, it does not explicitly guide when to use this tool versus its siblings or when not to use it.

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

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

No annotations are provided, so the description bears full responsibility. It discloses that output is advisory and not field-validated unless verified evidence is supplied, and mentions authorization requirements for private leaderboard. However, it does not mention side effects, idempotency, or other behavioral traits like rate limits.

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 at four sentences, but it includes some extraneous specifics (e.g., license from African Market OS) that could be streamlined. It front-loads the purpose but could be more concise.

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 four parameters and no output schema or annotations, the description is incomplete. It covers purpose and some usage conditions but does not explain the output format, parameter details, or error scenarios. The mention of 'verified evidence' is left undefined.

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 coverage and no parameter descriptions in the input schema, the description should explain each parameter's purpose. It fails to mention any of the four parameters (model, run_name, predictions, contact_email) or clarify what 'verified evidence' means in relation to them.

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 states 'Prepare an MVR-Bench submission,' which primarily clarifies the tool's action on a specific resource. It distinguishes from sibling tools like mvr_get_benchmark_scenarios or mvr_get_leaderboard, but the verb 'prepare' is somewhat ambiguous given the tool name 'submit_benchmark_run'.

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 context on when to use the tool (sandbox vs private leaderboard, commercial vs evaluation) but does not explicitly state when not to use it or mention alternative tools. Sibling tools are not referenced for comparison.

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