Search fresh Indian jobs and internships, plus international intern and new-grad roles.
Scored across 4 tools
The two search tools (search_jobs for India, search_global_jobs for abroad) are clearly split by geography, and get_job vs. the search tools is a clear fetch-vs-list distinction. list_job_filters is distinct. Only minor risk is confusing the two search_* tools at a glance, but descriptions resolve it.
All four names follow a consistent snake_case verb_noun pattern (get_job, list_job_filters, search_global_jobs, search_jobs). Verbs and structure are predictable throughout.
Four tools is on the lean side but each earns its place for a read-only job discovery server: two searches, one detail fetch, one filter lookup. Nothing redundant, nothing obviously missing from scope.
Covers the core job-discovery lifecycle: browse filters, search (domestic and global), and fetch full detail with application info. No save/alert or pagination controls, but agents can work around those; no dead ends for the stated purpose.
Fetch one Indian listing in full: the complete description and how to apply (apply link, HR email or WhatsApp, whichever the employer gave). Takes the slug from search_jobs, or a carrerlift.in/jobs/ link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug, e.g. blinkit-program-manager-gurugram-fec5c82b, or the full job link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context by disclosing what the payload contains — the complete description and how to apply (apply link, HR email, or WhatsApp depending on the employer) — which matters since there is no output schema.
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 compact sentences, front-loaded with the action and scope, then the input source. Every clause carries information; nothing is padding.
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 required parameter with full schema coverage and annotations covering the safety profile, the description fills the main remaining gap by describing return content in the absence of an output schema. It does not mention failure behavior for an invalid or expired slug, a minor omission.
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 slug field already documents both the example slug and the full-link alternative, so the description largely restates it. The mention that the slug comes from search_jobs adds a small amount of provenance context but no new format or constraint detail.
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 and resource ('Fetch one Indian listing in full') with the scope narrowed to a single record, which cleanly separates it from search_jobs and search_global_jobs. It even names what 'full' means (description plus application method), so the agent knows exactly what it gets.
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?
Gives clear context for invocation: the slug 'Takes the slug from search_jobs, or a carrerlift.in/jobs/ link', which chains this tool after the search tool and tolerates two input shapes. It stops short of explicit when-not-to-use guidance or naming alternative detail-fetch paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cities and job types the Indian listings currently cover, busiest city first. Use to pick a valid location for search_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and world-scope are covered. The description adds real context beyond that: the geographic scope is India-only and results are sorted busiest-first. It says nothing about result size, pagination, or freshness of the listing coverage.
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, no filler. The scope and ordering lead, and the usage hint follows, which is the right front-loading for a lookup 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?
For a parameterless read-only enumeration with no output schema, the description supplies the essentials: what is enumerated, the geographic restriction, the sort order, and why to call it. The only missing piece is a sense of result size or shape, which is minor here.
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 takes zero parameters, so there is nothing for the description to clarify and no schema gap to compensate for. Baseline 4 applies for a parameterless tool.
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 concrete resource (cities and job types the Indian listings cover) plus a result-ordering trait (busiest city first), so an agent knows exactly what comes back. The verb is implicit rather than explicit, and it does not directly contrast itself against get_job or search_global_jobs, but the scope is unambiguous.
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?
"Use to pick a valid location for search_jobs" names the downstream tool and the condition that motivates calling this one, which is genuinely useful routing. It stops short of stating when not to call it or naming other alternatives (e.g. search_global_jobs for non-Indian listings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search internships and new-grad roles abroad (mostly USA, some international), merged from community job lists and refreshed a few times a day. Filter by keywords, level/region, and field.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. Default 1. | |
| type | No | intern_usa, newgrad_usa, intern_intl (outside USA) or newgrad_intl. | |
| query | No | Matches company, role or location, e.g. google, machine learning, London. | |
| category | No | Field of work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds genuine, non-obvious context about provenance and staleness ('merged from community job lists and refreshed a few times a day'), but omits the server-side paging ceiling and any rate/result-count 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?
Two sentences, zero filler: scope and data source lead, filtering capability follows. Every clause carries information an agent needs to decide whether to call the 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?
With no output schema the description need not explain return values, and 100% schema coverage handles the parameters. The main residual gap is explicit differentiation from the same-family search_jobs tool, which the agent must infer from the 'abroad' framing.
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 each of the four parameters is already documented, including both enums and the 1-based page default. The description's 'keywords, level/region, and field' phrasing only loosely restates those fields and adds no format or edge-case detail.
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 and resource ('Search internships and new-grad roles abroad') with explicit scope ('mostly USA, some international'), so the agent knows exactly what corpus is queried. It never names the sibling search_jobs, however, so the boundary between global and non-global search is left to inference.
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 filter sentence ('filter by keywords, level/region, and field'), which maps loosely onto query/type/category. No when-to-use, when-not, or alternative routing versus search_jobs, list_job_filters, or get_job is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live job and internship listings in India, newest first. Filter by keywords (role, skill or company), city, and type. Returns up to 24 per page, each with a short description and a link.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. Default 1. | |
| type | No | Only when the user asked for a specific type. | |
| query | No | Keywords: role, skill or company, e.g. "data analyst" or "react". Omit to browse the newest. | |
| location | No | City, e.g. Bangalore, Delhi NCR, Pune, or Remote. Omit for anywhere. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: sort order ('newest first'), page size ('up to 24 per page'), and what each result contains (short description and a link), which is especially valuable with no output schema.
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, zero filler, with the scope, sort order, and result shape front-loaded before the filter list. Everything 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 usefully covers return shape (24 per page, short description, link) and sorting. It omits pagination depth (the schema caps page at 20) and any mention of the sibling tools for disambiguation, so it is strong but not fully 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?
Schema coverage is 100%, so the schema already documents all four parameters in detail, including the enum and defaults. The description restates keyword/city/type filtering but adds no syntax or format detail beyond the schema; 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?
States a specific verb+resource ('Search live job and internship listings in India') with scope and sorting, which implicitly separates it from search_global_jobs. It does not explicitly name that sibling or get_job, so differentiation is left to inference rather than stated.
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 explains what can be filtered but gives no explicit when-to-use guidance or alternatives (e.g. use search_global_jobs for non-Indian roles, get_job for details). Usage is only implied by the India scoping.
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.
get_joblist_job_filterssearch_global_jobssearch_jobsSearch live, vetted India jobs by keyword, location, posting age, and job ID.
Search 200k+ live jobs and internships. Filter remote, salary, H-1B, then auto-apply on ApplyBolt.
Search a live index of millions of open jobs from employer career sites and 100+ ATS platforms.
Add one secure layer between your agents and this server.
