Skip to main content
Glama

import_resume_submit_tex

Check a LaTeX resume against the imported Word or PDF source, then optionally accept it when the content matches.

Instructions

Check a LaTeX version of the imported resume against the source Word or PDF file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
texYes
accept_if_okNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, and it undersells the operation: 'Check' reads as a read-only comparison, yet the tool is named submit_tex and exposes an accept_if_ok flag that implies the check can commit or accept the imported resume. Nothing is said about side effects, what a mismatch does, or reversibility.

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?

A single front-loaded sentence with no filler. It is appropriately short, though the brevity is achieved partly by omitting needed information rather than by tight writing.

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

Completeness2/5

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

With no annotations, no output schema, 0% schema coverage, and an undocumented side-effecting flag, the description leaves an agent unable to call this correctly or predict its effects. It should at minimum explain what a successful check returns and what accept_if_ok does.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters. The description loosely implies the 'tex' input is the LaTeX file under test, but it never explains the required tex string's format or the accept_if_ok flag at all, which is the one parameter with real behavioral consequence.

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?

States a concrete action (check/compare) on a specific resource: the LaTeX version of an imported resume against the source Word/PDF. This places it in the import_resume_* workflow and separates it from siblings like build_resume or import_resume_prepare, though it never names a sibling explicitly and the name's 'submit' verb is not reconciled with the description's 'check'.

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?

No when-to-use guidance, no stated prerequisites (presumably a prior import_resume_prepare call), and no indication of what to do if the check fails. The agent must infer the whole position of this step in the workflow from the name alone.

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