Skip to main content
Glama

jobctl

by io.github.DmytroRybka

Attach CV or cover letter

attach_file
Destructive

Attach or replace a file on an application so the user sees it in the dashboard: a CV/resume (kind: 'cv') or a cover letter (kind: 'cover_letter'). Pass the file bytes as base64 in data_base64. One file per (application, kind) - a new call REPLACES the previous one. Max ~5 MB; pdf/doc/docx/txt/md (MIME is inferred from the filename if you omit it). Call this whenever you generate a tailored CV or cover letter for an application. Example: attach_file({application_id: "…", kind: "cv", filename: "CV_Cursor.pdf", data_base64: "JVBERi0…"}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
mimeNoOptional; inferred from the filename extension when omitted
filenameYes
data_base64YesBase64-encoded file bytes
application_idYes

TDQS

A4.4/5.0
Behavior5/5

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

Annotations indicate destructiveHint=true; description reinforces this by stating a new call 'REPLACES the previous one'. Adds behavioral details beyond annotations: max 5 MB size, supported formats (pdf/doc/docx/txt/md), MIME inference from filename. No contradiction with annotations.

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?

Description is 3-4 sentences, front-loaded with main action and purpose. Includes a concrete example call. Could be slightly more concise without the example, but structure is effective and easy to parse.

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

Completeness3/5

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

Covers input parameters and behavior well, but lacks any description of return values (no output schema). For a file upload tool, mentioning what is returned (e.g., success indicator or updated application) would improve completeness. Otherwise adequate for agent selection.

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

Parameters4/5

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

Schema description coverage is 40%; description adds meaningful context: clarifies kind enum values ('cv' or 'cover_letter'), explains data_base64 as base64-encoded bytes, and documents that filename extension infers MIME. Does not detail application_id format beyond schema's regex, but overall adds significant value.

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?

Clearly states verb 'Attach or replace' and resource 'file on an application', specifies two kinds (cv, cover_letter). Explicitly differentiates from sibling tools like attach_analysis by stating when to call: 'whenever you generate a tailored CV or cover letter for an application'.

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?

Provides explicit usage context: call when generating a tailored CV or cover letter. Mentions replacement behavior and constraints (one per (application, kind)). However, does not explicitly state when not to use or name alternatives like attach_analysis, leaving minor ambiguity.

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

All jobctl toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Every tool targets a distinct resource and action: application, note, analysis attachment, file attachment, interview file, application detail, due actions, planned schedule, application listing, interview logging, and application updates. Even the three 'attach' tools are clearly differentiated by purpose (analysis vs CV/cover letter vs interview prep). The only potential overlap between get_due and get_planned is explicitly resolved in the descriptions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (add_application, get_application, list_applications, update_application, attach_analysis, log_interview, etc.). The verb prefix accurately reflects the action, and nouns are singular for single-item operations and plural for list operations, maintaining a predictable convention.

Tool Count5/5

With 11 tools, the server is well-scoped for a job application tracking domain. Each tool covers a necessary function without redundancy, and the count is neither sparse nor overwhelming.

Completeness4/5

The tool set covers the full lifecycle of an application: create, read, list, update, plus notes, attachments, analysis, and interview logging. Minor gaps exist—there is no explicit delete or archive tool (though status updates can archive), and interviews cannot be directly updated or removed after logging—but these are workable within the existing surface.

Resources