Jobs by Workable MCP server. Access over 150K jobs & thousands of companies listed on the job board.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 10 of 10 tools scored.
Each tool targets a distinct resource and action, with clear boundaries between search, recommendations, and recent searches. The descriptions resolve any potential overlap, making misselection unlikely.
All tool names follow a consistent action_noun pattern in snake_case. Get operations use 'get_', while update, withdraw, and search operations use their respective verbs, maintaining a predictable convention.
With 10 tools, the server is well-scoped for its purpose, covering job search, application management, and profile handling without unnecessary bloat or a thin surface.
The toolset covers job search, job details, profile retrieval/update, and application withdrawal. However, there is no direct 'apply' tool, which is a notable gap in a job-focused server, though agents can work around it via external links.
get_companyGet companyAGet the full profile of a company by its id (Workable UUID or database _id), including open job listings.
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | Company id — accepts either the Workable UUID or the database _id (returned as company.id by other tools) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| logo | No | |
| name | Yes | |
| slug | Yes | |
| website | No | |
| openJobs | Yes | |
| description | No | |
| openJobsUrl | Yes | |
| openJobCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, which cover the safety profile and world assumptions. The description adds that the tool returns open job listings, but it does not disclose additional behavioral traits such as error handling, rate limits, or data freshness. With annotations present, this is a baseline score.
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, well-structured sentence that front-loads the core action and includes essential detail (ID types, output content). No unnecessary words or repetition.
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?
Given the tool's low complexity (one parameter, output schema present, annotations included), the description sufficiently conveys the return content and ID semantics. The presence of a complete output schema means return values need not be elaborated further.
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%, and the parameter 'companyId' already thoroughly describes accepting either a Workable UUID or database _id. The description merely echoes this information without adding new meaning, so the baseline score 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 clearly states the verb (Get), resource (company), and scope (full profile including open job listings). It is specific and distinguishes itself from sibling tools by focusing on the company entity with a particular ID format.
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?
Usage is implied by the purpose: call this when you need a company's full profile by ID. However, there is no explicit guidance on when to use it over alternatives (e.g., get_job) or any exclusions. The description does not mention when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobGet jobAGet the full details of a single published job by its advertising UID.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Advertising UUID of the job (accepts full or shortened form) |
| Name | Required | Description |
|---|---|---|
| uid | Yes | |
| title | Yes | |
| company | No | |
| applyUrl | No | |
| benefits | No | |
| location | No | |
| workplace | No | |
| department | No | |
| description | No | |
| requirements | No | |
| employmentType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety and data-completeness aspects. The description adds 'published' as a behavioral constraint (likely only published jobs are accessible) and clarifies the ID type as 'advertising UID,' which is useful context beyond the schema. No contradictions found.
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 information without any fluff. Every word earns its place, and it 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?
Given the tool's simplicity (one parameter, read-only annotations, and an output schema provided), the description is sufficient. It specifies the key qualifier 'published' and the unique identifier, while the output schema handles return-value expectations. No additional context is needed.
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%, and the parameter 'uid' is well documented in the schema ('Advertising UUID of the job (accepts full or shortened form)'). The tool description's mention of 'advertising UID' adds no new meaning, so a baseline score 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?
The description clearly states the verb ('Get'), resource ('full details of a single published job'), and the exact identifier ('advertising UID'). It distinguishes itself from siblings like 'get_job_locations' by covering full details rather than just locations, making the tool's purpose immediately obvious.
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 'single published job by its advertising UID' implies when to use this tool: when you already have a specific job UID. The context is clear, though it does not explicitly compare against siblings like 'search_jobs' or 'get_recommendations'. No exclusions are mentioned, but the scope is implicitly understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_locationsGet job locationsAList city/country pairs where jobs are published. Optionally filter by a partial city or country name. Supports pagination via after_key.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Maximum number of location buckets to return (default 100) | |
| after | No | Pagination cursor from a previous response after_key | |
| query | No | Partial city or country name to filter by (case-insensitive prefix match) |
| Name | Required | Description |
|---|---|---|
| after_key | No | |
| locations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already known. The description adds behavioral detail about filtering semantics (case-insensitive prefix match) and pagination via after_key, which is useful beyond the annotations. No contradictions found.
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 two sentences: the first states the primary action and resource, the second covers filtering and pagination. Every word earns its place, and it is appropriately sized for the tool's simplicity.
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?
Given the simplicity of the tool (3 optional parameters, output schema present, strong annotations), the description fully covers purpose, filtering, and pagination. It is complete for an agent to select and invoke the tool correctly without needing additional 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 input schema has 100% description coverage for all three parameters, and the description restates the query and pagination concepts without adding new syntax or details. It provides a helpful high-level summary but does not go beyond what the schema already explains.
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 ('List') and identifies the resource ('city/country pairs where jobs are published'), clearly distinguishing it from sibling tools like get_job or search_jobs. It also mentions optional filtering and pagination, which further clarifies its scope.
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 provides clear context on what the tool does and how to use it (listing normalized locations, optional partial name filtering, pagination support). It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate use cases given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_applicationsGet my applicationsAList your submitted job applications, most recent first, paginated. Each item includes jobOpen, indicating whether the job is still open. Recruiting-pipeline stages (in_review, interviewed, offered, rejected) are not tracked here.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number; 10 applications per page (default 1) |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| hasMore | Yes | |
| pageSize | Yes | |
| totalItems | Yes | |
| totalPages | Yes | |
| applications | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description credit for adding ordering ('most recent first'), pagination behavior, and the specific field jobOpen, plus the limitation about pipeline stages. This enriches beyond structured data, though not exhaustive (auth, rate limits not mentioned but not critical for 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then key behavioral notes; no fluff.
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?
Given low complexity, one documented parameter, output schema present, and read-only annotation, the description covers purpose, ordering, pagination, a field, and a limitation, making it effectively complete.
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?
Input schema has 100% coverage for the single 'page' parameter, including default and page size, so the description adds no parameter-specific detail. Baseline 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?
Description uses specific verb 'List' and resource 'your submitted job applications', clearly distinguishing from sibling get_* tools. The phrase 'most recent first' adds scope/ordering.
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?
States the tool is for your own submitted applications and explicitly excludes recruiting-pipeline stages ('not tracked here'), which is a clear when-not. However, it does not name an alternative tool for pipeline tracking, warranting a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_profileGet my profileAGet your candidate profile: name, contact details, headline, summary, resume, education and experience.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming a safe read operation. The description adds the specific content fields (contact details, resume, etc.) but does not disclose behavioral details like authentication requirements or error handling, which are not needed given the simple read-only nature.
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?
One concise sentence that is front-loaded with the action ('Get your candidate profile') and lists the content, with no unnecessary 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 no-parameter read tool, the description lists the key profile components, making it clear what output to expect. It does not mention authentication explicitly, but 'your' implies the authenticated user. Given the simplicity, it is sufficiently complete.
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?
There are no parameters, so the description has nothing to add. The empty schema already provides full 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 clearly states the tool retrieves the authenticated user's candidate profile, listing the specific sections included. This distinguishes it from sibling tools like get_job or get_company.
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 use when you need the current user's profile data. No explicit exclusions or alternatives are mentioned, but the tool name and description are self-explanatory, making the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_searchesGet recent searchesAList popular/recent job search terms, tailored to your last known location, with a URL to run each search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| searches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that results are tailored to the user's last known location and that each result includes a URL to run the search. This adds behavioral context not available from annotations or schema, without contradicting the readOnlyHint.
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 starts with the active verb 'List' and conveys the tool's purpose efficiently. Every element—popular/recent terms, location tailoring, URLs—earns its place with no redundancy or filler.
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 no-parameter, read-only tool with an output schema, the description covers all essential behavioral aspects: what it lists, location tailoring, and the URL affordance. The output schema handles return value details, so the description is sufficiently complete for an agent to select and invoke the tool 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 input schema is empty and schema coverage is effectively 100%. Per the rubric, the baseline for 0-parameter tools is 4, and the description appropriately focuses on behavior rather than parameter semantics since there are none to explain.
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 lists popular/recent job search terms, using a specific verb ('List') and a distinct resource (search terms). It differentiates from siblings like search_jobs and get_recommendations by focusing on search terms themselves, not job results, and adds location-tailoring and URL provision as unique features.
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 usage when you want to see popular/recent search terms, but it does not explicitly contrast with sibling tools like search_jobs or get_recommendations, nor does it state when not to use it. The context is implicit rather than clearly differentiated, so it does not fully satisfy 'when vs alternatives' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recommendationsGet recommendationsAGet personalized job recommendations for you. Recommendations are matched to your profile (skills, education, experience) and exclude jobs you have already applied to. If your profile is incomplete, recommendations fall back to jobs near your location.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recommendations to return (default 10) | |
| pageToken | No | Opaque cursor returned as nextPageToken from a previous call; pass it to fetch the next page |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| nextPageToken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavioral details beyond that: it excludes applied jobs and falls back to location-based recommendations if the profile is incomplete. This provides valuable context without contradicting annotations.
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 three concise sentences, each earning its place: the first states the core purpose, the second explains matching and exclusions, and the third describes fallback behavior. No fluff or redundant information.
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 main functionality, exclusion logic, and fallback behavior, which is sufficient for a recommendation tool. An output schema exists, so return-value details are handled elsewhere. The description is complete for the agent to select and invoke the tool 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?
Both parameters (limit and pageToken) already have descriptions in the input schema, giving 100% schema coverage. The description does not mention parameters, but the baseline is 3 when schema carries the semantic load, so no deduction is warranted.
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 'Get' with resource 'personalized job recommendations', and explains the personalization based on profile (skills, education, experience) and exclusion of already applied jobs. This clearly distinguishes it from sibling tools like search_jobs and get_my_applications.
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 provides clear context that this is for personalized recommendations based on the user's profile, and notes fallback behavior for incomplete profiles. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsSearch jobsASearch published jobs on the Workable job board.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search across job title, description, skills, company, name | |
| location | No | City, region, or country to filter by | |
| companyId | No | Restrict to a single company by id | |
| day_range | No | Restrict to jobs posted in the last N days | |
| pageToken | No | Opaque cursor returned as nextPageToken from a previous call; pass with the same filters to fetch the next page | |
| workplace | No | Filter by workplace types | |
| employment_type | No | Filter by employment types |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| totalItems | Yes | |
| nextPageToken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and unpredictability aspects are covered. The description adds the 'published jobs' status filter, which is useful behavioral context, but it does not mention pagination, result ordering, or rate limits. It provides modest value beyond the annotations without contradicting them.
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 short sentence that is immediately understandable, front-loads the verb and resource, and contains zero filler or redundant information.
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 a detailed input schema, an output schema, and annotations, the description only needs to convey the core search purpose and scope. It does so effectively, and the 'published jobs' qualifier adds relevant context. The description is sufficient for an agent to understand when to invoke this tool, though it could have briefly mentioned pagination.
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%, with every parameter fully described in the input schema. The tool description itself adds no additional parameter-level semantics. Given the complete schema, a baseline score 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?
The description states a specific verb ('Search'), a specific resource ('published jobs'), and a clear scope ('Workable job board'). It clearly differentiates from sibling tools like get_job (which fetches a single job) by implying a broad search across multiple jobs, and from get_recommendations by focusing on the global job board.
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 usage by stating what the tool does, but it does not explicitly mention when to use it versus alternatives such as get_job or get_recommendations. There is no exclusionary language (e.g., 'for a specific job, use get_job'), leaving the agent to infer the appropriate context from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_my_profileUpdate my profileAInspectUpdate your candidate profile: name, phone, location, education, and work experience.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | No | Phone number | |
| address | No | Postal address or location | |
| lastname | No | Last name | |
| education | No | Full education history — replaces existing list | |
| firstname | No | First name | |
| experience | No | Full work experience — replaces existing list |
| Name | Required | Description |
|---|---|---|
| phone | No | |
| address | No | |
| lastname | No | |
| education | No | |
| firstname | No | |
| experience | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description simply says 'Update your candidate profile' without mentioning that education and experience arrays replace existing lists (the schema does say this), nor any other behavioral nuances. Annotations are all false and don't provide additional context. The description adds little beyond the surface-level field list, missing the replacement behavior.
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?
Single sentence, 12 words, front-loaded with 'Update'. Efficient and free of unnecessary detail.
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 schema is rich and covers parameter semantics well, and an output schema exists, so the description doesn't need to explain return values. The main gap is not explicitly stating the replace-all behavior, but the schema property descriptions cover it. Overall, the definition is mostly complete for a straightforward update 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?
Input schema provides 100% coverage with descriptions for all 6 parameters, including details like 'Full education history — replaces existing list' and ISO date formats. The description only mentions field names in general, adding no additional parameter semantics beyond what the schema already documents.
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?
Description clearly states the verb ('Update') and resource ('your candidate profile'), and lists the fields (name, phone, location, education, work experience). This distinguishes it from sibling get_my_profile (read) and other getters.
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 is for updating profile fields, but it doesn't explicitly contrast with reading via get_my_profile or specify when not to use it. No alternatives or exclusions are mentioned, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
withdraw_applicationWithdraw applicationAWithdraw one of your submitted job applications by its application id. This action cannot be undone from here.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationId | Yes | Application identifier, as returned by get_my_applications |
| Name | Required | Description |
|---|---|---|
| withdrawn | Yes | |
| applicationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the crucial context that the action 'cannot be undone from here,' which is more specific than the generic destructive flag. No contradiction with annotations.
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 two concise sentences: the first states purpose, the second warns about irreversibility. Every sentence adds value, and there is no redundancy or fluff.
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 single-parameter destructive tool with an output schema, the description covers the essential purpose, usage, and irreversibility. It does not elaborate on post-conditions or restrictions, but nothing critical is missing given 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 has 100% coverage for the single parameter applicationId, with a clear description ('as returned by get_my_applications'). The tool description only repeats 'application id' without adding new semantic detail, 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?
The description clearly states the tool's purpose: 'Withdraw one of your submitted job applications by its application id.' It uses a specific verb (withdraw) and resource (job applications), and the reference to 'your submitted' distinguishes it from the getter and search siblings.
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 when to use it (to withdraw a specific application) and includes a warning about irreversibility. It does not explicitly list alternatives or exclusion criteria, but the context is clear enough for a simple action. The schema's note about the id coming from get_my_applications further clarifies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
