Work Researcher MCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Each tool maps to a distinct job-search, application, or browser action, and search_jobs/get_job/fetch_job_description are separated by source and purpose. The main boundary that needs care is browser_type vs browser_set, but their descriptions steer usage to different control types.
Naming Consistency4/5Domain tools consistently use verb_noun (search_jobs, start_application, record_application), and browser tools share a predictable browser_ prefix. A few noun-style names like browser_tabs, browser_snapshot, and browser_form break the otherwise verb-first pattern.
Tool Count2/5At 29 tools, this exceeds the 25-tool threshold and feels heavy for a single MCP server. The browser_* primitives are individually distinct, but bundling a full browser automation suite with the job-application domain layer makes the surface larger than necessary.
Completeness5/5The tool set covers the full workflow: searching and deduplicating jobs, fetching fuller descriptions, managing blocklists and CVs, checking prior applications, starting and recording applications, and driving the browser through manual forms. There are no obvious dead ends; truncated descriptions have a dedicated fetch tool and form interactions have snapshot/form/set/click/upload primitives.
Average 4/5 across 29 of 29 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no anotations, the description carries the burden of disclosing behavior. It conveys that this is a non-mutating read operation and describes the kind of data returned. It does not mention side effects, persistence semantics, or ordering/pagination, but for a list tool the core behavior is adequately suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with concrete information. The metaphor 'long-term memory' adds some flavor but is not essential; overall every sentence earns a place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list with two optional parameters and no output schema, the description gives enough to understand the general return content. It does not explain the filtering behavior of status or the meaning/effect of limit, leaving the agent to infer from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It nore mentions 'status' as a field in the returned history, which sheds some light on that parameter, but it does not explain that status functions as a filter, and it says nothing about the limit parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('Application history') and the specific data it contains (job, company, status, dates), and gives scope ('everything already applied to'). It does not explicitly name sibling alternatives, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over related siblings like check_applied, get_status, or record_application. The phrase 'long-term memory' implies a read/history use case, but no conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. It does state that the tool waits until a condition is met and returns a snapshot, but it omits timeout behavior, what happens if the expected text never appears or disappears, and whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with concrete examples and a clear return signal. The slash-separated conditions create slight ambiguity, but the structure is efficient and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three parameters are optional in the schema and there is no output schema or annotation coverage, so the description needs to clarify valid input combinations and edge-case behavior. An agent cannot tell what a bare call with no arguments does or how long it will wait, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the prose needs to carry parameter meaning. It maps 'time' to seconds, 'text to appear' to text, and 'text to disappear' to text_gone, which is helpful. But it does not clarify whether exactly one condition must be supplied, what happens if multiple are supplied, or what a call with no parameters does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a wait action with three trigger conditions: elapsed time, text appearing, and text disappearing, and states it returns a snapshot. This is specific enough to distinguish it from related browser tools like browser_snapshot or browser_screenshot, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples 'Application submitted' and 'spinners' imply this tool is for waiting on async UI updates after actions, which gives useful context. However, it does not explicitly state when not to use it or compare it against sibling tools that also return snapshots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 burden. It states that JS runs on the page and hints at side effects like scrolling, but does not disclose the return value, error behavior, asynchronous handling, or the potential for arbitrary side effects on the page. This is thin for a powerful eval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence that states the core action first and then lists useful application examples. Every word serves a purpose and no redundant detail is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and only a minimally described parameter, so the description must carry substantial contextual load. It names the operation but omits critical operational details like return format, page context caveats, error propagation, and side-effect warnings, leaving an agent to ricognize how to safely and correctly use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a required string parameter 'js' with no description. The description implies js is the JavaScript code to execute, but does not explain whether it should be an expression, statement, async function, or how the result is returned. With 0% schema coverage, the description should compensate more strongly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Evaluate'), names the resource ('JS on the page'), and gives concrete examples that distinguish it from sibling browser interaction tools. It clearly conveys what the tool does and why an agent would choose it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples—extract hidden JSON, scroll, dismiss cookie banners—provide concrete scenarios where evaluating JS is appropriate. It does not explicitly state exclusions or name alternative tools, but the context is clear enough for typical browser automation decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It discloses the outcome (fresh snapshot) but does not mention possible side effects of key presses, whether a page must already be open, or the full range of accepted keys beyond three examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and uses an arrow to clearly indicate the result. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core action, example values, and expected result. However, the lack of parameter enumeration and usage differentiation leaves gaps that could hinder correct invocation within the broader browser tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one 'key' parameter with 0% description coverage. The description compensates partially by providing example values (Enter, Tab, Escape) that map to the parameter, but it does not specify the complete set of accepted keys, case sensitivity, or aliases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Press') and resource ('page-level key') with example keys and a clear outcome ('fresh snapshot'). It distinguishes this tool from siblings like browser_click and browser_type by focusing on keyboard key presses at page level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pressing page-level keys but provides no explicit when-to-use guidance or exclusions. It does not mention alternatives like browser_click or browser_type, leaving the agent to infer selection among the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly states the side effect (a PNG is saved to data/screenshots) and implies that a path is produced for subsequent use. It doesn't cover overwriting, file naming, or page-load requirements, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one efficient sentence with no filler. It front-loads the key fact (save a PNG to data/screenshots) and closes with the actionable next step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter tool, the essential flow is covered: save, get path, pass to record_application. But the description leaves `full_page` and `name` semantics unaddressed, and there is no output schema to fill that gap, so the definition is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it never explains `name` or `full_page`. The mention of `path` is about the output rather than the parameters, so the agent gets little help understanding the optional arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: save a PNG to data/screenshots. It also explains the intended downstream use (pass the path to record_application). However, it does not explicitly differentiate itself from sibling tools like browser_snapshot or browser_upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete usage context: capture a screenshot and use the saved path as evidence for record_application. This is clear context, but it stops short of explicitly saying when not to use it or naming alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose mutation and the allowed status values plus evidence shape, but it doesn't state overwrite semantics, whether the application must already exist, permissions, or what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and fields, with no filler. The status pipe list and evidence format earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a simple field-update tool, but with no annotations or output schema it leaves open important invocation details such as whether application_id must reference an existing record, whether omitted fields are preserved or cleared, and what success/failure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry parameter meaning. It adds the status enum, notes/cover_letter as text, and evidence as a screenshot-path object. The only gap is that application_id is not explicitly described as the update target, though 'Update an application' implies it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an application' and enumerates the mutable fields (status, notes, evidence, cover_letter). It distinguishes itself from siblings like start_application and list_applications by using the verb 'update', though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: an existing application is updated with a status and optional fields. However, there is no explicit guidance on when to choose this over start_application or check_applied, and no exclusionary conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the return payload in detail, the refusal behavior for duplicate applications, and the cross-board dedup memory. It stops short of explicitly stating whether the tool performs any state changes beyond planning, but the plan-oriented wording and memory disclosure make behavior largely clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but information-rich, with a clear front-loaded purpose sentence followed by structured output details and the key constraint. Every sentence contributes, though the long enumeration could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers outputs and the anti-double-apply constraint well, but with no annotations, no output schema, and 0% parameter coverage, it leaves gaps around prerequisites (e.g., existing CVs/profiles), the role of notes, and how the returned plan is meant to be consumed alongside browser or recording tools. It is adequate but not fully complete for a complex orchestration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting cv_id, notes, and job_id. It only indirectly references the job and CV ('chosen CV (+alternatives)'), never mentions notes, and does not explain how cv_id interacts with selection or what notes are used for. This is a meaningful gap for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Begin applying to a job.' It then distinguishes this tool from likely siblings by stating it returns a comprehensive plan (URL, playbook, CV, steps, cautions) rather than merely recording an application. The anti-double-apply refusal further clarifies its unique responsibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Begin applying to a job') and gives a clear when-not condition ('REFUSES to create a second application for a job that already has one'). However, it never names alternatives such as check_applied, record_application, or list_cvs, leaving the agent to infer the decision boundary among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does disclose important behavior: clicking returns a fresh snapshot and popups automatically become the active tab. This goes beyond a bare 'click' statement, though it does not disclose timeout behavior, error cases, or whether navigation waits for page load.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the action comes first, followed by the return behavior and the popup caveat in a short parenthetical. Every phrase 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter click tool, the description provides the essential action and return behavior. However, it lacks timeout_ms semantics and any guidance about selecting this over sibling input tools, so an agent has enough for a basic call but not full confidence in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that n refers to an element number/index via "element #n", but it says nothing about timeout_ms, leaving a required-for-completeness parameter undocumented. The description only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Click element #n". It also clarifies the output (FRESH snapshot) and a key behavioral consequence (popups become the active tab), making it clearly distinguishable from sibling browser_* tools like browser_press, browser_type, or browser_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs to click an element and then inspect the resulting snapshot, but it does not explicitly state when to use this tool versus alternatives such as browser_press or browser_form. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key output traits—focusing on the dominant form, human labels, and heuristically detected submit buttons ('likely'). It also implies stability with 'use once.' However, it does not state whether the operation is read-only, whether it can fail, or what happens when no form is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two short sentences—with the output structure front-loaded and the usage instruction in the second sentence. It is slightly dense and grammatically a noun phrase, but it contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description covers the essential return content and the logical next step (browser_set by field number). It leaves minor edge cases unaddressed, such as handling multiple forms or a missing form, but it is largely sufficient for a zero-parameter inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline is 4. The description adds no parameter meaning, but none is needed; instead it clarifies the semantic content of the returned field metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the 'dominant form' and enumerates the returned data: per-field metadata (n, tag, type, label, required, options) plus likely submit buttons. However, it lacks an explicit verb like 'extract' or 'inspect,' relying on a noun phrase, which slightly weakens action clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete workflow guidance: 'Use once per application page, then browser_set fields by number.' This tells the agent when in the interaction sequence to invoke the tool. It does not mention alternatives or explicit exclusion cases, but the usage rule is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral transparency burden. It discloses one non-obvious behavior: click-opened popups become active automatically and that this tool can switch back. However, it doesn't clarify what the action/close does to the active tab or what the response looks like, leaving some behavioral detail to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded: the first phrase summarizes all operations, and the second sentence adds a single practical behavioral note. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core purpose and an importent behavioral nuance, which is reasonable for a small utility tool. Yet with no output schema and no parameter explanation, an agent still lacks details about how to specify a tab or what happens when list/select/close is executed. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverate is 0% , and the description only loosely maps 'list / select / close' to the likely `action` values. It doesn't explain the `index` parameter, its null default, or how index relates to tab selection/closing. Since parameter documentation is absent from both schema and description, the agent gets insufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (tabs) and three specific verbs (list, select, close), which makes the tool's purpose immediately recognizable. This clearly differentiates it from sibling tools like browser_open or browser_click, which concern navigation and page interaction rather than tab management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete usage instruction: click-opened popups become active automatically, so use this tool to switch back. This is helpful contextual guidance for when to invoke the tool. It doesn't enumerate alternatives or explicit when-not scenarios, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions the local-folder source, which implies a read operation, but does not explicitly state that it is read-only, what output structure to expect, or whether any indexing is triggered. The behavioral surface is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant wording. The core purpose is front-loaded, followed by parameter-specific guidance. The structure is clean and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description leaves out the return format: what a CV entry contains and how per-CV scores are structured. It also does not clarify whether 'indexed' implies a one-time indexing step or a pre-existing state. This is enough for a basic call but incomplete for robust agent success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter job_id is given meaningful semantics: passing it returns per-CV recommendation scores for that job. This goes well beyond the schema's type/nullability by explaining the effect of providing the parameter, which is critical since schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (CVs) and the scope (indexed from the active profile's local folder). The optional job_id behavior is also described, which adds functional clarity. It does not explicitly name a sibling or contrast with `sync_cvs`, leaving slight ambiguity about when to choose this over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call to list CVs, and pass job_id to get per-CV recommendation scores. However, it gives no explicit guidance on when to use this tool versus siblings like `sync_cvs` or `list_applications`, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals persistence ('logins survive between runs'), default visibility ('Headed by default'), and return behavior ('returns the first snapshot'). This goes beyond the schema but does not mention tab reuse, error handling, or side effects on existing browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding distinct value. The primary action is front-loaded, followed by state persistence and headless behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two parameters, the description covers the essentials but leaves out how browser_open interacts with the existing tab(s), whether it opens a new tab or reuses the current one, and what happens on invalid URLs. Sibling tools like browser_tabs and browser_close make this surrounding context more relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly explains headless via 'Headed by default' and implies url means the address to open, but it never explicitly maps each parameter or provides format constraints. Some meaning is added, but not enough to fully overcome the absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Open a URL in the persistent application browser.' It also notes the return value ('returns the first snapshot'), which distinguishes it from navigation, typing, and clicking siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context like 'Logins survive between runs' and 'Headed by default so the user can handle 2FA/captcha', implying when the headless parameter matters. However, it never explicitly says when to prefer browser_open over alternatives or when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool returns a fresh snapshot and explains how values are interpreted per control type. However, it does not mention side effects like waiting, scrolling, triggering events, or behavior on failure, which would make the behavior more transparent for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that packs the core operation, per-control value semantics, and return behavior with minimal waste. The arrow-based formatting is slightly dense but remains scannable and front-loads the primary verb and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations and no output schema, the description provides enough to invoke it correctly: what to set, how each control type interprets the value, and what is returned. Minor gaps remain around array values for multi-selects and whether actions wait for the element, but these are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'n' refers to an element number and explains 'value' semantics for inputs, selects, and checkboxes/radios. The array form of 'value' is not explicitly addressed, but the core parameter meaning is well covered beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and resource ('element #n'), and clarifies the operation by mapping value semantics to control types (inputs, selects, checkboxes/radios). It is clear and actionable, though it does not explicitly distinguish itself from sibling tools like browser_type or browser_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct guidance on when to use the tool for different control types: inputs should be filled, selects should receive an option value, and checkboxes/radios should receive true/false. It does not mention exclusions or name alternatives, but the control-type mapping provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal useful behavior: matching is by job_id, exact URL, or fuzzy title+company, and it can catch duplicates across boards. However, it does not state whether the operation is read-only, what it returns, or how it behaves when no matching parameters are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The user-facing question is front-loaded, followed by the matching modes and the critical usage instruction. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains when to call the tool and how to target a job, but it omits return semantics and post-check handling. Since there is no output schema and no annotations, an agent still has to infer what kind of result comes back and what to do with it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps all four parameters to their intended usage: job_id, URL, and the title+company fuzzy combination. This is meaningful semantic context, though it does not specify whether at least one parameter is required or what happens when multiple modes are passed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear action (check whether an application already exists) and a specific resource (a particular job/vacancy). It also specifies distinct lookup modes—job_id, exact URL, or fuzzy title+company—which makes the tool's purpose concrete and separates it from broader tools like list_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'ALWAYS call before a manual browser application.' This tells an agent when to use the tool, but it does not name sibling alternatives or explain when this check is unnecessary, so it stops short of full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden and does well: it discloses adaptive batch sizing behavior, the different response profiles, and the important guarantee that 'No job is deleted when a supplied job_ids list is truncated'. It does not mention whether authentication or other side effects are involved, but the truncation note conveys a non-destructive read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and dense, with every sentence providing actionable information. It front-loads the purpose and then adds parameter behavior, usage advice, and a critical truncation guarantee without filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description covers the core behavior: batch sizing, profile-specific limits, and truncation handling. It is slightly incomplete because it does not explain the default 'auto' profile or the output structure of summaries versus full descriptions, but these are minor compared to the clarity provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to response_profile with specific counts, links context_window/response_profile to search_jobs, and implies include_description maps to 'full descriptions'. However, it does not explain the 'auto' enum value or the exact semantics of context_window values, which leaves some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Details for selected jobs' with adaptive batch sizing, indicating it returns job detail data. It references search_jobs for parameter reuse, which hints at differentiation, but it does not explicitly name sibling alternatives like fetch_job_description or list_stored_jobs, and the opening is a noun phrase rather than a direct verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The advice to 'Pass the same context_window/response_profile used for search_jobs' gives concrete context for how to invoke the tool after a search. It also offers strategic guidance ('Request full descriptions only for plausible finalists'), but it does not explicitly state when to prefer this tool over fetch_job_description or other siblings, nor does it list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the write operation, destination folder, returned path, and the metadata-padding behavior for short text. It could be more transparent about overwrite behavior and naming, but it covers the key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences with no filler. The purpose is front-loaded, the padding edge case is explained, and the DOCX preference is justified. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description provides strong operating context: destination, return type, format rationale, and an important upload constraint. The main missing piece is the 'name' parameter and possible overwrite behavior, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions, so the description must clarify parameters. It indirectly clarifies 'text' as the cover letter content and links it to the padding rule, but it does not mention the optional 'name' parameter at all or what it controls. This is a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Write'), resource ('cover letter as a DOCX file'), destination ('CV_collection'), and return value ('its path'). It clearly differentiates itself from sibling tools like browser_upload by positioning itself as the file-creation step before upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Names browser_upload as the downstream consumer and explains why DOCX is preferred over PDF with the 8KB upload constraint. It gives clear use context, though it does not explicitly state when not to use this tool or name an alternative generation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the key side-effect fact that the login profile persists on disk after closing. It does not mention process-level details, but the most important consequence for an agent is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the core action front-loaded and the important side effect in a parenthetical. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless close operation with no output schema, this description is complete: it tells the agent what happens and what persists. No additional argument or return-value documentation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. With no input schema coverage needed, the description is not required to add anything further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Close the browser.' The parenthetical about the login profile persisting on disk adds a meaningful scoping detail that distinguishes closing from a destructive reset or logout. It does not explicitly contrast with sibling browser_open, but the action is otherwise unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical provides clear practical context: the tool can be used to end a browser session without losing saved login state. It does not enumerate alternatives or exclusions, but for a zero-parameter primitive in a browser suite, the implied usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that typing is key-by-key and intentionally fires JS handlers, and that submit=true presses Enter and yields a fresh snapshot. This is meaningful context about side effects and behavior beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences, no filler, with the core action and the most important behavioral points front-loaded. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no annotations or output schema, the description covers the action, the target, the optional behavior, and the key side effects. It does not discuss edge cases, when typing might fail, or what happens when submit is false, but the core usage is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for missing parameter documentation. It clarifies n as the target element ('#n') and explains the submit parameter's behavior ('submit=true presses Enter'), but it leaves the text parameter entirely implicit, relying on the tool name and schema title. This is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Type into #n key-by-key') and resource, making it clear this is a text-entry tool. It also distinguishes itself from siblings like browser_press or browser_set by emphasizing key-by-key input that fires JS handlers, and by naming target use cases (search boxes, chat fields).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the tool for search boxes and chat fields, which gives clear context for when it applies. It does not explicitly say when not to use it or name alternatives, so it falls short of a 5, but the intended usage is not left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does useful work: it reveals what the snapshot includes and signals the intended session-start placement. 'Snapshot' implies a non-mutating read, but it does not explicitly confirm side-effect-free behavior or note sensitivity of exposed API keys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly worded sentence with a front-loaded purpose, a concise content list, and the call-order instruction at the end. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health/config tool, the description covers what the agent receives and when to invoke it. Even without an output schema or annotations, no critical operational detail seems missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no parameter burden. Baseline for zero parameters is 4; the description adds no parameter-specific details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a health/config snapshot and enumerates its contents (active candidate, localCV director, DB stats, providers, API keys, saved searches). It distinguishes from sibling tools by being a status/introspection endpoint, though it lacks an explicit verb like 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Call first in a session' gives explicit when-to-use guidance that is highly actionable for an agent. It does not explicitly compare against alternatives, but as the only status/snapshot tool among siblings, exclusion is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the action (click, send file) and the resulting fresh snapshot, which is useful. However, it does not mention whether the tool waits for the upload to complete, what happens if the control is missing, or potential page navigation—gaps that matter for reliable automation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action, parameter mapping, and output in sequence. There is no filler or repetition; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a two-parameter browser action with a shared snapshot return concept. It mentions the return ('fresh snapshot') and ties the file path to start_application, which covers the main workflow dependencies. It omits minor details like wait behavior or failure modes, but these are less critical given the narrow scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explicitly interprets both parameters: 'n' is the upload control number, and 'file_path' is the local CV path from start_application. This gives the agent precise meaning far beyond the raw schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Click upload control #n and send a local file' and identifies the resource (upload control) and the context (CV path from start_application). This clearly distinguishes it from sibling tools like browser_click, browser_set, or browser_type, which target other interaction types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: after start_application, when an upload control is present and a file must be sent. It does not explicitly exclude alternatives, but the specific mention of 'CV path from start_application' gives concrete workflow context, which is strong enough for an agent to route selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does so exceptionally well by describing persistence in config.toml, immediate effect, closing the old browser first, and switching isolated CV, database/application, and browser-login folders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by necessary side-effect details and a usage tip. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The side effects of switch are well documented, but there is no output schema and the description does not state what 'list' returns. It also omits the relationship between the 'profile' parameter and the switch action. These are notable gaps for an otherwise strong description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains what the action values 'list' and 'switch' mean, but it never explicitly defines the 'profile' parameter, its necessity for switch, or the default behavior. The user can infer the meaning, but the description does not spell it out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pair: 'List candidate profiles or switch the active candidate.' It clearly distinguishes this profile-management tool from sibling tools like list_cvs or start_application, and the two action modes are both stated explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use directive: 'Always list/verify profiles before a search or application task for a named person.' It does not discuss exclusions or name alternative tools, but the context for using the tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses what the snapshot contains, how text_chas changes output, and that modal_only restricts output to the active dialog/wizard while excluding hidden templates. This gives the agent a solid mental model without claiming side effects that are not evidenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and telegraphic, with the core purpose front-loaded and every segment contributing parameter or workflow knowledge. No fluff or repetition exists; the formatting with newlines reinforces the distinct parameter behaviors.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and four optional params, this description is unusually complete. It covers input semantics, output shape ('numbered interactive elements + text'), and the downstream workflow (browser_set/click by number), so an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all four parameters: focus values, filter_text narrowing, text_chars boundary behaviors, and modal_only semantics. It adds substantial meaning beyond the bare schema and fully compensates for the schema's lack of comments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a page inspection action producing 'numbered interactive elements + text', which is specific enough to separate it from mostly unrelated siblings. It does not explicitly name a sibling alternative, but the focus/filter/modal modifiers make the tool's role plain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context: use modal_only=true for apply wizards, then browser_set/click by number, and use filter_text to find 'Apply'. It does not spell out when to prefer browser_snapshot over sibling tools like browser_screenshot or browser_eval, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that this performs no board calls, operates only on the local database, and returns job_ids, titles, and requirements status. This is effective transparency for a read-oriented search tool, though it does not mention ordering or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the most important distinction: local database, no board calls. Every sentence earns its place, and the follow-up routing is included without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description conveys the return fields and delegates detail retrieval clearly. It is complete enough for an agent to select and call the tool, though details like default limit and exact matching behavior are left to the schema defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It meaningfully explains query as title keyword, source as source board, days_old as freshness, plus company and location. Only limit is not semantically elaborated, but its default makes it low-risk.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the LOCAL job database, establishes the resource and an explicit verb, and differentiates itself from board-based calls. It also distinguishes follow-up detail retrieval into get_job / fetch_job_description, making its role among siblings obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this INSTEAD of Bash/sqlite for filtering by company, title, location, board source, or freshness, which is strong guidance. It also routes detail retrieval to get_job / fetch_job_description, but does not explicitly contrast with the sibling search_jobs beyond the 'no board calls' note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It states that observations go into a dedup + ranking store and that duplicates are merged, and it says what the tool returns ('stored count + duplicates merged'). It does not cover failure modes or idempotency details, but the main side effects are made transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly scoped sentences: it front-loads the action and source context, then gives the input shape, then states the return value. Every sentence earns its place with no irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description provides enough to call it correctly: the observation shape, source context, and return contract are all present. Additional semantics for the optional linkage fields and any prerequisites could make it fully complete, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so for the required observations parameter by enumerating the expected object shape ({source, url, title, company, location_text, salary_raw, description, posted_at?}), which goes far beyond the generic array-of-objects schema. The optional task_id, search_id, and observation_type fields are left to inference, which prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Feed jobs') and a specific destination ('the same dedup + ranking store'), and it further scopes the input by source ('the harness's own browser' listing Indeed, CV-Library, LinkedIn, Glassdoor). This makes the purpose clear and helps distinguish it from search-oriented siblings like search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'jobs found via the harness's own browser' gives a clear context for when this tool is appropriate, and the listed sources provide concrete criteria. It does not explicitly say when not to use it or name an alternative tool, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: only local manual copies are indexed (no cloud sync), unchanged files are skipped, and force=true overrides skipping. It doesn't describe failure modes or logging, but these are significant behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. The core action and scope are front-loaded, the force behavior follows logically, and the final sentence prevents a common misuse path (assuming cloud sync). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and a clear indexed resource, this is complete enough. It could mention what the output looks like (e.g., a list of indexed files), but the description covers action, scope, triggering condition, and caution. The sibling context confirms the tool's standalone nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the sole parameter 'force' semantically: 'Unchanged files are skipped unless force=true.' This adds meaning beyond the raw boolean field, telling the agent when to set it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's specific verb+resource: 'Index CV files manually copied into the active profile's cv_dir.' This clearly distinguishes it from siblings like submit_job or check_applied — it indexes CV files, not jobs or applications. It also explicitly disambiguates with 'There is no cloud sync,' clarifying it is not a sync operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it: after manually copying CV files into cv_dir, or to force re-indexing with force=true. While it doesn't explicitly name alternatives, the sibling list shows distinct tools and the description's focus on local files vs. jobs/applications implies the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses persistence ('memory'), the supported actions, the company vs keyword matching behavior, and important side effects—blocked jobs are hidden from search and refused by start_application until removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's purpose, then efficiently covers operations, parameter mapping, and side effects without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description is nearly complete: it covers purpose, operations, parameter semantics, and cross-tool effects. The only minor omission is what the list action returns, which is not essential for selecting or invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates: action is defined as add|remove|list, kind distinguishes company vs keyword, value is the company name or keyword, and reason is quoted context. This adds real meaning to every parameter in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an employer/recruiter exclusion memory and specifies its operations: add, remove, and list. It also distinguishes the tool from siblings by explaining its effect on search results and start_application refusals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: when the user says 'never apply to <company>', use action=add with the corresponding fields. It also explains keyword-based blocking. No explicit alternative is needed because no sibling tool provides this exclusion-memory function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses the open-site behavior, sign-in check, 'Continue with Google' flow, pre-approved account selection without prompting, and the logged_in/needs_user return contract. It also covers the interactive stop-and-ask condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose, then concisely detail the flow, account-selection policy, and return semantics. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a login tool with one parameter and no output schema, the description covers the return value, the interactive stop condition, and the account-selection policy. An agent has enough information to invoke it correctly and know how to respond after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, url, has 0% schema coverage. The description implies url is the job board site by saying 'Opens the site,' but it does not explicitly define the parameter or its formatting constraints. For a single parameter, this is adequate but not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific goal: ensure signed-in status on a job board before applying. It describes the login flow and clearly distinguishes itself from sibling tools like browser_open or browser_click by being a higher-level authentication operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context ('before applying') and instructs to stop and ask the user on 2FA/captcha/consent. However, it does not explicitly name sibling tools as alternatives or state when not to use it, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden and does so clearly: it opens pages in the browser, stores descriptions back, re-runs the requirements check against CVs, and detects closed vacancies. These are meaningful behavioral side effects beyond simply 'fetching'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, batch limit, use case, side effects, and closed-vacancy detection are all covered without unnecessary filler. The core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema, no annotations, and no output schema, the description is unusually complete. It tells the agent when to use it, what side effects will occur, what constraints apply, and what additional detection it performs, leaving little ambiguity for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and the schema covers none of its semantics. The description compensates by specifying that it accepts 1-10 job_ids and advising batching to save round-trips. It does not fully describe ID format or edge cases, but it adds meaningful constraint information the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetch FULL job descriptions by opening browser pages. It further distinguishes itself from related job tools by targeting parser failures (null/short descriptions) and adding side-effect behavior like re-running CV checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: for jobs where the parser returned null/short descriptions, common on Totaljobs/Reed. It also gives batching guidance. However, it does not name specific alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly covers automatic exclusion of paid training ads, deduplication across boards, ranking, memory flags, location intelligence, response sizing behavior, and the fact that all remaining results stay stored. This gives an agent a clear picture of side effects and processing behavior beyond a simple 'search jobs' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, with the core purpose stated first, followed by structured guidance on paging, response sizing, default behavior, and exclusions. Every sentence carries useful information, but the long paragraph format makes it harder to parse quickly; bullet-like sections would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 19 parameters, no annotations, and no output schema — the description covers the essential invocation flows, defaults, important exclusions, and key response characteristics. It does not fully document every parameter or the complete return shape, but it provides enough context for an agent to correctly perform fresh searches, page results, and tune response size.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining query, profile, search_id, offset, context_window, response_profile, limit, include_training, location_policy, and work_from_home. However, several parameters — sources, location, min_salary, max_days_old, radius_miles, drop_mismatch, drop_req_gap, limit_per_source, and enrich_descriptions — are left undocumented in both schema and description, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run a UK job search OR page an earlier one.' It clearly distinguishes the two operating modes (fresh search vs. paging an existing search) and gives concrete examples for query and profile. This makes the tool's purpose immediately obvious and differentiates it from siblings like get_job or fetch_job_description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: fresh searches take query/profile, while paging uses search_id+offset. It also explains when not to do something, such as setting include_training=true only when the user explicitly asks for courses, and documents defaults like the balanced response profile. This is strong operational guidance, even without naming sibling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Andrem19/work-researcher-bot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server