Skip to main content
Glama
niragmehta
by niragmehta

Record a manual submission

record_submission

Mark a job application as submitted after a person sends it, keeping counts, pacing, and duplicate checks accurate.

Instructions

Marks an application as submitted after a person sent it, so counts, pacing and duplicate checks stay accurate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
applicationIdYes
confirmationRefNo
Behavior4/5

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

Annotations only indicate readOnlyHint=false, so the description carries the burden of explaining the mutation. It adds useful context that recording affects counts, pacing, and duplicate checks, which helps the agent understand side effects. However, it does not disclose reversibility or other behavioral details, so a 4 is appropriate.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that immediately states the core action and then adds the purpose. Every word earns its place, with no filler or repetition.

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 output schema and only minimal annotations, the description leaves out return behavior, parameter details, and potential side effects. It is too sparse to fully guide an agent invoking the tool, especially with three parameters and no schema-level descriptions.

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%, and the description does not explain any of the three parameters (applicationId, notes, confirmationRef). It only hints that an application is being marked, but provides no meaning or usage guidance for the parameters. This is a significant gap.

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?

The description clearly states the tool marks an application as submitted after a person sent it, using a specific verb ('marks') and resource ('application'). It distinguishes from sibling tools like submit_application by emphasizing the manual submission context, and explains the purpose of keeping counts, pacing, and duplicate checks accurate.

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 description gives clear context for when to use the tool: when a person has manually sent the application. It implies this is distinct from automated submission tools, but it does not explicitly name alternatives or provide exclusions, 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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/niragmehta/autoapply-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server