Skip to main content
Glama
seinun-ai

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Record Filled Answers

record_filled_answers

Records what you filled into each job application form page, saving every question, answer, and source, and flags answers that need review.

Instructions

Record what was filled into this job's application form, one call per form page: each field's question, answer and source. Per question the latest call wins; the job page's What was submitted tab shows the record. An EEO answer is kept only while the user's standing EEO consent is recorded, and no MCP read returns its value. Returns {id, application_id, flag_count, flags}: each flagged field by its index in fields, with guessed_screening (a screening question answered by inference or composed prose), ticked_everything (a multi-select with every one of 3+ options ticked), differs_from_profile or eeo_without_saved_answer, each with a one-line reason. Flags warn; nothing is blocked, and get_final_review lists the job's flags again. step names the page: pass its URL path (location.pathname), the Companion's own key, so an agent row and a Companion row for one page fold together; a page number is still accepted. application_id links the record now; without it the record links, for the application of base_resume (the base resume's slug), when that application is created, marked applied or submitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepNo
fieldsYesThe page's fields as filled: {question, source, answer?, section?, required?, options_count?, slot?, eeo?, edited_by_you?}. answer is a string, or for a multi-select the list of ticked options with options_count, the number offered. source: profile (the autofill profile) | resume (work history or skills) | custom (a saved answer) | written (prose composed for this form) | inferred (a choice no saved fact states) | you (typed or changed by the user) | upload (a file: slot resume or cover_letter, answer the file name). slot names the profile fact, such as preferences.willing_to_relocate. eeo marks a voluntary self-identification question.
job_idYes
base_resumeNo
application_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses latest-call-wins overwrite semantics, that EEO answers persist only while standing consent is recorded and no MCP read returns their value, the exact return shape {id, application_id, flag_count, flags}, each flag type with meaning, and that flags warn rather than block. Annotations only cover write/safety hints, so this added context is substantive.

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?

Dense but mostly front-loaded, starting with the action and page granularity. The application_id/base_resume linking sentence is convoluted and hard to parse, costing some clarity, but nearly every sentence conveys non-obvious behavior.

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

Completeness5/5

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

With no output schema and low schema coverage, the description compensates fully: it documents return values, flag semantics, consent-gated EEO handling, overwrite behavior, and the keying strategy for pages and applications. Nothing an agent needs to call it correctly appears missing.

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

Parameters5/5

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

With only 20% schema coverage, the description carries the load and does: `step` is explained as the page URL path (location.pathname) so agent and Companion rows fold together, while page numbers are still accepted; `application_id` vs `base_resume` linking rules are spelled out; and the `fields` payload format, source enum, and eeo/slot semantics are detailed.

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?

Opens with a specific verb+resource: recording what was filled into a job's application form, one call per page. It is unmistakably distinct from siblings like record_triage, record_decision, or edit_application, and it states the granularity (per form page) that governs invocation.

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?

Gives clear operational context: call once per form page, per question the latest call wins, and points at the 'What was submitted' tab and get_final_review for verification. It does not name a competing tool or an explicit when-not-to-use condition, so it stops short of a 5.

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

Deploy Server

Other Tools