Claude Works

by andrewaws26

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct aspect of the job search and resume-building workflow: resume creation, job discovery, angle management, ledger operations, rendering, scoring, submission, and verification. No two tools have overlapping purposes, making selection unambiguous.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., build_resume, discover_jobs, record_application). The only exception is ledger_summary, which is noun_noun, but this is a minor deviation that does not cause confusion.
Tool Count5/5
With 13 tools, the server is well-scoped for its domain. Each tool serves a necessary function without superfluous additions, and the count is within the ideal range for manageable agent integration.
Completeness5/5
The tool set covers the full lifecycle: job discovery (discover_jobs), scoring (score_job), application planning (submit_application), ledger tracking (record_application, list_applications, ledger_summary), resume building (build_resume), verification (verify_resume), and rendering (render_resume). No obvious gaps exist.
Average 4.1/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 220 commits in the last 12 weeks
- Last stable release on July 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.json to 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?
No annotations are provided, so the description carries the full burden. It states the tool lists rows but does not disclose whether it is read-only, has pagination, or any ordering. The presence of an output schema reduces the need to describe return values, but behavioral traits beyond the schema are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description is mostly complete. It could mention that it is a read-only operation, but it covers the essential usage. The name 'applications' versus 'ledger rows' might cause minor confusion, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It effectively explains that the 'status' parameter is a filter and that an empty value returns all rows, adding semantic context beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List ledger rows' which is a verb+resource, but the tool name is 'list_applications', creating a slight mismatch. However, it is clear that the tool lists items, and the sibling tools confirm it is a list operation. The purpose is mostly clear but could be more aligned with the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the optional filter parameter 'status' and that empty status returns all rows. However, it does not provide guidance on when to use this tool versus its siblings like 'list_queue' or 'list_claim_fragments'. The usage context is limited to parameter usage.
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, and the description only states what the tool does, not how it works or any behavioral traits. It doesn't disclose if reading a file involves blocking calls or caching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys all necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema. The description is complete for basic usage, but lacks details like whether it reads a file each time or if it's cached.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds value by specifying the source file and output fields. Schema coverage is 100%, and the description provides context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list search angles from a specific file, enumerating the fields. It distinguishes itself from sibling get_search_angle by implying a list vs single retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the simplicity makes it obvious. No exclusions or context 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?
Without annotations, the description must convey behavior. It mentions external dependencies (Google Chrome, qpdf) and the return format (one_page field, pdf_path), but omits error cases or side effects like file creation. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three terse sentences, each packed with distinct information: action, return value, and prerequisites/pipeline role. No redundancy, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, output schema exists), the description covers the main behavioral aspects: rendering, return fields, dependencies, and pipeline position. It is slightly incomplete on parameter constraints but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'name' parameter. The description adds meaning by indicating it is used as '<name>.html', implying it's a base filename. This is helpful but minimal, leaving ambiguity about path or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders an HTML file named '<name>.html' to PDF and reports page count, which distinguishes it from siblings like 'build_resume' and 'verify_resume'. The verb 'render' and resource 'HTML to PDF' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions the tool as 'the first of the 4 gates', implying it should be used early in a pipeline. However, it does not explicitly state when not to use it or mention alternatives, limiting guidance for selection among siblings.
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?
With no annotations provided, the description carries the full burden. It describes a read-like operation but does not disclose details such as whether data is cached, real-time, or requires any permissions. The behavioral scope is too vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose without any superfluous text. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (as indicated by context), the description adequately covers the tool's purpose and expected output. No additional context is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The description reinforces that no inputs are needed, which is sufficient. A score of 4 reflects the baseline for parameterless tools where the description adds no extra burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a count of ledger rows by status and calls it a one-glance system summary, which is specific and distinct from sibling tools that list items or perform actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for quick system overviews but provides no explicit guidance on when to use it versus alternative tools like list_applications or list_queue. No exclusions or conditions are mentioned.
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, description carries full burden. It discloses de-duplication behavior, default date, and return value (bool and total). However, it does not mention side effects, auth requirements, or idempotency. The description is largely transparent but could detail whether existing entries are updated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with key actions front-loaded. Concise without extraneous details. Could be more structured with bullet points, but effectively communicates main points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description already covers return values. Missing context on how record_application differs from submit_application or ledger_summary. For a tool with 7 parameters and many siblings, more completeness is needed to guide correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate but barely does. Only status and date are vaguely mentioned (but no date parameter exists). No explanation for company, role, ats, note, tier, apply_url. Defaults are not explained. This severely hinders correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool appends a row to the application ledger, deduplicated by role. It uses specific verbs and resources ('append one row', 'application ledger'), and distinguishes from siblings like submit_application and list_applications by focusing on logging rather than submitting or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly state when to use vs. alternatives, but implies usage for logging not submitting. Provides context on de-duplication and status vocabulary, helping the agent understand constraints. Lacks direct comparison with submit_application or ledger_summary.
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 burden. It discloses that no browser is driven, PII/credentials are read from environment and never stored, and the return value is a plan with specific components. It does not mention permissions, side effects, or failure modes, but provides sufficient behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, starting with the core purpose. It is efficient and front-loaded. Minor verbosity in detailing the plan contents could be condensed, but overall it is appropriately sized for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema coverage, no annotations, and an output schema, the description is incomplete. It explains the return value well but ignores parameter semantics. It adds context about PII and environment but misses guidance on how to use parameters. It is adequate for a high-level plan but lacks detail needed for accurate invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions 'standard field values' and 'ATS' but does not map to individual parameters like title, company, url, ats, location, resume_path. It does not explain why title, company, url are required or how resume_path is used. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a fill-and-park submission plan for a role, emphasizing it does not drive a browser. It distinguishes itself from sibling tools by stating to report outcomes with record_application afterward, and it details the plan contents (ATS, action, field values, etc.). This is a specific verb+resource combination that differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow: first use submit_application to build a plan, then report outcomes with record_application. It implies the tool is used before recording outcomes. However, it does not explicitly state when to use this tool versus alternatives like build_resume or verify_resume, lacking explicit exclusion criteria.
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 provided, so description carries full burden. It describes that static gates run and returns lint_ok/verify_ok and findings, but doesn't elaborate on failure modes or what happens with invalid fragments. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with a clear front-loaded purpose sentence and a bullet list for parameters. Could be slightly more structured, but no wasteful sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 6 input parameters and mentions return values (lint_ok/verify_ok and findings). Notes that rendering is separate. Missing some context on static gates and error handling, but overall sufficient for a complex tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section explains each parameter in detail, including constraints like valid role_keys and bullet formats. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds a tailored one-page resume from verified fragments and runs static gates. Distinguishes from siblings like render_resume by noting that the 1-page render is separate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly mentions that render_resume handles the 1-page render separately, but does not explicitly state when to use this tool versus verify_resume or other siblings. Lacks explicit when-to-use or when-not-to-use guidance.
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 provided, so description must disclose behavior. It explains return values (value, pursue, reasons, hard_cap) and hard_cap conditions. However, it does not explicitly state that the tool is read-only or has no side effects, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences with no fluff. The first sentence states the core purpose, and subsequent sentences efficiently add detail on parameters and return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and an output schema, the description covers the return structure and hard_cap conditions. It lacks explanation of the 'angle' parameter and the rubric, but the output schema compensates for return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds some meaning by explaining that jd_text is preferred and that title is required. It does not explain url, angle, company, or location, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores a role 0-10 against FIT_RUBRIC.md and returns a pursue verdict. The verb 'score' and resource 'role' are specific, and the tool is well-differentiated from siblings like discover_jobs or build_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises passing JD text when available because titles under- and over-sell, giving clear context on preferred input. It lacks explicit exclusions or comparisons to alternatives, but the guidance is actionable.
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 burden. It explains the curation process, outcomes (KEPT/PARKED), reasons for parking, that nothing is discarded, and the return shape. It could be more explicit about side effects (e.g., whether it modifies the database).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into two paragraphs. Every sentence adds value, though it could be slightly more concise. It is front-loaded with the main purpose and then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thorough for a complex tool, covering process, outcomes, reasons, and return values. It compensates for lack of annotations and schema descriptions. With an output schema present, the description need not explain return format fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters. It does: 'up to `limit` queue entries with the given queue status' clearly defines both parameters. It also mentions default values. However, it does not enumerate possible status values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Triage the discovery queue into a fit-ranked active set and a parked set.' It uses specific verbs ('curate', 'triage') and identifies the resource ('discovery queue'). It distinguishes from sibling tool 'list_queue' which only lists without curation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used after discovery to perform curation, but it does not explicitly state when to use it versus alternatives like 'discover_jobs' or 'list_queue'. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses read-only nature, uses IMAP BODY.PEEK with revocable app password, scoped to known ATS domains, return format {status, code?}, and retry logic. This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary statement, followed by context and usage notes. It is moderately long but every sentence adds value. Could be slightly tighter but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter and an output schema, the description covers behavior, safety, and retry logic comprehensively. The only gap is the undocumented 'minutes' parameter, but overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'minutes' with default 15 and 0% description coverage. The description does not mention this parameter at all, failing to add meaning beyond the schema despite the need to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the newest ATS email-verification code from the applicant's own inbox, using a specific verb and resource. This distinguishes it from sibling tools like submit_application 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (for the emailed-code gate) and when not to use (for captchas or no-AI attestations), and provides retry guidance (wait ~8s, retry up to 3x). This is excellent usage context.
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 that the tool checks two gates and returns specific fields (lint_ok, verify_ok, passed, findings) with examples of findings. It is transparent about what the tool does, though it does not mention side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the core action and the second providing additional detail on output. It is concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single required parameter and the presence of an output schema, the description is complete. It explains what the tool does, what it returns, and provides example findings, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by indicating that the 'path' parameter should point to a resume HTML file on disk. This clarifies the parameter's purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs two static gates (lint + anti-fabrication verify) on a resume HTML. It distinguishes from sibling tools like build_resume and render_resume by specifying the verification purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to check any resume on disk,' which implies when to use, but it does not explicitly state when not to use or mention alternative tools for similar tasks.
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 provided; description covers list behavior, file source, and return limit. Sufficient for a read-only 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, parameter details, usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description adequately covers purpose, parameters, and when to use. Lacks mention of ordering but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description clarifies 'status' is the queue field defaulting to 'todo' and 'limit' controls count. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'List roles in the discovery queue... by queue status' – specific verb and resource, distinct from siblings like discover_jobs or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'before running new discovery' (queue-first gate). Lacks explicit when-not-to-use but provides clear context.
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?
Discloses behavioral traits such as reliance on public posting APIs and possible error returns for unsupported URLs or disabled APIs. Without annotations, the description covers failure modes well but lacks an explicit statement that the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences that are front-loaded with purpose, followed by supported platforms, a rationale for usage, and error handling. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description sufficiently covers purpose, supported inputs, error conditions, and usage rationale. No additional information is needed for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'url' parameter is described in context: expects an ATS URL from supported platforms. This adds substantial meaning beyond the schema's type definition, compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches a posting's title, location, and plain-text JD from ATS URLs. Specifies supported platforms (Ashby, Greenhouse, Lever) and explains why the JD is preferred over title for scoring, distinguishing it from sibling 'score_job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use (to get JD text for scoring) and includes important caveats about error handling and not assuming a role is closed based on board 404. However, it does not explicitly list alternatives among sibling tools.
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 fully discloses that the tool returns the angle's details or null. It implies a read-only operation and covers the edge case of empty input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the purpose and then explain the default behavior. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one optional parameter) and the existence of an output schema, the description sufficiently covers the tool's behavior: it returns angle details or null. It leaves no ambiguity about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaning by explaining the effect of an empty 'name' parameter (returns default lane). This goes beyond the schema's default value declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'look up' and the resource 'search angle (lens)'. It distinguishes itself from sibling tools like list_search_angles by focusing on a single angle retrieval via name or trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that an empty name returns the default lane, providing implicit guidance on when to omit the argument. However, it does not explicitly state when not to use the tool or suggest alternatives.
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 that fragments are verified and trace to CLAIMS_BANK.md, implying a safe, read-only operation. However, it does not explicitly state read-only or performance characteristics, which is acceptable for a zero-parameter list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence adds value. It is concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters and an output schema exists, the description sufficiently explains purpose and usage. It covers the source of fragments and their role, making it complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. According to the rubric, zero parameters baseline is 4. The description adds no parameter info, which is appropriate because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'verified resume building blocks from _genlib.py (roles, bullets, projects)', and specifies the domain. This distinguishes it from sibling tools like build_resume and verify_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: to obtain resume fragments that trace to CLAIMS_BANK.md, and advises building resumes only from these names for output honesty. While it does not explicitly compare to alternatives, the context 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 full burden of behavioral disclosure. It explains that the tool queries public APIs or private scripts, returns ranked de-duped results, and mentions failure modes for private sources. This provides sufficient transparency about the tool's behavior and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-liner summarizing the tool's purpose, then uses a structured bullet-like format for parameter explanations. Every sentence adds value, and there is no fluff. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signals indicate yes), the description doesn't need to detail return values, but it still lists the fields. It covers all parameters, usage context (pairing with other tools), and behavior. For a tool with 3 optional parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does excellently. It explains the 'angle' parameter as a search lens, 'source' as which sweep (with detailed options and behaviors), and 'limit' as max roles. This adds significant meaning beyond the schema's default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find fresh roles from a discovery source, ranked by fit, de-duped by role.' This is a specific verb+resource with additional details (ranked, de-duped) that distinguishes it from siblings like fetch_job_description and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool versus alternatives, such as 'For a much wider net, pair this with the JobDataLake MCP (search_jobs) and feed its results to score_job.' It also explains the different source options and their behaviors. While it doesn't explicitly state when not to use, the guidance is clear and helpful.
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:

[![claude-works MCP server](https://glama.ai/mcp/servers/andrewaws26/claude-works/badges/card.svg)](https://glama.ai/mcp/servers/andrewaws26/claude-works)

Score Badge

Copy to your README.md:

[![claude-works MCP server](https://glama.ai/mcp/servers/andrewaws26/claude-works/badges/score.svg)](https://glama.ai/mcp/servers/andrewaws26/claude-works)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/andrewaws26/claude-works'

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