MVR API - Minimum Viable Relationships

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

Annotations already declare readOnlyHint=true. Description adds that this is an advisory preflight scaffold only, not a full verdict, and mentions licensing/evidence requirements for the full route. 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, front-loaded with key phrase 'Abstention guardrail'. No wasted words, but lacks parameter descriptions which could be added without bloat.

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?

No output schema, 7 parameters with zero schema coverage. Description explains purpose and limitations but leaves parameter semantics and usage steps unaddressed. Incomplete for practical 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?

Schema description coverage is 0% and description provides no explanation for any of the 7 parameters. Only contextual hint 'relational readiness' but no details on fields like company_name, country, sector, 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 explicitly states verb 'decide whether to refuse, soften, or caveat' and resource 'confident recommendation' when 'relational readiness is unproven'. Clearly distinguishes from full engine verdicts by calling itself a 'preflight scaffold'.

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 for when to use ('when relational readiness is unproven') and contrasts with the typed REST route for full verdicts. Does not explicitly list named alternatives among siblings, but purpose implies usage boundary.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context that this is an advisory preflight scaffold requiring source-backed evidence and licensed access for full verdicts, which is consistent with annotations and provides extra behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with purpose, and efficiently conveys scope and limitations without any redundant information. Every sentence earns its place.

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, no output schema, and no parameter descriptions, the description lacks guidance on inputs and outputs. It adequately explains the tool's role and limitations but is incomplete for agent invocation without additional parameter or return value context.

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%, so the description does not explain any parameters. While parameter names are somewhat self-explanatory (e.g., company_name, sector), no additional meaning or constraints are provided, failing to compensate for the lack of schema documentation.

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 this is an accelerator screening preflight that separates claimed traction from evidence-ready applicants, with specific usage before cohort selection or demo-day routing. It also distinguishes itself from the full engine verdict route, making its purpose and scope unambiguous.

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 (before cohort selection or demo-day routing) and what it is not (a full engine verdict), directing to the REST route for full decisions. However, it does not explicitly exclude alternative tools or provide 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?

Annotations already declare readOnlyHint=true, and the description adds behavioral context: it is a 'wrapper returning advisory preflight scaffold only', and full engine verdicts require the REST route and licensed access. This goes beyond annotations by clarifying the limited scope and data source dependency.

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, front-loaded with purpose and context. It is concise and efficiently conveys key points, though it could be more structured with bullet points or clearer separation of scenarios.

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 9 parameters, no output schema, and very low schema description coverage, the description should provide more detail on input expectations, return format, or examples. It only mentions output is an 'advisory preflight scaffold', which is insufficient for proper 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?

Schema description coverage is only 11% (only one parameter 'recommendation_under_review' has a description). The tool description does not explain any parameters, so it fails to compensate for the low coverage. Agents would lack guidance on parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'drop-in agent guardrail' for market entry and related scenarios, and specifies it returns an 'advisory preflight scaffold'. However, it does not explicitly differentiate from similar sibling tools like mvr_preflight_market_entry or mvr_decision_check, though the context 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 lists applicable scenarios (market entry, MVP launch, etc.) and notes that full verdicts require a different route. This gives some context for when to use the tool, but it does not explicitly compare with siblings or state 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds 'Validate,' which is consistent but does not disclose additional behavioral traits beyond what annotations provide. The mention of 'public demo key' is a helpful detail but not a behavioral trait.

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 totaling 20 words. The first sentence states the core function, and the second provides usage guidance. Every word is necessary; no fluff or 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 tool is a simple auth check with no output schema, the description covers all essential aspects: what it validates, when to use it, and that it handles both specific keys and a demo key. It is complete for the tool's complexity and context.

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 fully documents both parameters. The description adds value for 'api_key' by stating it 'Defaults to the public sandbox key for evaluation,' which clarifies its optional behavior. For 'payload,' it simply restates 'Optional request body,' adding no new meaning. Overall, the description enhances the 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 the tool's purpose: 'Validate an MVR key or the public demo key.' It uses a specific verb ('validate') and identifies the resource ('MVR key or public demo key'). This distinguishes it from sibling tools like mvr_decision_check or mvr_abstention_check, which handle different aspects.

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 the tool: 'Use only when an agent needs to confirm access mode before calling other tools.' This provides clear guidance on the tool's role and implies it should not be used for other purposes.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, meaning the tool is a safe read operation. The description adds context about the output (safe/unsafe inferences) but does not disclose additional behavioral traits beyond what annotations imply.

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 a single, front-loaded sentence that efficiently states the tool's purpose and placement. It is concise with no waste, though it could benefit from slightly more detail on inputs/outputs.

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, output schema exists), the description is minimally adequate. It explains the core function and pipeline position but omits details about expected payload properties and return value format. Annotations and output schema partially compensate.

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 adds no information about parameters. Schema description coverage is 50% (only payload has a brief description), and the description does not explain the api_key or the structure of the payload object. It fails to compensate for the missing parameter details.

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 turns multiple context types into inferences, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like mvr_abstention_check or mvr_evidence_completeness, though the pipeline positioning ('after evidence capture, before verdict') provides some context.

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 gives explicit timing for use ('after evidence capture, before verdict'), providing clear context. However, it lacks exclusions or alternative tool mentions, so it does not fully guide when not to use this tool.

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?

Annotations already indicate readOnlyHint=true, so the description's characterization of producing a verdict is consistent with a read operation. The description adds a note about using it last, but does not disclose additional behavioral details like expected inputs or output format beyond what the annotations provide.

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 succinct sentences. The first states the core action, and the second provides usage timing. No wasted words, and the structure is effective.

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 complexity (2 parameters, nested object, output schema exists), the description is too brief. It does not explain what the payload should contain (additionalProperties implies flexibility but no guidance), nor does it describe the return value. The output schema exists but the agent could benefit from more context.

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 2 parameters with 50% coverage (only payload has a description). The description does not add meaning to the api_key parameter or elaborate on the payload structure beyond what is already in the schema. With low coverage, 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?

The description clearly states the tool produces the final MVR readiness verdict, with specific possible values, and implies it is a concluding step after evidence gathering. However, it does not explicitly differentiate from sibling tools that may also produce 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 says 'Use last, once evidence is gathered,' providing clear temporal context for when to invoke this tool. It does not mention alternatives or when not to use it, but the guidance is specific and 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'canonicalize' but doesn't elaborate on edge cases (e.g., not found) or return behavior, thus adding minimal 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?

Two sentences, no wasted words. Action verb front-loaded, resource list compact. Highly 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 2 parameters, output schema exists, and annotations cover safety, the description is minimal but adequate for a simple canonicalization tool. However, it lacks details on payload structure or behavior on ambiguity, leaving 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 schema covers 50% of parameters with descriptions (payload has description, api_key has none). The tool description does not explain any parameters, so it fails to add meaning beyond the schema 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 the tool canonicalizes entities like venture, market actor, etc., and distinguishes it as a first-step resolution tool among siblings. The verb 'canonicalize' is specific and the resource types are listed.

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 advises to use first when the user provides a name or market context, giving clear context for use. However, it lacks explicit when-not-to-use or alternative tool names, but the sibling tools are distinct enough.

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?

Annotations indicate read-only, idempotent, non-destructive behavior. Description adds that it lists missing proof, which is consistent and provides additional behavioral 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?

Single sentence with clear action and usage hint, front-loaded and efficient. 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?

Output schema exists, so return details are not needed. Description covers purpose, usage context, and behavior. Annotations handle safety. Sufficient for the tool's 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 description coverage is 50% (payload described). Tool description does not elaborate on api_key or payload structure, relying on schema. Does not add significant value beyond schema for 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?

Description states it checks evidence completeness and lists missing proof, with a distinct action verb and resource. It also mentions usage before decision_check, differentiating it from 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?

Explicitly advises 'Use before decision_check when evidence may be thin', providing clear context for when to use this tool versus 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: it returns an 'advisory preflight scaffold only' and does not provide full engine verdicts. It also mentions licensing limitations, which goes 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?

The description is three sentences, front-loaded with the core purpose, and every sentence adds value without redundancy. It is concise and well-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?

While the description covers high-level purpose and limitations, it fails to document any parameter semantics despite no schema descriptions. An output schema exists but is not referenced. Given the complexity (7 params, 5 required), more detail on parameter usage is needed for 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?

Schema description coverage is 0%, and the description provides no explanation of any parameter (company_name, country, sector, stage, target_users, evidence_available, api_key). The user is left to infer meaning from parameter names alone, which is insufficient for a tool with 7 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 explicitly states the tool's purpose: 'Return the next proof to request before the agent makes a stronger claim or go/no-go recommendation.' It distinguishes itself from the full engine verdicts (e.g., mvr_decision_check) by calling itself an 'advisory preflight scaffold.'

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 tells when to use the tool: 'before the agent makes a stronger claim or go/no-go recommendation.' It also clearly states when not to rely on it for full verdicts and points to the alternative: 'the typed REST /v1/decision-check route, source-backed evidence, and licensed access where applicable.'

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?

The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the tool returns a non-authorizing activation answer, missing proof, and production access routing, which goes beyond what annotations provide. It does not contradict 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 a single sentence that front-loads the primary use case ('Best first real call for a new MVR user or AI agent'). It is concise and avoids redundancy, though the sentence is somewhat dense with multiple clauses.

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, many sibling tools, and no parameter descriptions, the description is insufficient. It does not explain the significance of the many parameters, nor does it detail the output structure (despite an output schema existing). The description is too brief for the complexity of 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?

The input schema has 10 parameters with 0% description coverage. The tool description provides no elaboration on the meaning, format, or usage of any parameter. Since schema coverage is low, the description should compensate, but it fails to do so, leaving agents with no guidance on how to fill these 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 the tool's purpose as the best first call for new MVR users or AI agents, listing specific outputs like non-authorizing activation answer, missing proof, and next API/MCP calls. This strong verb and resource description, along with the context of being a starting point, effectively distinguishes 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?

The description explicitly states the tool is for new MVR users or AI agents as a first call, implying its primary use case. It also mentions that no private key is required, providing context on when to use it. However, it does not explicitly exclude other scenarios or mention alternatives among the many sibling 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?

The description adds behavioral context beyond the annotations: for the 'dev' split it returns public URLs, for 'private_test' it returns boundary metadata only. This aligns with the readOnlyHint and idempotentHint annotations, adding valuable detail without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the core purpose and immediately following with usage guidance. No redundant or unnecessary 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 the tool's simplicity (one optional parameter, no output schema, clear annotations), the description fully covers what the tool does, what each split returns, and how to use it. 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% and the parameter description in the schema already explains the behavior of each enum value. The tool description does not add further parameter meaning, so the baseline of 3 applies.

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 finds MVR-Bench dev scenarios and private-test boundaries, using a specific verb ('find') and resource. It also distinguishes from siblings by specifying it's for benchmark setup, not live market-entry advice, which contrasts with tools like mvr_preflight_market_entry.

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 says 'Use for benchmark setup, not for live market-entry advice,' providing clear when-to-use and when-not-to-use guidance. It does not name specific alternatives, but the negation implies alternatives exist for live advice.

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?

Annotations (readOnlyHint, destructiveHint, idempotentHint) already indicate safety. The description adds that data is public and enumerates return items, but does not disclose potential issues like invalid parameters or rate limits. 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?

A single, dense sentence that conveys the purpose and return data efficiently with 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?

For a simple read-only tool with good annotations, the description covers purpose and return data. However, it lacks parameter documentation and output format details, which would be needed if output schema were absent. Still, it is largely 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?

The schema has one parameter 'benchmark' with no description (0% coverage), and the tool description does not explain its meaning, allowed values, or effect on results. The description adds no value 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 verb 'Fetch', the resource 'MVR-Bench leaderboard', and the data returned (rows, scores, Reckless-GO Rate baselines). It is specific and sets it apart from sibling tools like mvr_get_benchmark_scenarios.

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 'for citation or benchmark reporting' but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on parameter usage or 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so description adds value by defining what the metric means. No contradictions, and the description provides relevant behavioral 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?

The description is two concise sentences, front-loaded with the purpose. 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?

For a simple explanatory tool with one optional parameter and annotations covering safety, the description provides the essential purpose and usage hint. However, it lacks information about the output format, which may be needed since there is no output 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?

The schema has one string parameter 'model' with no description, and schema description coverage is 0%. The tool description does not explain what 'model' is for, leaving ambiguity. A brief mention of its role would improve clarity.

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 explains the 'Reckless-GO Rate' metric and gives a concise definition. It distinguishes from sibling tools like mvr_abstention_check and mvr_decision_check, which perform other actions.

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 says 'Use when the user asks about the metric itself,' providing clear context. Does not specify when not to use, but given sibling list, the guidance is sufficient.

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?

Annotations already indicate read-only and idempotent. The description adds that it returns only an 'advisory preflight scaffold' and that full verdicts require the REST route with evidence and licensing. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second clarifies limitations. No redundant information. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing details about what the 'advisory preflight scaffold' contains or how parameters affect the output. No output schema exists, so the description should describe the return value. Required parameters (5) are not explained.

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 the description provides no explanation for any of the 8 parameters (e.g., company_name, country, sector). The agent receives no guidance on parameter meaning or format, which is inadequate.

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: a 'guardian-risk scan' for entities that can block execution (regulators, gatekeepers, etc.). It specifies it's a preflight wrapper, distinguishing it from sibling tools like the full decision-check route.

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 guides when to use this tool (advisory preflight) versus the full REST route for verdicts. However, it doesn't explicitly mention when not to use it or compare to specific siblings like mvr_decision_check.

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?

Annotations already declare readOnlyHint=true, and the description adds that it returns only an advisory preflight scaffold, not full verdicts. There is no contradiction, and the description provides additional behavioral 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?

The description is two sentences long. The first sentence is concise and directly states the purpose. The second sentence adds an important caveat. While efficient, the second sentence is slightly longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and low schema coverage, the description does not provide enough context. It lacks details on what the preflight scaffold includes, how parameters influence the check, or what the output looks like.

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 in the schema. The description does not explain any of the 8 parameters (e.g., company_name, country, sector, stage, target_users, api_key, known_partners, evidence_available). It fails to add meaning beyond the parameter names.

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 an 'Investor memo preflight' that flags missing relational proof before funding, diligence, valuation, or investment-committee recommendations. It distinguishes itself from sibling tools by noting it is a wrapper returning an advisory scaffold, while full verdicts require the typed REST route.

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 tells when to use the tool (before funding, diligence, valuation, or investment-committee recommendations) and when not to (for full engine verdicts, use the typed REST route). This provides clear guidance on 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?

Description adds useful context beyond annotations: it clarifies the tool returns an advisory scaffold, requires licensed access for full verdicts, and does not provide source-backed evidence. No contradictions with readOnlyHint annotation.

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, front-loaded with purpose and closed with limitations. No extraneous 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 the complexity (8 parameters, no output schema, many siblings), the description fails to map outputs to parameters or explain input semantics. Agents lack enough information to correctly populate fields like 'known_partners' or 'evidence_available'.

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 provides no explanation for any of the 8 parameters (0% schema coverage). The tool's input logic (e.g., what 'stage', 'sector', 'target_users' mean) is entirely undocumented, forcing the agent to guess.

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 it builds a market-permission memo summarizing safe claims, unsafe claims, etc., and distinguishes itself from siblings by noting it is an advisory preflight scaffold, not a full engine 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?

Description explains this tool is for advisory preflight memos only, and that full verdicts require a different route (/v1/decision-check). However, it does not explicitly name alternative tools or list 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?

Annotations already declare read-only, safe, idempotent. Description adds that it returns only an 'advisory preflight scaffold' and mentions dependence on licensed access, adding valuable 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?

Two sentences, front-loaded with purpose, no extraneous 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?

Explains tool's limitations and usage context well, but lacks parameter descriptions and does not specify output format beyond 'advisory preflight scaffold'.

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 description provides no details on individual parameters (company_name, country, sector, etc.). With 8 parameters and 6 required, 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?

Clearly states verb 'readiness check' and specific resource 'local partner'. Distinguishes from siblings by focusing on partner legitimacy and noting it's a preflight wrapper.

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 ('when question is whether a partner is legitimate') and when not (full engine verdicts require other routes). Provides alternative for full decision.

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?

Annotations already declare readOnlyHint=true, and the description adds that it returns only an advisory scaffold, not a full verdict, and mentions the need for licensed access for the full route. This enriches understanding 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?

The description consists of two concise sentences, front-loaded with the core purpose. There is no wasted text; every sentence serves a clear informational role.

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 8 parameters, no output schema, and many siblings, the description is too sparse. It fails to describe the output format, parameter details, or prerequisites (e.g., api_key usage). The advisory scaffold is not elaborated.

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 8 parameters (including required ones like company_name, country, sector, stage, target_users). The parameter names are somewhat self-explanatory, but the description adds no semantic value.

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 market-entry guardrail for launch or expansion advice, specifying it returns an advisory preflight scaffold. It distinguishes itself from the full engine verdicts, making the purpose unambiguous.

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?

It explicitly states when to use ('before recommending entry into an African or high-context market') and notes that full verdicts require the REST route and licensed access. However, it does not name specific sibling tools as 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?

Annotations already mark the tool as readOnly and non-destructive. The description adds context that it returns only an 'advisory preflight scaffold' and not full verdicts, reinforcing its limited scope and the need for other routes. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the purpose and conditions, then clarify limitations. Every sentence adds value with no redundancy or fluff.

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?

Despite good purpose and usage clarity, the tool has 7 un-documented parameters and no output schema. The description fails to cover parameter semantics or return value structure, making it incomplete for effective 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?

Schema has 7 parameters with 0% description coverage. The description does not mention any parameter details, leaving the agent without guidance on what each parameter means or how to use them. This is a critical 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 an 'MVP-advice guardrail' and specifies when to use it (when trust, permission, embeddedness, or guardian proof is untested). It distinguishes itself from full engine verdicts, making the purpose specific and actionable.

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 advises to 'Use before telling a founder to build' under specific conditions and contrasts with the full verdict route, providing clear when-to-use and when-not-to-use guidance with alternative named.

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?

Annotations already declare readOnlyHint=true, and the description adds that the tool 'returns instructions' and that private scoring stays server-side, aligning with read-only behavior. It clarifies authorization needs for private leaderboard, which 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?

The description is only two sentences with no wasted words. However, it is too brief given the tool's complexity, sacrificing necessary detail for conciseness.

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 4 parameters, no output schema, and many siblings, the description leaves major gaps. It does not explain how to use predictions, how to handle authorization, or what the returned instructions contain.

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 four parameters (model, run_name, predictions, contact_email). The agent gets no guidance on parameter meaning or formats.

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 'Prepare an MVR-Bench run submission' which clearly identifies the action and resource. It mentions returning instructions, but does not explicitly differentiate from siblings like mvr_preflight_mvp or mvr_get_benchmark_scenarios. The purpose is clear but could be more specific.

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 implies usage for submitting a benchmark run and notes that private leaderboard scoring requires authorization. However, it does not provide when-not-to-use guidance or mention alternatives among the 18 sibling tools.

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