Spanish Top Tech Companies

Report how an application went

report_application

Idempotent

After sending an application to a posting from find_jobs, or failing to, report the outcome: sent, uncertain (submitted, but the board neither confirmed nor clearly refused it), failed (with the reason) or handed over to the person to send. Nothing about the person is asked or stored; it counts which postings get applications and where sending gets stuck, so the site can fix it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "status": "<status>"
    },
    "name": "report_application"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The job id from find_jobs.
`notes`	No	In a sentence or two, what you had to work out that these tools did not tell you: the tool or trick that worked, what the board did. About the board and the tools only: nothing about the person, no names, emails, answers or CV text.
`steps`	No	What it took beyond filling the form, every one that applies: set_up_browser (you had to add a browser tool), switched_browser (the first tool failed and another worked), read_form_in_browser (job_questions gave no questions), extra_questions (the page asked ones job_questions did not list), required_differed (the page required a field given as optional, or the reverse), location_differed (the page named another location), reattached_cv (the upload had to be repeated), converted_cv (the board wanted another file format or size), email_code, captcha_to_person, person_signed_in (an account or login), person_filled_field (they typed something you could not), retried_submit, other.
`reason`	No	Why it failed or is uncertain: captcha, login_required, form_error (a field was refused), upload_refused (the board would not take the CV file), submit_error (the board answered the submit with an error), no_confirmation (submitted, nothing confirmed it), posting_closed, blocked (the board refused the browser), no_browser, person_declined, other.
`status`	Yes	sent: the board confirmed it, on the page or by email. uncertain: it was submitted and the board showed an error or no confirmation, so it may or may not have arrived. failed: it was not submitted. handed_over: the person got the URL and the answers.
`browser`	No	What you sent it with: built_in (your client's own browser), claude_in_chrome, playwright_mcp, other, or none.
`context`	No	Why are you calling this tool? Describe the goal in general terms, and refer to people by role ("a candidate") rather than by name. Leave out personal and identifying information.
`attempts`	No	How many times you submitted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare this is a non-destructive, idempotent, non-open-world write, so the safety bar is partly covered. The description adds context annotations cannot: that no personal data is asked or stored, and that reports are aggregated to show which postings get applications and where sending gets stuck. It stops short of saying what a repeat report for the same id does, leaving that to the idempotentHint.

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

Conciseness4/5

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

Two sentences, front-loaded with the trigger and the outcome vocabulary, and the privacy statement is short and earns its place. The first sentence is dense with parenthetical glosses on 'uncertain' and 'failed' that partly duplicate the status enum descriptions.

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

Completeness4/5

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

For an 8-parameter, high-complexity reporting tool with no output schema, the description covers the trigger, the outcome taxonomy, and the data-handling contract an agent needs to call it responsibly. It omits what the call returns and how repeated reports for the same posting are treated, minor gaps given the idempotency annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the enums for status, reason, steps and browser are documented field-by-field in the schema itself. The description only glosses the four status values, which the schema already defines in more detail, so it adds little semantic value beyond the schema baseline.

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

Purpose5/5

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

States a specific verb and resource ('report the outcome' of an application) and enumerates the four outcomes the tool records. It also anchors the tool to the sibling that produces the input ('a posting from find_jobs'), so an agent can place it in the workflow without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trigger is explicit: call this after sending an application, or after failing to send one. It does not name a when-not condition or point at an alternative tool (e.g. where to go for guidance before applying), but for a post-action reporting tool the timing guidance is unambiguous.

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

All Spanish Top Tech Companies tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.