request_full_reportEmails the full Competitive Hiring Report for a posting to the person who will use it (their work email). Their click creates a free VeritaHire account and opens the report. Nothing more is sent unless they click.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| Yes | The email address the report goes to | ||
| state | No | ||
| title | No | ||
| job_id | No | ||
| job_url | No | ||
| employer | No |
Changes observed during successful MCP inspections.
Input schema / properties / email / descriptionPrevious value: -"Where to send it - the user's own address, with their consent"New value: +"The email address the report goes to"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the write/external nature is partly covered. The description adds real context beyond them: the recipient's click creates a free VeritaHire account, that click is what opens the report, and 'nothing more is sent unless they click' bounds the side effects. A 4 rather than 5 because it doesn't say whether repeat calls resend or what happens on failure.
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 tight sentences with the action and recipient front-loaded, followed by the side-effect caveat. Nothing is padded and every clause carries 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?
There is no output schema, so the description owns the burden of explaining behavior, and it does cover the main side effect well. However, with 7 parameters at 14% coverage and no explanation of how the posting is identified or what happens on a bad job_id, an agent lacks enough to invoke it confidently.
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 14% (just the email field), so the description must carry the load. It clarifies email ('their work email') but leaves city, state, title, job_id, job_url and employer completely unexplained — an agent must guess which combination identifies the posting to report on.
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?
States a specific verb ('Emails') and resource ('the full Competitive Hiring Report for a posting') plus the recipient. None of the siblings (benchmark_role, get_job, save_search, etc.) send anything, so an agent can distinguish it immediately.
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?
Usage is only implied: the description makes clear it targets 'the person who will use it (their work email)', i.e. the hiring manager. It never states when to reach for this over benchmark_role or get_job, and gives no prerequisites, but the intended scenario is inferable from the text.
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.