Server Quality Checklist

Tool Scores

• search_companiesC
  2.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search Naukri's company directory' and does not mention return format, pagination, authentication needs, or whether results are limited or ordered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though it sacrifices useful detail for brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no annotations, the description leaves significant gaps: an agent cannot know what a search result looks like, whether authentication is required, or how this relates to get_company_profile. The description is minimally viable but not complete enough for confident tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description adds no meaning to the query or limit parameters. It does not explain what kinds of queries are valid, how limit behaves, or what the response contains, so the agent must rely entirely on parameter names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Search Naukri's company directory.' It is clear that this tool searches companies, distinguishing it from siblings like search_jobs, though it does not explicitly contrast itself with any sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as get_company_profile or search_jobs. The description gives no context about use cases, prerequisites, or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_applied_jobsC
  2.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure, and it fails to do so. Given sibling tools naukri_login and naukri_session_status, this tool presumably depends on an active session — a critical behavioral detail the description omits. It also doesn't mention pagination, which is odd given the 'limit' parameter suggests it's a list endpoint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 7-word sentence that front-loads the action verb 'List.' Every word earns its place, and there's zero fluff. However, the extreme brevity comes at the cost of excluding useful context (session requirements, pagination notes) that could have been added without hurting conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only 1 param, no annotations, no output schema, and no nested objects, the description should compensate for structured gaps, but it doesn't. Missing context includes session/auth requirements (critical given login-related siblings), return format, and a note distinguishing 'applied' from 'saved' jobs. The agent is left with potentially costly ambiguity when choosing between this and get_saved_jobs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% with one integer parameter (limit, default 30). The description provides zero compensation for the schema's silence — it doesn't mention that limit controls page size or how the default behaves. Since there is 1 param, the 0-param baseline (4) doesn't apply, and the description adds no help.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb + resource pairing: 'List jobs you've already applied to.' It's clearly scoped and unambiguous about what the tool does. However, it doesn't explicitly differentiate itself from the very close sibling get_saved_jobs, leaving the agent to infer the distinction between 'applied' and 'saved' jobs without naming the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool vs. alternatives like search_jobs, get_saved_jobs, or get_recommended_jobs. There's no mention of prerequisites (e.g., must be logged in), no exclusions, and no mention of when this might not be the right tool. The use case is only weakly implied by the name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_profile_viewsC
  2.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must disclose behavioral traits on its own. It only mentions that the tool returns recent viewers but does not clarify whether this is a read-only operation, whether authentication is required, if results are limited by default, or what happens if there are no views. Since annotations are absent, the description carries the full burden and fails to disclose these important behaviors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise, a single sentence that front-loads the primary purpose. It earns points for brevity, but the lack of additional detail means it is under-specified rather than efficiently concise. Still, there is no wasted words, so it is appropriately sized for what it does.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has only one parameter, no output schema, and no annotations, the description should provide substantial context, but it does not. It fails to explain what data is returned (e.g., recruiters' names, companies, timestamps), how the limit parameter affects the output, or any prerequisites. The lack of output schema and annotations makes the description incomplete for an agent to fully understand the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, so the description must compensate for explaining the 'limit' parameter. The description does not mention the parameter at all, leaving the agent to infer that 'limit' controls the number of results. This is a significant gap because the parameter's meaning is not self-evident from its name alone, and the description fails to explain it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states that the tool returns recruiters or companies that recently viewed your profile, which is a specific resource (profile views) and a clear intent. However, it does not explicitly distinguish this from sibling tools like 'get_my_profile' or 'get_recommended_jobs', though the resource is distinct enough that an agent can infer the difference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for retrieving profile visitor information, but does not mention when it should not be used or provide context such as 'use after login' or 'use to check who viewed your profile'. There is no comparison to sibling tools, so the usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_recommended_jobsC
  2.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden of explaining behavior. It says the tool returns current recommendations, but it does not disclose read-only behavior, personalization basis, freshness, pagination, or failure modes. The 'get_' prefix implies read-only, but the description itself adds little beyond the output concept.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or redundant wording. It is appropriately concise for a simple retrieval tool, though it could have used its brevity budget to add a bit more behavioral or usage context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only fetch with one optional parameter, the description gives the essential meaning. However, with no output schema and no annotations, it is missing useful context like the shape of results, pagination behavior, and how it differs from search_jobs, making the description adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, limit, is left entirely unexplained in the description. Schema description coverage is 0%, so the description should compensate, but it does not mention how the limit affects the number of recommendations or whether there is a maximum. The parameter is self-explanatory to some degree, but that is not enough to earn a higher score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: jobs Naukri is recommending for the user, and the tool name reinforces a fetch/recommendation operation. It lacks an explicit verb like 'returns' or 'fetches' and does not contrast itself with sibling tools such as search_jobs, but the intended purpose is easily understood.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given for when to use this tool instead of alternatives like search_jobs, get_saved_jobs, or get_job_details. There is no mention of login/session requirements or any condition under which recommendations would be unavailable or inappropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_jobC
  2.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full behavioral burden. It communicates that the action is bookmarking, but does not disclose login/session requirements, duplicate handling, or any side effects beyond saving.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short sentence with no redundant wording; the action and object are front-loaded. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no annotations and no output schema, the description omits required session context and what happens after saving. It is minimally usable but not complete for a tool that likely depends on an authenticated Naukri session.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not mention job_url at all. The property name and title are self-explanatory, but the tool description provides no additional semantics such as URL format or where to obtain the job URL.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific verb ('Bookmark') and resource ('a job on Naukri'), with the phrase 'for later' clarifying intent. It is clear but does not explicitly differentiate from sibling tools like get_saved_jobs or apply_to_job.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as apply_to_job or get_saved_jobs. The 'for later' phrase implies a use case, but there is no explicit when/when-not context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• send_messageC
  2.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of disclosing behavior. 'Reply in an existing conversation' implies a mutating action, but the description does not state consequences, prerequisites (e.g., whether an existing conversation must be fetched first), what happens if the thread doesn't exist, or any error behavior. The term 'reply' vaguely hints at a write operation, but this is under-specified for a mutation tool. No contradiction with annotations exists only because there are no annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence with no wasted words, which is efficient. However, its terseness contributes to the cryptic nature of 'matched by recruiter/company name' — it is concise but at the expense of clarity. It earns credit for being short and front-loaded, but the phrasing is dense and slightly confusing, warranting a middle score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a side-effecting tool with no annotations, no output schema, and 0% parameter coverage, the description is under-specified. An agent cannot determine the exact expectation for thread_query (name format), the role of text, or what distinguishes a successful send from a failure. The presence of sibling tools like get_conversation suggests context, but the description itself leaves significant gaps for this mutation operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is a low 0%, so the description must compensate. It partially does by clarifying that thread_query matches against 'recruiter/company name,' adding meaning beyond the literal 'Thread Query' label. However, it does not clarify whether thread_query is a full name, a partial query, or which field takes precedence, and 'text' is entirely undocumented. The description adds some value for thread_query but leaves text and the exact matching semantics ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('reply') and identifies the resource ('an existing conversation'), with a distinguishing scoping detail ('matched by recruiter/company name'). It implies this is not for starting new conversations, partially differentiating it from a hypothetical 'new message' tool. However, it could more explicitly state this is a message-sending action, and the phrase 'matched by recruiter/company name' is slightly ambiguous without context, so it doesn't quite merit a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, nor does it name any sibling tool as an alternative for different scenarios. Given the sibling list includes get_conversation and get_inbox, the distinction from those is left entirely to inference. There is no condition or exclusion stated, so an agent must infer all usage context from the surrounding tool family alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apply_to_jobC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No mention of side effects like submitting an application, potential confirmation steps, or irreversibility. The description doesn't disclose whether this is a final action or a request.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence with no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity, it covers the basic action, but lacks context about necessary steps (e.g., login), possible outcomes, and limitations. It's adequate for a simple tool but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter job_url is described only as a string with no additional context about expected format or validation. Since schema description coverage is 0%, the description fails to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: applying to a job on Naukri. It distinguishes from saving a job or viewing applied jobs, though it could be more explicit about the difference from saving.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this vs save_job or other job-related tools. It implies a requirement for an existing profile but doesn't explicitly state prerequisites or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_inboxB
  3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the behavioral disclosure burden. It does communicate that this is a read-only listing of recent recruiter conversations, which is the core behavior. However, it omits important behavioral context such as authentication requirements, output shape, pagination, and what 'recent' means in terms of returned data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise, front-loaded sentence with no filler. It is efficient for a simple list operation and gets the core intent across immediately. It does not abuse brevity to the point of tautology, but it omits some valuable context that could be provided without bloating the description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter and no output schema, the description is minimally adequate: it names the resource and the operation. However, it does not address login/session requirements or explain the optional limit param, which an agent needs to predict call failures or control the response volume.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There is a single optional 'limit' parameter, but schema description coverage is 0% and the description never mentions limit or how pagination/truncation behaves. The parameter name and default value provide some meaning, but the description adds no parameter-level information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb and resource: 'List your recent recruiter conversations on Naukri'. It conveys exactly what the tool does and uses the inbox framing, which separates it from siblings like get_conversation. It lacks an explicit contrast with get_conversation, but the plural list framing makes the purpose reasonably clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus get_conversation, get_recommended_jobs, or other Naukri tools. It also does not mention that an active Naukri session is likely required before calling it. An agent must infer usage context from the sibling tool list and the word 'inbox'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_my_profileB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists content fields and does not mention that this is a read-only operation, whether authentication is required, or what happens if no session exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the resource and immediately lists the key returned fields. Every word earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter personal profile fetch, the description identifies the resource and main return fields, which is adequate but minimal. It omits any mention of session requirements or error behavior, which would be useful given the lack of annotations and output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no parameter ambiguity for the description to resolve. The baseline of 4 applies because the description adds relevant context about the returned profile fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as the current user's Naukri profile and lists key returned fields (headline, key skills, resume status). The 'my' qualifier distinguishes it from sibling tools like get_profile_views and get_company_profile, though it lacks an explicit verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives such as get_profile_views or get_company_profile. The name and description imply self-profile retrieval, but there is no explicit context or exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_company_profileB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the full burden of disclosing side effects, auth requirements, etc. It states a read operation (Get) but does not note whether a login session is required, rate limits, or any other behavioral constraints. Given the sibling list includes naukri_login and session tools, the lack of any auth note is a notable gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that conveys the essential function without fluff. It starts with the verb and resource, and lists the contents concisely. Perfectly sized for its purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has one parameter, no output schema, and no annotations. The description tells what information is fetched (overview, ratings, jobs) but omits any prerequisites such as authentication (inferred from sibling tools), the expected response format, or error handling. Given the simplicity, it is still incomplete without these clarifications.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does not explain the parameter beyond the schema's name 'company_slug_or_url'; it never says that this is the company identifier or what format is accepted. The description only mentions the action, not the parameter's role, leaving the agent to infer that the parameter identifies the company.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the specific resource (a company's Naukri page) and what it contains (overview, ratings, open jobs). It uses a specific verb 'Get' and is distinct from siblings like search_companies or get_job_details. No ambiguity about the tool's core function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when one has a specific company identifier, but it does not explicitly contrast with search_companies or state when to use this instead of searching. The context of a single parameter (slug/URL) implies you already have the target, but no explicit when-to-use versus alternatives is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_conversationA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the behavioral disclosure. It clearly says 'read its message history', implying non-destructive read. However, it doesn't mention any side effects like marking as read, or whether it requires a session. The term 'Open' could imply something more, but the clarification to 'read' mitigates ambiguity. It lacks details on response structure, but for a single-purpose tool, it's adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with the action and resource. The parenthetical adds necessary detail without fluff. It's concise but could be slightly clearer by separating the matching criteria.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has one required param and no output schema guardian. The description covers the core functionality, but doesn't mention session requirements, error scenarios, or the response format. Given the sibling tool set includes login-based tools, the agent might need to know if authentication is implied. Still, for a simple read tool, it's reasonably complete but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description is crucial. It explicitly explains that thread_query is matched by recruiter/company name, giving the parameter concrete meaning beyond the generic schema. That's a strong compensation for the schema's lack of description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool opens a conversation and reads its message history, specifying that the conversation is matched by recruiter/company name. This gives the agent a clear sense of what the tool does without ambiguity. It falls short of 5 because it doesn't explicitly say what the output will be (message history), though it implies reading it.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains how to match (recruiter/company name) but doesn't state when to prefer this over siblings like get_inbox or send_message. There's no mention of prerequisites like being logged in, or context about the agent's goal. It's functional but not prescriptive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_job_detailsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden of behavioral disclosure. It does state the input is a Naukri URL and the output is the 'full description,' which conveys a read-only operation. However, it doesn't mention network effects (e.g., requires internet, might fail for invalid URLs), whether it requires an active session (given the sibling naukri_login and naukri_session_status tools), or whether output is structured. The description is adequate but leaves behavioral questions about session requirements and error handling unanswered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, fourteen words, zero waste. The key scoping constraint 'from its Naukri URL' is prominently placed. Every word serves the semantic goal of explaining what the parameter expects and what the tool returns.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter retrieval tool with clear output implied by 'full description,' the description is nearly adequate. However, it doesn't address the session-dependency question—the sibling set includes naukri_login/session_status/close_session, suggesting authentication state might affect behavior, and this tool doesn't clarify whether a session is required. It also doesn't explicitly state the return is in a specific format (JSON vs. HTML content). The description is complete for the happy path but leaves the agent guessing on auth requirements and error/expired-session scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, meaning the schema provides no description for the job_url parameter. The description's phrase 'from its Naukri URL' provides crucial semantic context: the parameter expects a Naukri job URL specifically, not just any URL. Is that enough to reach 4? For a single string parameter, the description does add meaning beyond the raw schema. However, it could be more explicit about the URL format (e.g., 'e.g., https://www.naukri.com/job/...'). A 3 is fair because while it provides the best possible guidance for the one parameter, it doesn't specify expected format, validations, or examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets the full description of a single job, specifying the resource (job) and source (Naukri URL). It distinguishes from siblings like search_jobs (which searches) and get_saved_jobs (which lists), though it could more explicitly name these alternatives. The verb 'Get' and object 'full description of a single job' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage—when you have a Naukri URL and need its full details—but doesn't explicitly state when not to use it or name alternatives like search_jobs or get_recommended_jobs for discovery. An agent could infer 'use when you have a job URL,' but the tool would be stronger with an explicit 'use search_jobs to find jobs by query' or similar guidance. There is no explicit exclusion of cases requiring a different tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_jobsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description makes it clear this is a search operation and is likely read-only, which is useful given that no annotations are provided. However, it does not disclose important behavioral aspects such as whether an active Naukri session is required, what the response shape looks like, or how limit/page_num affect results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single well-front-loaded sentence. Every word contributes essential information: the source, the tone, and primary/optional filters. There is no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives enough to understand core purpose and the primary filters. But with no output schema and no annotations, the agent is left to infer the return format and pagination behavior, which is a noticeable gap for a tool with 5 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema description coverage at 0%, the description must compensate. It adds meaningful meaning to keywords, location, and experience by framing them as job search filters. However, it does not add anything beyond the schema for 'limit' and 'page_num', leaving those as inferred-only.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('Search Naukri job listings') and names the key filters: keywords, location, and years of experience. It identifies the resource as Naukri job listings, which distinguishes it from sibling tools like search_companies, but it does not explicitly distinguish itself from get_recommended_jobs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the keyword-based search entry point for Naukri job listings, especially given the sibling search_companies tool. There is no explicit guidance about when not to use it, such as 'use get_recommended_jobs for recommendations' or 'use get_job_details once you have a job ID.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_saved_jobsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It indicates a read-only operation ('List'), but does not mention potential side effects (likely none), return format, or any limitations. The description is minimal and provides no information about pagination or data structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise with no redundant words. It gets straight to the point, which is ideal for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the operation, the description is adequate but incomplete. It lacks details about the output structure, whether results are ordered, or any response format. Since no output schema is provided, the description should at least hint at what fields or structure to expect, but it doesn't.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, 'limit' with a default of 30, is not mentioned in the description. Since the schema coverage is essentially 0% (the description ignores the parameter), the description fails to add value. Although the parameter is self-explanatory, the description could have clarified its purpose (e.g., 'limit the number of results').

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: listing previously saved or bookmarked jobs. It uses a specific verb ('List') and a specific resource ('jobs you've previously saved/bookmarked'), and it is distinct from sibling tools like get_applied_jobs or get_recommended_jobs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when the user needs to see their saved jobs. However, it does not explicitly contrast with alternatives like search_jobs or get_applied_jobs, though the naming and simple description make the use case obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naukri_session_statusA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry behavioral disclosure. It states the action is a check, implying no side effects, but it does not specify the return value or behavior when no session exists. It lacks details about how validity is determined, so only partial disclosure is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the action 'Check'. It is concise, with no filler or redundancy, and every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given its zero-parameter simplicity, the description states the purpose clearly. However, without an output schema, it does not describe the return format or possible statuses (e.g., boolean, error), leaving ambiguity about how an agent should interpret results. This is a minor gap for a status-check tool, but it is still incomplete for an agent that needs to react to the output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is 100% by default. The description adds no parameter details, but none are needed. Baseline 4 applies because no parameters exist and the description need not compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Check' and the resource 'whether there's a currently valid, logged-in Naukri session'. It distinguishes from sibling tools like naukri_login and naukri_close_session, which are actions not status checks. The purpose is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives. It implies usage via its purpose (checking session status before operations), but does not mention that it should be used before authenticated actions nor exclude alternatives. Guidance is implied, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naukri_loginA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full behavioral burden. It discloses that the tool opens a visible browser, requires manual interaction including OTP/captcha, and saves the session for headless reuse. However, it does not explicitly state what happens if already logged in (e.g., whether it overwrites the existing session), which is a minor gap. Overall, it provides good transparency beyond what schema could offer.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, with the core action front-loaded and no extraneous information. Every word contributes to understanding the tool's operation and usage timing. It is concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a login tool that requires manual interaction, the description covers all essential aspects: what it does, when to call it, how the session is persisted, and how to check status (via sibling). No output schema exists, so none is needed. It adequately addresses the tool's complexity and context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no descriptions (coverage 0%), and the description does not mention the 'timeout_seconds' parameter at all. The parameter's name and default are self-explanatory, but since the description doesn't compensate for the lack of schema text, agents must infer its meaning. This is a notable gap given the low schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: opening a visible browser window for manual login, including OTP/captcha steps. It distinguishes this tool from siblings by noting that it is the only interactive login tool and that the resulting session is reused by all other tools. The verb-resource pairing is precise and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says to call this tool first, and again when the session status reports logged out, referencing the sibling 'naukri_session_status' as the check. It also implies when not to use it (when logged in). This provides clear guidance on invocation timing and the relationship to other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• naukri_close_sessionA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the burden of behavioral disclosure. The description discloses that closing the browser frees resources and that the saved session enables automatic reopening. This is useful beyond a bare 'closes the session' phrase. It did not mention impact on unfetched/unsubmitted work or irreversible actions, but for a clean-session-close operation that auto-reopens a exactly-saved state, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the action phrase closing, then the consequential behavior future auto-reopen. Two complete sentences, zero filler, no repetition feels well structured and appropriately sized for a 0-parameter close action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that it has a parameter, no annotations, and no output schema, the description sufficiently covers everything an agent needs: what it does closing browser freeing resources and what comes next. There is no important missing signal for the close-session operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters and schema description coverage 100% (trivially), the parameter-semantics bar is set at baseline 4 by the rules. The description adds no per-parameter information because there are no input_fields to explain. A score of 4 best expresses that there is no meaningful parameter to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action (clapping the browser) associated with the tool named close_session. It implies it is the counterpart to a session that other sibling tools like naukri_session_status inspect, so it is distinguishable in purpose from its siblings with minimal effort.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It does not explicitly say 'call this when you are finished with the browser session' or list exclusions, but it does provide context that the session is saved and will be auto-reopened on a future call, which makes the close operation safe and does not prevent later use. It doesn't explicitly name alternatives, but the description is quite obvious for a closing operation, so the absence of an explicit when / when-not is a minor gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.