h1b_check
FREE. Does this US employer sponsor H-1B visas? Approvals/denials from the USCIS H-1B Employer Data Hub — top 3 matches.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employer | Yes |
FREE. Does this US employer sponsor H-1B visas? Approvals/denials from the USCIS H-1B Employer Data Hub — top 3 matches.
| Name | Required | Description | Default |
|---|---|---|---|
| employer | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses cost ('FREE'), data provenance (USCIS Employer Data Hub), and that results are capped at the top 3 matches, but says nothing about authentication needs, matching behavior (exact vs fuzzy), or what is returned when no match is found.
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 compact sentences with the core question front-loaded, followed by provenance and result shape. 'FREE.' is short but does consume the lead position with a billing caveat rather than the capability statement.
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 no annotations, no output schema, and an undocumented parameter, the description does enough to convey what comes back (approvals/denials for top 3 matches). It is still thin on input expectations and on the relationship to the two sibling tools, leaving an agent to guess which tool fits a given request.
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% for the single 'employer' parameter, so the description must compensate. It implies the value is a US employer name and that matching is approximate ('top 3 matches'), but it does not clarify expected formatting, partial-name tolerance, or whether multiple employers can be supplied.
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 question the tool answers (does this US employer sponsor H-1B visas) plus the data source (USCIS H-1B Employer Data Hub) and the result shape (approvals/denials, top 3 matches). It does not explicitly differentiate itself from siblings employer_detail or sponsor_search, so it stops short of a 5.
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 implied (quick check of a named employer) but there is no statement of when to use this versus sponsor_search or employer_detail, and no guidance on what happens when the employer name is ambiguous or absent from the data. Only the 'top 3 matches' hint suggests a fuzzy lookup use case.
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.