build_vendor_evidence_package
Read-onlyIdempotent
Purchase a classified, source-backed vendor regulatory evidence package.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_token | Yes |
Vendor Regulatory Evidence
TDQS
C2.2/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the readOnlyHint annotation: 'Purchase' strongly implies a state-changing, potentially paid transaction, while readOnlyHint declares the operation has no side effects. This is a serious annotation contradiction that could mislead an agent about cost, reversibility, and safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action, containing no filler. However, it is under-specified rather than deliberately structured, so its brevity is a result of minimalism rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, a single undocumented parameter, and no explanation of cost, delivery, return value, or side effects, the definition is far from complete. The unresolved conflict between 'Purchase' and readOnlyHint further prevents an agent from safely understanding what will happen.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions vendor_token, its meaning, format, how to obtain it, or its role in the purchase. The agent is left with only the parameter name and type, so the description adds no useful parameter-level information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('Purchase') and a specific resource ('classified, source-backed vendor regulatory evidence package'), so the core purpose is identifiable. However, it does not explicitly distinguish this from sibling tools like get_vendor_regulatory_records or resolve_vendor, and the name says 'build' while the description says 'purchase'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling tools, nor any mention of prerequisites such as needing a vendor token or when an evidence package is appropriate. An agent would have to infer usage entirely from the tool name and the minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
B3/5.0
Disambiguation3/5
build_vendor_evidence_package and get_vendor_regulatory_records both result in purchasing regulatory evidence, with only packaging and record type distinguishing them, which could lead to misselection. resolve_vendor is clearly distinct as a prerequisite, but the two purchase tools still overlap.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: build_vendor_evidence_package, get_vendor_regulatory_records, resolve_vendor. The verbs and nouns are predictable and clearly domain-specific.
Tool Count4/5
Three tools is on the low side but sufficient for a focused resolve-then-purchase workflow. The count is reasonable and not excessive, though a few more operations could round out the offering.
Completeness3/5
The set covers resolving a vendor and purchasing two types of evidence, but lacks any way to retrieve previously purchased packages, check purchase status, or list available evidence types. These are notable gaps for a vendor evidence service.