Search current job listings on Faith Friendly Jobs and read each one.
Scored across 3 tools
Each tool has a clearly distinct role: get_job retrieves a single job by id, list_categories enumerates categories with counts, and search_jobs performs filtered listing searches. There is little risk of an agent confusing these operations because their inputs and outputs are conceptually separate.
All three tools follow a consistent verb_noun snake_case pattern: get_job, list_categories, and search_jobs. The naming is predictable and easy to scan.
Three tools is a well-scoped surface for a read-only job board: one for search, one for browsing categories, and one for retrieving a specific job. Each tool earns its place and there is no unnecessary surface area.
The surface covers the core read-only job-board workflows: search listings, browse categories, and fetch a job's details. Minor gaps exist, such as no tool for listing locations or companies independently, but agents can generally work around these through search filters.
Returns one current Faith Friendly Jobs job by its id, with a sanitized description of up to 8,000 characters and a link to its page.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id of a job from a search_jobs result. The number at the end of that id works on its own too, as an integer or a string. |
| Name | Required | Description |
|---|---|---|
| job | Yes | |
| brand | Yes | |
| premium_similar | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's added value is the payload contract: the description text is sanitized and capped at 8,000 characters, a page link is returned, and only 'current' postings are eligible. It does not state what happens on an unknown or expired id, which is the main remaining behavioral gap.
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?
A single front-loaded sentence that identifies the resource, the key, and the return characteristics with no filler or redundant restatement of the tool name.
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 one-parameter lookup with a full schema and an output schema, the description covers what an agent needs to select and call it. The only omission is error/empty-result behavior for missing or expired ids, which would otherwise make this 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% and the id parameter is already documented in detail, including the integer/string dual type and the 'number at the end of the search_jobs id' convention. The description adds nothing beyond 'by its id', so the 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 (returns), a specific resource (one current Faith Friendly Jobs job), the lookup key (by its id), and the payload characteristics (sanitized description up to 8,000 characters plus a page link). Clearly distinguishable from list_categories and search_jobs, which are browsing tools rather than single-record lookups.
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 only implied: 'by its id' suggests calling this after a search, and the schema note ties the id to a search_jobs result, but the description itself gives no explicit when-to-use, when-not-to-use, or alternative routing. An agent must infer the search-then-fetch workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the job categories on Faith Friendly Jobs with how many current listings each one has.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| brand | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, closed-world operation. The description adds useful behavioral context by stating that counts of current listings are included, but it does not disclose ordering, whether categories with zero listings appear, or whether counts are live versus cached. The output schema carries the return-shape burden.
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 definition is a single front-loaded sentence that names the resource and its most decision-relevant attribute, the current listing count. There is no redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only listing tool with annotations and an output schema, the description covers the essential behavior: what is listed and that counts accompany each category. Minor gaps around ordering and zero-count categories remain, but they are unlikely to block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden beyond confirming that no input is required. The description correctly implies a no-argument listing operation. Baseline 4 applies for a zero-parameter 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?
The description states a specific verb and resource: it 'Lists the job categories on Faith Friendly Jobs' and specifies that each category includes a current listing count. This clearly distinguishes it from get_job and search_jobs, which operate on individual jobs or job searches rather than category aggregation.
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 return content: an agent would call this to discover categories and their listing volumes. However, there is no explicit guidance on when to choose this over search_jobs or get_job, and no mention of exclusions, prerequisites, or whether this is intended as a discovery step before searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the current job listings on Faith Friendly Jobs by keyword, category, remote and location, and returns each job with a link to its page on Faith Friendly Jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many jobs to return, from 1 to 20. The default is 10. | |
| query | No | A word or short phrase to look for in each job's title, company, skills and categories. Matching is case-insensitive and the whole phrase has to appear inside the title, the company, one skill or one category, so one or two words work best. | |
| offset | No | How many matching jobs to skip before the results start, for paging. The default is 0, and the response's total says how many jobs matched. | |
| remote | No | With true only remote jobs come back, and with false only jobs that aren't remote. Without it, both come back. A job counts as remote when its location is Remote. | |
| category | No | One category name from list_categories, matched case-insensitively, and known aliases work too. Any other name, or more than one category, returns an error instead of wider results. Without a category, the search covers every category. | |
| location | No | A city, state or country to look for in each job's location, matched case-insensitively. Remote jobs have Remote as their location, so the remote argument is the better way to find them. |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| brand | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| premium_more | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds that results carry a link back to the site page, which usefully hints at a follow-up get_job pattern, but it says nothing about ordering, zero-result behavior or error handling beyond what the schema documents.
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?
A single sentence front-loads the action and resource, then the filters, then the return shape. No filler, no repetition of the title.
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?
An output schema exists and annotations cover the safety profile, so the description does not need to explain return values. It is complete enough for an agent to call the tool correctly; the only missing piece is an explicit pointer to get_job and list_categories as follow-ups, which is implied but not spelled out.
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 every parameter is already documented in detail, including limit bounds, offset paging, case-insensitive matching and the error behavior for an invalid category. The description only echoes the filter dimensions (keyword, category, remote, location) and omits limit/offset entirely, so it adds little beyond the schema. The baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The sentence names a specific verb ('searches') and resource ('current job listings on Faith Friendly Jobs') and enumerates the filter dimensions it accepts. It also states what comes back, a job list with a link to each job's page, so the agent can distinguish it from get_job. It stops short of explicitly naming the siblings, so it falls just under a 5.
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 context is implied rather than stated: 'current job listings' versus get_job for a single job, and the category parameter points at list_categories for valid values. There is no explicit 'when to use this instead of' sentence and no statement about pagination workflow, so the agent must infer the routing.
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_job1 field changedInput schema / properties / id / descriptionAdded value: +"The id of a job from a search_jobs result. The number at the end of that id works on its own too, as an integer or a string."search_jobs6 fields changedInput schema / properties / category / descriptionAdded value: +"One category name from list_categories, matched case-insensitively, and known aliases work too. Any other name, or more than one category, returns an error instead of wider results. Without a category, the search covers every category."Input schema / properties / limit / descriptionAdded value: +"How many jobs to return, from 1 to 20. The default is 10."Input schema / properties / location / descriptionAdded value: +"A city, state or country to look for in each job's location, matched case-insensitively. Remote jobs have Remote as their location, so the remote argument is the better way to find them."Input schema / properties / offset / descriptionAdded value: +"How many matching jobs to skip before the results start, for paging. The default is 0, and the response's total says how many jobs matched."Input schema / properties / query / descriptionAdded value: +"A word or short phrase to look for in each job's title, company, skills and categories. Matching is case-insensitive and the whole phrase has to appear inside the title, the company, one skill or one category, so one or two words work best."Input schema / properties / remote / descriptionAdded value: +"With true only remote jobs come back, and with false only jobs that aren't remote. Without it, both come back. A job counts as remote when its location is Remote."get_joblist_categoriessearch_jobsSearch current job listings on Christian Jobs List and read each one.
Search current job listings on Christian Tech Jobs and read each one.
Read job postings live from employer career sites across 10 applicant tracking systems.
Add one secure layer between your agents and this server.
