Skip to main content
Glama
jobinja-mcp

jobinja-mcp

by sepehr071

Skill demand

jj_skills
Read-onlyIdempotent

Search skill keywords to see how many job ads have ever listed each skill, ranking skills by demand; counts include expired ads and do not represent current openings.

Instructions

Find skills matching a word, with how many ads ever listed each (demand signal).

Counts include expired ads, so they rank skills but are not current openings.

Input Schema

NameRequiredDescriptionDefault
queryYesSkill words, e.g. react.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • changedInput schema / properties / query / description
      Previous value: -"Skill words, e.g. react, python, حسابداری."New value: +"Skill words, e.g. react."
  2. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low, yet the description adds genuinely useful semantics the schema cannot express: counts include expired ads, so they rank skills rather than reflect live openings. It still doesn't state ordering, truncation, or what an empty match returns.

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?

Two short sentences, front-loaded with the action and result, followed by a caveat that materially changes how the numbers should be interpreted. Nothing is wasted and nothing is buried.

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

Completeness4/5

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

For a one-parameter lookup with no output schema, the definition covers purpose, result content, and the key caveat about stale counts. A brief note on result ordering or no-match behavior would make it complete, but an agent could call it correctly as written.

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 coverage is 100% and the single 'query' param is already documented as 'Skill words, e.g. react.' The description's 'matching a word' adds a slight hint about matching granularity but no real syntax, matching-rule, or length guidance beyond the schema. Baseline 3 applies.

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?

Names a specific verb ('Find') and resource ('skills') and states what the result contains: each skill plus a count of ads that ever listed it. That is clearly distinct from the job/company siblings by resource, though it never names a sibling to route against.

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 second sentence gives an implicit usage boundary — the counts are a ranking/demand signal, not current openings — which helps the agent decide when this is the wrong tool for 'how many jobs are open now'. However, it never names an alternative such as jj_search_jobs or jj_market for current-demand questions.

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