venture_foundry_get_reportRead one settled report using its job ID and secret bearer token. This tool cannot initiate payment.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| reportToken | Yes | Secret report token returned by prepare_checkout. Never disclose it outside the paying workflow. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds value by stating 'cannot initiate payment,' which directly addresses potential confusion with payment siblings, and highlights the 'secret bearer token' for security awareness.
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 the core action and parameters. No redundant wording; the second sentence adds a critical limitation without 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?
For a simple 2-parameter read tool with no output schema, the description covers what it does, the required inputs, and a key limitation. The workflow context (token from prepare_checkout) is provided in the schema for reportToken, rounding out the picture.
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% (only reportToken has a description). The description maps 'job ID' and 'secret bearer token' to the two parameters, giving semantic meaning to jobId and reinforcing the token's secrecy. This partially compensates for the missing jobId description in 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 'Read one settled report' with specific parameters (job ID and secret bearer token). It distinguishes itself from sibling tools by explicitly noting it cannot initiate payment, making it distinct from checkout workflows.
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 phrase 'settled report' implies usage after payment, and 'This tool cannot initiate payment' excludes payment-related use cases. While it doesn't name alternatives explicitly, it provides clear context that this is a read-only companion to the checkout flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool represents a distinct step in the payment-gated report workflow. No two tools overlap; even the two report-related tools are separated by payment status and described unambiguously.
Most tools follow a consistent verb_noun pattern (create_quote, get_report, prepare_checkout, settle_checkout), but 'service_info' breaks the pattern with a noun-noun construction.
With five tools, the server is appropriately scoped for its purpose; each tool is necessary for the quote-to-report lifecycle and there are no redundant utilities.
The core lifecycle is well-covered (info, quote, checkout, settlement, retrieval). The only minor gap is no explicit cancellation or update tool, but that doesn't hinder the primary workflow.