HR and recruiting: score a job description, or generate a structured role profile. No API key.
Scored across 10 tools
Each tool targets a distinct resource+action: assess vs generate for the write side, and get/list/search operate on clearly separated resources (assessments, private roles, public roles, account). The generate_role/check_role_status pairing is explicitly called out as a poll relationship, and get_role vs get_public_role are distinguished by generated-vs-published in their descriptions.
All ten tools follow a clean verb_noun pattern (assess_job_description, check_role_status, generate_role, get_account_status, get_assessment, get_public_role, get_role, list_my_assessments, list_my_roles, search_public_roles). Verbs are used consistently (get for single fetch, list for collections, search for querying) with no style mixing.
Ten tools is well within the sweet spot and each earns its place: the write/async lifecycle (generate_role, check_role_status), the assessment path (assess_job_description, get_assessment, list_my_assessments), the role read path (get_role, list_my_roles), the public library (search_public_roles, get_public_role), and account context (get_account_status). No filler or redundant tools.
Core lifecycle is covered: assess, generate, poll, fetch, list, and search, plus account/quota introspection. Gaps are minor and likely intentional (generated profiles and assessments are immutable), though there is no delete or update/regenerate operation, and no way to cancel an in-flight generation.
Score a job description from 0-100 on how cleanly it can be turned into a structured role profile, and say what is missing and what to fix. Takes the job description as text. Runs synchronously — the answer comes back on the same request — so allow a generous client timeout. Metered: see get_account_status.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | A label for this document, shown in the account history. | |
| job_description | Yes | The full text of the job description, with each heading and each list item on a line of its own. Working from a PDF or Word file, write it out that way rather than as the text came out of it. Markdown is not needed, but text joined into one paragraph is scored as unstructured, because that is what arrived. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it runs synchronously and is metered, pointing to get_account_status. This adds valuable context about timeouts and usage limits. It doesn't mention error handling or side effects, but for a read-only scoring tool, the disclosed traits are relevant and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded, and the behavioral notes (sync, metered) follow efficiently. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input format (via schema), the synchronous behavior, and the metering. It tells the agent what to expect back (score and feedback). While it doesn't detail error handling or output structure, these are minor for a tool with a clear schema and no output schema. It's complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters in detail, including the formatting instructions for job_description and the purpose of filename. The description adds nothing beyond that, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Score', the resource 'job description', the scale (0-100), and the outcome (say what is missing and what to fix). It is distinct from siblings like generate_role (which creates a role) and get_assessment (which retrieves a previous assessment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention when to prefer it over generate_role or get_assessment, or any prerequisites like having a job description text ready. The only implicit clue is that it scores text, but there's no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a role generation has finished, and return the role profile once it has. Poll this after generate_role.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | "summary" (the default) leaves out each skill's task statements, per-level proficiency indicators and course descriptions, and says so in the response. "full" includes them. | summary |
| role_id | Yes | The role_id returned by generate_role. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does partially discharge it by disclosing asynchronous completion behavior and the fact that a profile is only returned once ready. However, it omits what the response contains while the role is still generating, whether there is a timeout or expected poll interval, and whether repeated polling has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and immediately followed by the usage instruction. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polling tool with no annotations and no output schema, the description covers the essentials (what it checks, what it yields, when to call it) but leaves gaps around the not-yet-ready response shape and any timeout or retry expectations an agent would need to poll correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters — including the enum-trading detail flag and its relationship to skill task statements — are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (role generation status), and adds the key outcome: it returns the role profile once finished. This distinguishes it from siblings like get_role or get_assessment, which retrieve already-available entities rather than completion state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Poll this after generate_role" explicitly names the sibling that produces the state and the trigger condition for calling this tool. It stops short of saying when to stop polling or what to use instead once the role exists (get_role), but the core 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.
Start generating a structured role profile — description, responsibilities, skills with proficiency levels. Returns immediately with a role_id; generation continues in the background, so poll check_role_status. Spends one of this account's role-generation credits. Only one generation runs at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| role_title | Yes | A single job title, e.g. "Staff Data Engineer". Not a list. | |
| company_name | Yes | The organization the role is for. | |
| job_description | No | Full text of a related job description, used as source context. Strongly recommended for titles labor-market data may not recognize. | |
| learning_resources_source | No | Which catalog the suggested courses come from. Ignored when include_learning_resources is false. | Skillsoft |
| include_learning_resources | No | Attach suggested courses to each skill, readable later at result[].skills[].learning_resources. On by default. Turn it off for a shorter profile when nobody is going to act on the training suggestions. | |
| use_job_description_if_title_not_found | No | Build the role from the job description when the title cannot be matched to labor-market data, instead of failing. Defaults to true when job_description is supplied, and has no effect without one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does a strong job: it reveals asynchronous execution, immediate role_id return, background generation, single-flight concurrency, and credit consumption. It stops short of describing failure states or credit exhaustion behavior, but the core side effects are disclosed clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover the action, output, async behavior, cost, and concurrency constraint with zero filler. The most important information—what the tool does and what it returns—is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async generation tool with no output schema, the description explains the immediate return value, background processing, polling path, credit cost, and concurrency limit. A small gap is that it does not mention how to retrieve the final generated profile beyond polling status, but overall the essential operational context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents every parameter. The description adds no parameter-specific meaning, but it does not need to because the schema is self-sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Start generating a structured role profile' and enumerates what the profile contains (description, responsibilities, skills with proficiency levels). It clearly distinguishes this from sibling tools by noting the async pattern and the need to poll check_role_status, so an agent can tell it apart from assess_job_description or get_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when a structured role profile is needed, and it explicitly directs the agent to poll check_role_status afterward. It does not enumerate when-not-to-use alternatives like assess_job_description, but the purpose and follow-up action are unambiguous enough for safe invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report which WorkforceGPT account this credential belongs to, what it is permitted to do, and how much of its quota is left. Call this first: it is how you find out whether a generation will be accepted before you build one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a read-only operation by using 'Report,' and describes what it returns (account, permissions, quota). However, it doesn't explicitly state that it has no side effects or mention any potential failure modes (e.g., invalid credential). Given the simplicity of the tool, this is adequate but could be more explicit about non-mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences with no filler. The first sentence immediately states the purpose and output, and the second provides the usage directive. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with no parameters and no output schema, the description covers the essential information: what it reports and when to call it. It could be improved by mentioning the response format (e.g., JSON, text), but given the tool's simplicity and the guidance to call it first, the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no information to supplement. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what the tool returns rather than parameters. It doesn't need to add parameter-specific details because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it reports the account associated with the credential, its permissions, and quota. The verb 'Report' is specific, and the resource is 'WorkforceGPT account' with explicit details. It is distinct from sibling tools like get_role or check_role_status, which focus on roles rather than account-level status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to 'Call this first' and explains the purpose: 'it is how you find out whether a generation will be accepted before you build one.' This gives clear when-to-use guidance and a rationale, though it doesn't explicitly contrast with alternatives. The 'call first' directive effectively positions it as a prerequisite check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one previously run job-description assessment by id.
| Name | Required | Description | Default |
|---|---|---|---|
| assessment_id | Yes | The id returned by assess_job_description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety and behavior. 'Fetch' implies a read operation, but it does not explicitly state that it is safe, non-mutating, or what happens on errors. It also omits any authentication or permission expectations. For a simple getter, this is adequate but lacks explicit disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core action without any filler. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-id tool with a single parameter and no output schema, the description provides sufficient context: it identifies the resource and the lookup key. It does not explicitly describe the return structure, but 'assessment' implies the content. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter (assessment_id) as the id returned by assess_job_description. The description merely reiterates 'by id' without adding format, range, or usage nuances. With 100% schema coverage, this meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), the resource (a previously run job-description assessment), and the unique identifier (by id). It unambiguously distinguishes from siblings like list_my_assessments (which lists) and assess_job_description (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool retrieves a single past assessment, but it does not explicitly state when to prefer this over alternatives like list_my_assessments or check_role_status. There is no mention of exclusions or selection criteria, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one published role profile from the public library in full. Needs no account.
| Name | Required | Description | Default |
|---|---|---|---|
| short_id | Yes | From search_public_roles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the auth requirement ('Needs no account') and the scope/return nature ('in full'). 'Fetch' implies a read-only operation, which is transparent enough for a simple one-parameter getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry the action, resource, scope, and auth requirement with no filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter public fetch with no nested objects and no output schema, the description covers the key facts: what is fetched, from where, fully, and without an account. It is slightly light on explicit return-shape or error details, but those are less critical for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, short_id, already documents that it comes 'From search_public_roles.' The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), a specific resource ('one published role profile from the public library'), and a scope qualifier ('in full'). The word 'public' clearly distinguishes this from the sibling get_role, which is likely account-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for published profiles in the public library and requires no account. It does not explicitly name alternatives or exclusions, but the public-library framing makes the appropriate use case reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one generated role profile: description, responsibilities, pay, skills with importance and proficiency levels, and the suggested courses per skill when the generation asked for them. detail "full" adds task statements, per-level proficiency indicators and course descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | "summary" (the default) leaves out each skill's task statements, per-level proficiency indicators and course descriptions, and says so in the response. "full" includes them. | summary |
| role_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden: it discloses that some fields are conditionally present and that 'full' changes the payload shape, which is genuine behavioral context. It never states that this is a side-effect-free read, nor what happens for an unknown or still-generating role_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, and the returned payload is front-loaded ahead of the detail-mode qualifier. The first sentence is long but each enumerated field earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry return-value disclosure, and it does enumerate the fields plus the conditional courses and the extra full-mode fields. Remaining gaps are error behavior and how role_id is obtained, which are secondary for a simple read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: role_id is documented nowhere, and the description only implies it selects 'one generated role profile' without stating its origin or format. The detail explanation largely restates the enum description already in the schema, adding conditionality but no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and a specific resource (one generated role profile), and enumerates the payload fields, so the agent knows exactly what comes back. The qualifier 'generated' separates it from the public/job-description siblings, but no sibling is named and it never says how it differs from list_my_roles or get_public_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use statement, no prerequisites, and no mention of alternatives, despite siblings like list_my_roles, check_role_status and get_public_role that could plausibly be confused with it. The only conditional given ('when the generation asked for them') describes payload variance, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this account's recent job-description assessments, newest first, from both this API and the web app.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions ordering and source, and implicitly signals a read operation. However, it does not state whether results are summaries or full details, whether pagination is handled, or any limitations like rate limits. For a simple list tool this is moderately transparent, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any filler. Every clause adds information: scope, resource, ordering, and source. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the core purpose and unusual aggregation across API and web app. It does not describe the shape of returned assessments, which could be useful, but it is largely complete given the tool's simplicity and the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter (limit), and the description does not mention it at all. The schema itself provides type, default, and range, so the agent can infer meaning, but the description adds no value in explaining when or how to set limit. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), a specific resource (this account's recent job-description assessments), and adds ordering (newest first) and source scope (from both this API and the web app). This clearly distinguishes it from siblings like get_assessment (single item) and assess_job_description (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for listing assessments but does not explicitly contrast it with get_assessment or state when to prefer one over the other. It also lacks guidance on when not to use it. The 'recent' qualifier and source mention give context, but no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the role profiles on this account, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does add behavioral detail: results are scoped to 'this account' and ordered 'newest first.' It does not disclose how status or limit affect behavior, whether pagination exists, or whether this is purely read-only, but 'List' implies a non-destructive read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the resource, the scope, and the ordering with economy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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 two undocumented optional parameters, the description is too thin. It omits the meaning of the status filter, how limit works, and what the returned role profiles look like, leaving the agent without essential call-construction information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention limit or status at all. The agent must infer the meaning of status from the enum values alone, and the description adds no value for either parameter beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('role profiles on this account') and adds the ordering detail 'newest first.' It distinguishes from public-role siblings by the 'on this account' scope, though it does not explicitly name an alternative or contrast with get_role/search_public_roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on this account' implies this tool is for the caller's own role profiles, which gives some usage context. However, there is no explicit guidance about when to prefer this over get_role, search_public_roles, or list_my_assessments, and no exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public WorkforceGPT role library — role profiles their authors chose to publish. Needs no account. Use it for examples of what a generated profile looks like, or for prior art on a title.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Matches role titles. Omit to browse the most recently published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals that results are publicly published profiles and that no account is needed, and 'search' and 'browse' imply read-only behavior. It does not disclose result shape, pagination, or rate-limit behavior, but for a simple search this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the tool's purpose and use cases without padding. Every clause contributes useful information, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two optional parameters and no output schema, the description covers purpose, access requirements, and use cases well. It could more explicitly describe what fields a returned role profile contains, but the phrase 'role profiles' plus search-by-title is enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: query is described in the schema, and the description does not add meaning for the limit parameter. The limit field is simple enough to infer from its type, default, min, and max, but the description itself adds no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource: 'Search the public WorkforceGPT role library'. It also clarifies this is a lookup of author-published profiles and explicitly notes it requires no account, separating it from account-scoped siblings like list_my_roles get_role, or get_public_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete reasons to use the tool: finding examples of generated profiles or prior art on a title. 'Needs no account' tells an agent it is the right choice in no-authentication contexts, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_role_status1 field changedInput schema / properties / detailAdded value: +{
+ "default": "summary",
+ "description": "\"summary\" (the default) leaves out each skill's task statements, per-level proficiency indicators and course descriptions, and says so in the response. \"full\" includes them.",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "type": "string"
+}get_role1 field changedInput schema / properties / detailAdded value: +{
+ "default": "summary",
+ "description": "\"summary\" (the default) leaves out each skill's task statements, per-level proficiency indicators and course descriptions, and says so in the response. \"full\" includes them.",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "type": "string"
+}assess_job_description1 field changedInput schema / properties / job_description / descriptionPrevious value: -"The full text of the job description."New value: +"The full text of the job description, with each heading and each list item on a line of its own. Working from a PDF or Word file, write it out that way rather than as the text came out of it. Markdown is not needed, but text joined into one paragraph is scored as unstructured, because that is what arrived."assess_job_descriptioncheck_role_statusgenerate_roleget_account_statusget_assessmentget_public_roleget_rolelist_my_assessmentslist_my_rolessearch_public_rolesScore and tailor your CV/resume against a job posting — for AI agents and humans, no-login trial.
Query professional profiles, search candidates, and get AI-powered summaries and job fit analysis.
AI resume triage for recruiters. Query your candidate pool from Claude or ChatGPT.
Free ATS resume score and job-match checker: scores a resume against a job description.
Add one secure layer between your agents and this server.
