Workopia — Job Search
Server Details
Search 6.3M+ live jobs from companies' own career pages, plus resume tailoring & cover letters.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.7/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: job search (job_tool), job details (job_detail_tool), dashboard (dashboard_tool), resume tailoring (tailor_resume_tool), and cover letter generation (cover_letter_tool). Even with similar two-step patterns in resume and cover letter tools, the descriptions and outputs are distinct, preventing confusion.
All tool names follow a uniform pattern of descriptive phrase (often verb_noun) followed by '_tool' (e.g., cover_letter_tool, job_detail_tool). This consistency makes the tool set predictable and easy to navigate.
With 5 tools, the server covers essential job search operations (search, detail view, resume tailoring, cover letter, dashboard) without being bloated or sparse. Each tool serves a clear, necessary function.
The tool set is fairly complete for the job search domain, covering search, viewing, tailoring, cover letters, and user dashboard. Missing features like a direct 'apply' tool or more granular job management are minor gaps, but core workflows are well-supported.
Available Tools
5 toolscover_letter_toolADestructiveInspect
Write a cover letter for a SPECIFIC job — TWO steps. STEP 1 (default; action omitted or 'prepare'): the server returns the job's JD and the candidate's background, plus writing instructions. YOU (the model) then WRITE the cover letter (250–350 words, specific to the role, mapping the candidate's real achievements to the JD — never fabricate). STEP 2: call this tool again with action:'save', cover_letter_text:, and job_id — the server renders a PDF and saves it to the candidate's Workopia dashboard (requires sign-in). Use whenever the user asks for a cover letter for a specific job. Resolving job_id (same rules as tailor_resume_tool / job_detail_tool): pass the Job Id value from the most recent prior search/refine result VERBATIM; no placeholders like 'JOB_1' or '#1'. For STEP 1 supply ONE of job_id (preferred — server fetches the JD from Mongo) OR job_description, plus the candidate's resume via resume_text / resume_content / json_resume / user_profile.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Omit or 'prepare' = STEP 1 (server returns JD + background + instructions for you to write). 'save' = STEP 2 (pass cover_letter_text; server renders a PDF and saves it to the dashboard; requires sign-in). | |
| job_id | No | ID of a job from a prior search/refine result. Use the **Job Id** value from the prior search result's content text VERBATIM. Server fetches full JD from Mongo. | |
| company | No | Optional; used in the confirmation line. | |
| job_title | No | Optional; used in the 'for <role> at <company>' confirmation line. | |
| parameters | No | ||
| session_id | No | ||
| user_email | No | If provided, server fetches the full Workopia profile for the cover letter header + writes the generated cover letter back to profile.applications[jobId].coverLetter. | |
| json_resume | No | Optional JSON Resume object (basics/work/skills). Takes precedence over resume_text when both present. | |
| resume_text | No | User's resume content (plain text or JSON Resume as string). | |
| cover_letter | No | Optional wrapper containing the same fields above (legacy shape). | |
| user_profile | No | Optional main-site profile object; used as a fallback source for summary/skills/experience and for the cover letter header (firstName, lastName, email, phone, city, country). | |
| resume_content | No | ||
| job_description | No | Full JD text when the user pastes it directly (alternative to job_id). | |
| cover_letter_text | No | STEP 2 only: the cover letter you wrote (plain text). The server renders it to PDF and stores it on profile.applications[job_id].coverLetter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the two-step process, including that step 1 returns JD and background, step 2 saves a PDF to the dashboard (requires sign-in). This goes beyond the annotations (destructiveHint=true) by detailing the write behavior and prerequisites.
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 well-structured with clear step markers and front-loaded summary. However, it is lengthy and contains some repetition of schema descriptions, which could be trimmed slightly without losing clarity.
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 all necessary contextual aspects: the two-step protocol, parameter usage rules, data source options, and references to sibling tools for consistency. Without an output schema, the explanation of what the server returns (JD, background, instructions) is sufficient.
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?
With schema coverage at 79%, the description adds significant meaning: it explains the action enum values, the requirement to pass job_id verbatim from prior results, the precedence of json_resume over resume_text, and how user_profile serves as a fallback. This greatly aids parameter understanding.
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: writing a cover letter for a specific job in two steps. It uses specific verbs ('Write', 'save') and resources ('cover letter'), and distinguishes from sibling tools by referencing 'tailor_resume_tool' and 'job_detail_tool' for job ID resolution.
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 says 'Use whenever the user asks for a cover letter for a specific job.' It provides detailed guidance on step selection via the 'action' parameter and alternatives for providing job info. However, it lacks explicit 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dashboard_toolARead-onlyInspect
Show the signed-in user's Workopia dashboard (saved, tailored, and applied jobs + latest resume). Requires OAuth. Default action is list; optional status_filter (all | saved | tailored | applied). Use whenever the user asks to recall their Workopia activity: 'my applications', 'what jobs have I saved / applied to / tailored', 'show my dashboard', 'where did I leave off'. Returns a secure link to open the full dashboard on the web.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| status_filter | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=true and destructive=false, which is consistent. The description adds that OAuth is required and that the tool returns a secure link to the full dashboard online, providing valuable behavioral context beyond 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 relatively concise, covering purpose, usage, and output in a few sentences without extraneous detail. It could be slightly more structured but is efficient.
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 (2 enum params, no output schema), the description thoroughly covers purpose, usage, parameter meaning, and output. The absence of output schema is mitigated by describing the return of a secure link.
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 has 0% field descriptions, but the description compensates by explaining the status_filter options (all, saved, tailored, applied) and noting the default action. This adds clear meaning beyond the raw schema.
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 shows the signed-in user's Workopia dashboard with specific sections (saved, tailored, applied jobs, latest resume). It includes example user queries that make the purpose unmistakable.
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 says 'Use whenever the user asks to recall their Workopia activity' and provides concrete examples. It does not explicitly exclude alternative tools but gives strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_detail_toolARead-onlyInspect
Render the full job-detail card for a specific job the user asks about. Use this whenever the user references a particular job from a prior search result — by number (#1, '1', 'first', 'the 3rd one', 'job 3'), by company name (partial or full, e.g. 'Morgan Stanley', 'Morstan'), by role/title phrase ('the analyst role', 'the credit risk one'), or by any 'show me this job' / 'tell me more about X' / 'view this role' style request. Resolving job_id from user reference: identify the right job from the most recent prior search/refine result (the numbered list you generated): (a) numeric/ordinal → the Nth job; (b) company name → substring match on Company field; (c) role/title phrase → substring match on Job Title field. Then pass that job's Job Id value from the prior search result's content text VERBATIM as job_id. Do NOT use a placeholder like 'JOB_1', '#1', or any synthetic id — only the real Job Id string from the prior result is server-valid. Required: job_id. OUTPUT BEHAVIOR: Render the response as a structured markdown card with the job's title (linked to the apply URL), company, location, salary, employment type, work mode, must-have skills, key requirements, highlights, and summary. Follow it with a brief next-step hint (e.g. 'Want to save it, find similar roles, ask about the company, or tailor your resume for this role?').
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | The id from a prior search result's job_cards[].card.id. Required. | |
| parameters | No | ||
| user_email | No | ||
| get_job_detail | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond annotations: 'Render the response as a structured markdown card with specific sections' and 'Follow it with a brief next-step hint'. Annotations already declare readOnlyHint=true, and the description confirms read-only behavior without contradiction.
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 well-structured with clear sections: purpose, usage resolution, output behavior. It is front-loaded with purpose. While slightly lengthy, every sentence adds value for agent execution.
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 read-only detail tool without output schema, the description covers the main parameter thoroughly and describes the output format and next-step hint. It lacks documentation for non-job_id parameters but is mostly complete for its intended use.
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 low (25%), so the description must compensate. It provides extensive semantics for job_id: how to resolve from user references, must be verbatim from prior result, not synthetic. However, it does not mention the other three parameters (parameters, user_email, get_job_detail) or their roles, leaving a gap.
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 'Render' and resource 'full job-detail card' for a specific job. It distinguishes from siblings like job_tool (likely search) by specifying it's for viewing details of a single job from prior search results.
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 states when to use: 'whenever the user references a particular job from a prior search result'. It provides detailed resolution methods by number, company name, or role phrase. However, it doesn't explicitly state when not to use or mention alternatives within the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_toolADestructiveInspect
Search jobs across 90+ countries by title, location, salary, remote/hybrid work mode, or employment type. Find roles in tech, finance, product, design, marketing, and every other vertical — aggregated from 1000+ ATS sources globally. Default action is search; use refine when the user asks for more matches or gives feedback on a prior result set; use save to bookmark a job for the signed-in user (requires OAuth). REFINE PROTOCOL (action=refine has THREE distinct modes): (1) Pure continuation / 'show me more' / 'next batch' / 'another set' / 'more like these': pass refine_recommendations.exclude_ids = the full array of Job Id values from the most recent search/refine result's content text (verbatim) + refine_recommendations.session_id = prior response's session_id if present. Server returns next 10 unique jobs. (2) 'Show me more like #N' / 'similar to the Atlassian one' / 'jobs like #2': pass refine_recommendations.liked_indexes = [N] (1-based position from prior numbered list) + exclude_ids + session_id. Equivalently you may pass refine_recommendations.liked_job_ids = [<that job's **Job Id** value verbatim>]. Server seeds the recommendation from that job's title/skills/company profile. (3) 'Less like #N' / 'no more N-style jobs' / 'avoid jobs like that': pass refine_recommendations.disliked_indexes = [N] (or disliked_job_ids = []) + exclude_ids + session_id. Server suppresses similar jobs. All three modes: if you skip exclude_ids, the user sees duplicates — that's a failure. The handler layers exclude_ids with server-side AgentKit memory, so partial lists still work. NEVER invent 'JOB_1' / '#1' as job_id values — always use the real Job Id string from the prior result's content text. For detail requests (user asks about a specific job from the list, e.g. 'details for #1', 'show me this job', 'tell me more about '), DO NOT call this tool — call job_detail_tool instead. That separate tool binds to the job-detail widget card so the full job card renders in chat. OUTPUT BEHAVIOR: Render the search results as a numbered markdown list, one line per job, in this exact compact format: N. **[Job Title](View_Job_URL)** — Company · Location · Job Type · Compensation · Posted MMM DD. Embed the View Job URL as a markdown link on the title (so the user can click to apply). Keep URLs intact — don't strip parameters. Skip a field entirely if it's missing — never print 'N/A' placeholders. The numbered list IS the canonical user-facing answer. REQUIRED follow-up: after the list, output EXACTLY these two sentences as two parallel questions (same pattern for action=search and action=refine): Sentence 1 — 'Would you like to see full details on any of these? Reply with the number (#1), the company name, or the role title.' Sentence 2 — 'Or would you like to refine the list — what should change (work mode, level, salary, sector)?' These two sentences must be separate and parallel; do NOT merge them into one 'detail ... or refine' clause (that buries the detail CTA). Both questions must be asked every time after a search or refine result. When the user replies referring to a specific job from the list, identify which job they mean and call job_detail_tool immediately. Identifying the job (use flexibly — users rarely type '#N' literally): (a) any numeric or ordinal reference ('#1', '1', 'first', 'the 1st', 'top one', 'job 3', 'the third') → the Nth job in your prior numbered list; (b) a company name, partial or full ('Morgan Stanley', 'Morstan', 'Capital One') → case-insensitive substring match on the Company field of the prior list, pick the first match; (c) a role/title phrase ('the analyst role', 'the credit risk one') → case-insensitive substring match on the Job Title field. If multiple jobs match, prefer the earliest. Only if no reasonable match exists, ask a one-line clarifying question. Then pass that job's Job Id value from the prior search result's content text VERBATIM as job_id to job_detail_tool / tailor_resume_tool / cover_letter_tool. Do NOT invent a placeholder like 'JOB_1' or '#1' — those are not server-valid IDs. For save, pass job_id + optional job_title/company/job_url in save_job. Put search fields in search_jobs or parameters; refine in refine_recommendations; save in save_job.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Optional; omitted = search. refine = after results/feedback; save = bookmark a job for the signed-in user. | |
| save_job | No | Save args. Required: job_id (from job_cards[].card.id in a prior search result). Optional: job_title, company, job_url. | |
| parameters | No | ||
| search_jobs | No | Search args. Required: city. Optional filters surface only when the user explicitly mentions them — omit otherwise. job_title+city uses indexed snapshot; company+city (optional job_title) uses legacy DB match. | |
| refine_recommendations | No | Refine args. Pass exclude_ids (array of Job Id strings from prior result) and session_id always. For 'more like #N': pass liked_indexes=[N] or liked_job_ids=[<Job Id>]. For 'less like #N': pass disliked_indexes=[N] or disliked_job_ids=[<Job Id>]. job_title/city optional — auto-filled from prior search via session memory. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true, but the description goes far beyond by detailing the output behavior (numbered markdown list format), the required follow-up questions, and the three modes of the refine protocol with specific parameter usage. No contradictions 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 lengthy but well-structured into sections (search, refine, save, output, follow-up, job identification). Every sentence adds value, but it could be slightly more concise without losing critical guidance. Given the tool's complexity, the length is justified, but a bit of trimming would push it to 5.
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 all essential aspects: usage scenarios, parameter details, output format, follow-up actions, and error handling (e.g., avoiding duplicate job IDs). It includes nuanced instructions like how to identify jobs from user references flexibly (numeric, company name, role title). No output schema exists, but the description compensates fully.
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?
With 80% schema coverage, the description adds significant extra meaning beyond the schema. For example, it specifies exact key names for city and job_title, explains when to pass or omit workMode and employmentType, and details the refine parameters like exclude_ids, liked_indexes, etc. This compensates for the remaining 20% and ensures correct parameter usage.
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 searches jobs across 90+ countries with multiple filters. It distinguishes itself from sibling tools like job_detail_tool by specifying when to use each: 'For detail requests... DO NOT call this tool — call job_detail_tool instead.' The verb 'Search jobs' is specific and the scope is well-defined.
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?
Explicitly provides when to use each action: default is search, refine for more matches/feedback, save for bookmarking. It also tells when NOT to use: for job details, use job_detail_tool. Additionally, it covers alternative tools like cover_letter_tool and tailor_resume_tool for after job identification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tailor_resume_toolADestructiveInspect
Tailor a resume to a SPECIFIC job — TWO steps. STEP 1 (default; action omitted or 'prepare'): the server returns the job's full JD, its must-have skills/requirements, and the candidate's current resume, plus tailoring instructions. YOU (the model) then WRITE the tailored resume as JSON Resume, following the instructions — weave JD keywords into existing bullets only where the candidate genuinely has the experience, never fabricate experience/titles/dates/employers, keep all dates and company names, and flag any keyword you couldn't honestly add. STEP 2: call this tool again with action:'save', tailored_resume:, and job_id — the server renders a PDF and saves it to the candidate's Workopia dashboard (requires sign-in). Use whenever the user references a specific job to tailor for: 'tailor for #1', 'for Morgan Stanley', 'tailor my resume for this role: '. Resolving job_id (same rules as job_detail_tool): from the most recent prior search/refine result — (a) numeric/ordinal → the Nth job; (b) company name → Company-field match; (c) role/title phrase → Job-Title match — then pass that job's Job Id value VERBATIM. Do NOT use placeholders like 'JOB_1' or '#1'. For STEP 1 supply ONE of job_id (preferred — server fetches the JD from Mongo) OR job_description, plus the candidate's resume via resume_text / resume_content / resume_data. For general 'improve my resume' (no specific job), do NOT call this tool — call resume_tool action=improve instead. Note: the tailored resume is written by your AI client's own model — the assistant you are already using — so it works out of the box with nothing to configure; Workopia runs no LLM of its own and never charges for the AI.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Omit or 'prepare' = STEP 1 (server returns JD + resume + instructions for you to tailor). 'save' = STEP 2 (pass tailored_resume; server renders a PDF and saves it to the dashboard; requires sign-in). | |
| job_id | No | ID of a job from a prior search/refine result. Use the **Job Id** value from the prior search result's content text VERBATIM. Server fetches full JD from Mongo. | |
| company | No | ||
| job_title | No | ||
| parameters | No | ||
| session_id | No | ||
| user_email | No | ||
| resume_data | No | PREFERRED shape — structured resume per utils/tailor/types.ts ResumeTree. Server, widget, and main-site PDF template all consume this exact shape. Collect these fields from the user before calling when possible. | |
| resume_text | No | User's resume content (plain text or JSON Resume as string). Fallback when resume_data is not provided. | |
| user_profile | No | Optional main-site profile object; used as a fallback source for name/title/contact/experience when resume_data and resume_text are both absent. | |
| tailor_resume | No | Optional wrapper containing the same fields above (legacy shape). | |
| resume_content | No | ||
| job_description | No | Full JD text when the user pastes it directly (alternative to job_id). | |
| tailored_resume | No | STEP 2 only: the tailored resume you generated, as a JSON Resume object (or a JSON string). The server renders it to PDF and stores it on profile.applications[job_id].resumeTailor. | |
| customization_level | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds behavioral context: 'the server renders a PDF and saves it to the candidate's Workopia dashboard (requires sign-in),' warns against fabricating experience, and explains the two-step process. 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 long but well-structured, front-loading the two-step process. It includes detailed instructions for the model and job_id resolution. While some detail could be trimmed, it remains clear and organized for a complex tool.
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 15 parameters, no output schema, and nested objects, the description is thorough. It covers the entire workflow, parameter choices, behavioral constraints, and authentication needs, providing complete context for an AI agent.
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?
Despite only 53% schema description coverage, the description compensates by explaining parameter usage per step: 'For STEP 1 supply ONE of job_id OR job_description, plus the candidate's resume via resume_text / resume_content / resume_data.' It also clarifies the tailored_resume parameter for STEP 2, adding meaning beyond the schema.
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: 'Tailor a resume to a SPECIFIC job — TWO steps.' It specifies the verb 'tailor' and the resource 'resume' to a job, distinguishing it from sibling tools like cover_letter_tool or job_detail_tool.
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 explicit when-to-use scenarios (e.g., 'tailor for #1', 'for Morgan Stanley') and when-not-to-use ('For general improve my resume... call resume_tool action=improve instead'). It also includes detailed instructions for job_id resolution, making it clear when to invoke this tool.
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.
Discussions
No comments yet. Be the first to start the discussion!