jobsearch-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct part of the pipeline: searching/ingesting jobs, inspecting and triaging stored jobs, tracking applications, managing profile documents and revisions, and checking config/health. Near-neighbor tools like search_jobs vs list_jobs and add_profile_fact vs update_profile_section have clearly defined boundaries in their descriptions.
Naming Consistency4/5
The vast majority of tool names follow a clear snake_case verb_noun pattern (search_jobs, list_jobs, update_job, record_application, add_profile_fact). A few noun-style names like job_detail, job_stats, health, and config_status are minor deviations but remain predictable and readable.
Tool Count3/5
At 19 tools, the server is in the heavy range and covers a broad surface spanning job search, storage, applications, profile management, revisions, and diagnostics. Most tools earn their place, but the count feels larger than strictly necessary and a few could potentially be consolidated.
Completeness4/5
The core workflow is well covered: discovering jobs (search_jobs/ingest_jobs), fetching details, triaging with update_job, tracking applications, and managing the profile with facts, full-document updates, and revision history. Minor gaps like explicit job/application deletion or a dedicated application detail view are workable around through existing tools.
Average 3.8/5 across 19 of 19 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Record' suggests a write operation, but it does not specify whether omitted fields are overwritten, what side effects occur, or what the response contains. A mutation tool with seven parameters needs more transparency.
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 single-sentence description is concise and front-loads the core action with no filler. It is efficiently written, though it opts for brevity at the cost of substantive detail.
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 seven parameters, zero schema descriptions, and no annotations, a one-sentence description is far from complete. The output schema exists, so return values are not needed, but the description still leaves critical gaps around parameter semantics, usage conditions, and behavioral expectations.
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 only offers the generic context of a 'triage decision' without explaining any of the seven parameters. The names fit, rank_score, rank_verdict, and status provide some inference, but the description does not define formats, allowed values, or how parameters relate to each other.
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 action ('record a triage decision') and a target resource ('a stored job'), making it clear the tool operates on existing jobs. It does not explicitly name sibling tools, so it stops short of full differentiation, but the verb-object pairing is 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 phrase 'against a stored job' implies the tool is for updating existing jobs rather than creating new ones, but it does not explicitly state when to use this tool instead of siblings like ingest_jobs or job_detail. There is no guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral disclosure burden. 'Query stored jobs' implies a read-only action, but it does not disclose behavior such as whether results are paginated, how the query is interpreted, what the default return set looks like, or any side effects. The description addresses purpose but not behavioral detail.
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 two short sentences with no filler; the main purpose is front-loaded. It is appropriately concise, though its brevity trades away useful detail that is counted under other dimensions.
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 six optional parameters, no annotations, and no parameter descriptions, the description is too sparse to be complete. An output schema exists, so return values are partially covered, but the tool's selection criteria and filtering semantics are not explained.
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 for any of the six parameters. An agent is left with only parameter names and defaults to guess how 'fit', 'search', 'status', 'company', and 'min_score' interact.
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 and resource ('Query stored jobs') and adds a distinguishing note ('Use this instead of re-searching a portal') that separates it from a portal-searching sibling. It is clear but does not name the sibling explicitly, so it falls just short of full differentiation.
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 sentence 'Use this instead of re-searching a portal' provides direct guidance on when to select this tool over a portal search. It gives a clear context but does not name a specific sibling tool or list any exclusion cases beyond the portal-search scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions liveness and dependency checking, which implies a read-only health probe, but it does not disclose what dependencies are checked, whether it can return error details, or any side effects. The behavior is under-specified for a tool with no annotation support.
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 concise five-word phrase with no filler or redundancy. It is front-loaded and communicates the essential purpose quickly. It could be slightly more structured with a verb, but it remains efficient and readable.
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?
Given that the tool has no parameters and an output schema exists, the description is largely complete for a simple health check. It identifies the core concerns (liveness and dependencies). It does not detail response semantics, but the presence of an output schema offloads that burden.
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 the schema already fully covers all inputs. The description adds no parameter information, but none is needed. The baseline of 4 for a zero-parameter tool is appropriate.
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 the tool performs a liveness and dependency check, which is a clear, specific purpose for a health endpoint. It is not a tautology and the resource is implicitly the service/API itself. It differentiates from the domain-specific sibling tools, which all handle job or profile operations.
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 guidance on when to use this tool versus alternatives. There are no sibling health-check tools, so the need to distinguish is low, but there is also no context about typical usage, such as pre-flight checks or operational monitoring. This leaves usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Show' indicates a non-mutating comparison, and the description identifies the two operands: a stored snapshot and the current document. With no annotations provided, the description carries the behavioral disclosure burden, but it leaves out details like error behavior or whether the revision must already exist.
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 the action and comparison object front-loaded. Every word contributes to the meaning, with no filler, redundancy, or unnecessary detail.
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 one-parameter tool with an output schema, this is minimally sufficient: it names the two sides of the comparison and the resulting action. Still, it lacks usage guidance and explicit parameter semantics, so an agent must infer context from sibling tool names and the parameter name.
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%, so the description must add meaning on its own. It partially does by implying that the required revision_id identifies the stored snapshot being compared to the current document. However, it never explicitly defines revision_id or explains how to acquire it.
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 and object: 'Show what changed between a stored snapshot and the current document.' This clearly indicates a diff/comparison operation and is distinct from sibling tools that list or restore revisions, though it doesn't name those alternatives explicitly.
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?
There is no explicit guidance about when to use this tool versus siblings like list_profile_revisions or restore_profile_revision. The intended use is only implied by the verb 'show', and no prerequisite steps, such as obtaining a revision_id from another tool, are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys a read-only retrieval operation with optional filters, which is minimally adequate. However, it does not disclose output format details, default behavior when no filter is provided, authentication needs, or any other behavioral traits beyond the basic 'get' semantics.
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 concise and front-loaded: the first sentence states the operation and filters, and the second sentence lists the relevant competencies. Every sentence contributes useful information 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?
With an output schema present, return values are covered elsewhere. The single optional parameter is partially documented through the competency list, but the phantom keyword filter and lack of clarification about default behavior leave meaningful gaps for an agent trying to invoke the tool correctly.
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%, so the description must compensate. It adds value by listing the valid competencies on file, which effectively documents acceptable values for the competency parameter. However, it also mentions a 'keyword' filter that does not exist in the input schema, making the parameter mapping confusing and incomplete.
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 verb and resource: 'get' STAR examples, with an optional filter by competency or keyword. It does not explicitly distinguish itself from sibling tools, but none of the siblings appear to target STAR examples. The mention of a 'keyword' filter that is not present in the input schema introduces some ambiguity.
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 about when to use this tool versus alternatives, nor any exclusions or prerequisites. It only implies that filtering is optional. There is no mention of scenarios where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds one useful behavior — open_only hides resolved applications — but does not mention ordering, pagination, status semantics, or any read-only guarantees.
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 short sentences, front-loads the primary action, and contains no filler. Every phrase adds informational value.
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 is simple and an output schema exists, but no annotations and an undocumented status parameter leave gaps. The description is minimally adequate but does not fully cover what an agent needs to use it correctly.
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 explains open_only, but leaves the 'status' parameter completely unexplained, including what values it accepts or how it combines with open_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 specific verb ('List') and resource ('tracked applications'), making the core purpose clear. It doesn't explicitly contrast with siblings like list_jobs or record_application, but the resource name is distinct enough to avoid major ambiguity.
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 tool's intended use is implied by its name and the phrase 'List tracked applications,' and 'open_only hides resolved ones' gives useful filtering guidance. However, there is no explicit when-to-use vs alternatives guidance, nor any exclusions compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose what the history includes (changes, timestamps, source tool), which is useful. But it does not mention ordering, pagination behavior, whether deleted revisions appear, or how limit and section 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-structured sentence that front-loads the core purpose and then specifies the value of the returned data. Every word earns its place, and there is no redundant filler.
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 list tool with an output schema, the description covers the main purpose well. However, it omits key contextual details such as what section refers to, how revisions are ordered, and when to prefer this over the revision-related sibling tools. These gaps matter because there are no annotations to fill them.
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 needed to compensate for the limit and section parameters, but it does not mention either one. The schema provides names and defaults but no meaning; the description adds no parameter-level context beyond what an agent might infer from the 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 names a specific resource (profile revisions) and a clear action (list history), and it explains what the history contains: what changed, when, and via which tool. It is distinct enough from siblings like restore_profile_revision and diff_profile_revision, though it does not explicitly name them for contrast.
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 intended use is implied: call this when you need a history of profile edits. However, there is no explicit guidance about when to choose this over diff_profile_revision or restore_profile_revision, nor any mention of prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must communicate behavioral traits. 'Counts' implies a read-only aggregation rather than a mutation, but the description adds no detail about scope, freshness, permissions, or whether the counts are computed on demand.
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 with no filler. Every phrase contributes meaning, naming the resources counted and the grouping dimensions.
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 zero-parameter stats tool with an output schema present, the description is nearly complete. It could add a phrase about what 'pipeline' refers to or whether these are current counts, but the basics are covered.
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 the baseline is 4. The description adds meaningful grouping semantics (status/fit) beyond the empty schema, making invocation expectations clear.
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 indicates this tool returns counts of jobs and applications aggregated by status, and jobs also by fit. This distinguishes it from list/detail siblings, though it omits an explicit verb like 'retrieve' or 'get'.
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 choose this tool over alternatives such as list_jobs, job_detail, or list_applications. The 'counts' wording implies an aggregate use case, but the description never states this directly or names any sibling as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It clearly labels the operation as a read and lists the document sections, but it does not disclose behavior such as how the section parameter affects the response, what happens with invalid sections, or whether this returns the current/default profile.
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 short and front-loaded with the core action, followed by a compact, useful enumeration of sections. Every line earns its place with no tautology or filler.
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 simple read tool with an output schema, the description is largely sufficient: it identifies the resource, the available sections, and the optional parameter. The main missing context is how get_profile relates to sibling retrieval tools, but that gap is accounted for in the usage dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives only a bare 'section' string with zero description coverage, but the description compensates with the full list of valid sections and sub-content. This gives the agent concrete meaning for the sole parameter, including values like candidate, behavioral, evaluation, and overview.
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: it reads a profile document, and enumerates the sections available. It does not explicitly distinguish itself from siblings like search_profile or get_star_examples, so it stops short of full sibling differentiation.
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 get_profile versus alternatives such as search_profile, get_star_examples, or update_profile_section. The verb 'Read' implies retrieval, but there is no when/when-not logic or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does so well: it discloses the upsert-like behavior, the special handling of final-status applications, and the guarantee that re-applications never overwrite earlier outcomes. It does not discuss authorization or broader side effects, but the key behavioral contract is explicit.
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 tightly written: a one-line summary is followed by a compact explanation of the branching logic. Every sentence carries useful information and no filler is present.
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 delivers the critical behavioral rules needed to avoid destructive overwrites, and an output schema exists to cover return values. However, for a tool with 8 parameters, no annotations, and zero schema documentation, the undefined status vocabulary and undocumented non-key parameters leave meaningful gaps for an agent trying to call it correctly.
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 is the only source of parameter meaning. It explains the significance of company, role, and status by referencing 'OPEN' and 'final status,' but says nothing about notes, source, channel, deadline, or fit_rating, leaving most of the 8 parameters semantically undocumented.
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 uses a specific verb-resource pair ('Create or advance an application record') and immediately distinguishes its behavior from read-only siblings by explaining the update-vs-create branching. It is clear that this tool is the mutation path for application records, not a lookup or job-management tool.
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 practical context about when an existing open application is updated versus when a new row is created, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. The intended use is inferable from the name and resource, but no sibling comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the roll-back action and the snapshot eligibility rule, which is useful. However, it does not state the destructive/replacing consequence of the rollback, permissions, or whether the operation creates a new revision.
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, with the action front-loaded and the eligibility caveat in the second sentence. Every sentence adds necessary information and there is 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?
An output schema exists, so return values do not need elaboration. Still, no annotations are provided and the exact meaning of revision_id is under-specified, making the definition only partially complete for a mutation operation.
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 only says revision_id is a required integer, and schema description coverage is 0%. The description never mentions revision_id explicitly or clarifies whether it identifies the snapshot to restore or the revision being rolled back. This ambiguity is a significant gap for a one-parameter tool.
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 uses a specific verb and resource: 'Roll a profile document back to a previous snapshot.' It also distinguishes this tool from revision-related siblings by noting that only revisions from update_profile_section carry snapshots, so the scope is clear.
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 gives explicit when-to-use and when-not-to-use guidance: use it for update_profile_section revisions that have snapshots; do not use it for append revisions. It does not name alternative tools, but the eligibility rule is clear enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral burden. It discloses persistence ('store anything new'), deduplication behavior, remote-status limitations, and includes a security warning about third-party data. This is unusually thorough.
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 opening sentence is crisp and the content is organized by parameter with a clear security section. It is longer than average, but nearly every sentence adds necessary operational or safety 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?
Covers core workflow, deduplication, portal/lane behavior, and follow-up with job_detail. However, three parameters are unexplained and the side effects of 'store anything new' on existing jobs are not fully clarified. The output schema helps but does not compensate for the missing parameter semantics.
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%, so the description must explain the parameters. It thoroughly explains portal, lane, and query fallback, but days, limit, and all_results are never mentioned and have no schema descriptions, leaving significant gaps.
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?
States a specific action and resource: 'Search job portals and store anything new.' This distinguishes it from siblings like job_detail (which confirms remote status from posting text) and list_jobs (which likely lists already-stored 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?
Provides explicit guidance on portal auto-selection, lane semantics, behavior with no query, and when to route to job_detail. It lacks explicit 'do not use this when...' exclusions for list_jobs, but the context is strong enough for an agent to make the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden. It clearly discloses that the operation is destructive but reversible, that a snapshot is taken first, and that the previous version can be restored. This is strong behavioral context, though it does not cover permissions, side effects beyond the profile document, or rate limits.
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 three sentences long, front-loads the most important facts ('Replace an entire profile document. Destructive but reversible.'), and every sentence adds distinct value: behavior, reversibility, usage scenario, and alternative. No filler 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 high-level guidance is complete and the output schema exists, so return values need not be explained. However, with no annotations and zero parameter documentation in the schema, the missing semantics for 'section' and 'source' leave a real gap that prevents fully correct invocation.
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 for the undocumented parameters. It only implies that 'content' is the new resume/profile data, but it never explains what 'section' means, what values it accepts, or what 'source' contributes. An agent would still be guessing about two of the three parameters.
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 states a specific action and resource: 'Replace an entire profile document.' It also differentiates itself from add_profile_fact by framing this tool as a wholesale refresh rather than a single-fact addition. Even though the tool name includes 'section', the description's 'entire profile document' is unambiguous enough for an agent to understand the scope.
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?
It gives explicit when-to-use guidance with a concrete example ('a new resume supplied by the user') and an explicit alternative for a different case ('For a single new fact use add_profile_fact instead'). It also names the restore path for reversibility, which helps an agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: append-only behavior ('never overwrites'), automatic dating/attribution, immediate visibility to other tools, and the consequence that anything written is treated as true in future CV drafts. These are behavioral traits beyond the schema.
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 core operation, then adds usage boundaries and a safety warning, with no filler. Each sentence contributes to correct tool selection or invocation.
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?
The description covers operation, usage, safety, and cross-tool impact, and an output schema exists. The main gap is the undocumented `source` and `section` parameters, so an agent must guess their semantics.
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 coverage is 0% and the description does not explicitly explain the `source` or `section` parameters. It gives examples of what the `text` value should contain, but leaves the other two parameters' meaning and format to inference.
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 opens with 'Add a new fact to the candidate profile', a specific verb and resource, and immediately clarifies 'Appends - never overwrites', which distinguishes it from update_profile_section. Examples of content types (certification, metric, project, corrected scope) further ground what 'fact' means.
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?
It gives explicit 'Use this for anything newly learned' and instructs to prefer it over update_profile_section unless a whole document rewrite is intended. It also issues a constraint: only record facts the user has confirmed, which tells the agent when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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, and it delivers: it discloses intentional determinism, the location/remote rule, top-of-band salary logic, and the opt-in veto policy. This is rich behavioral context beyond what the parameter names alone convey.
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 compact, roughly five sentences, and front-loads the purpose in the first sentence. Every subsequent sentence adds a distinct piece of behavior or policy, with no filler or repetition.
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 check-only tool with an output schema present, the description covers the core semantics and edge cases (opt-in, deterministic, remote requirements, salary basis). It does not fully spell out every parameter's value domain, but the output schema and parameter names fill most remaining gaps.
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 0% schema description coverage, the description must compensate, and it does explain the location and salary comparison logic (top-of-band) and remote confirmation. However, it leaves salary_min and the expected remote_status values implicit, so an agent must still infer how to populate those parameters.
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 opening sentence uses a specific verb ('Test') and resource ('a role against the hard constraints in your config file'), immediately distinguishing the tool from the job-search, application, and profile siblings. It clearly identifies what the tool does and what domain it operates on.
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 gives clear context for when the tool applies: testing a role's location and salary against configured constraints, and it explicitly explains the opt-in behavior ('with nothing configured, nothing is vetoed'). It does not name alternative sibling tools or explicitly state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It does add useful behavioral context by mentioning that results are excerpts and that the tool is cheaper than get_profile. However, it does not disclose potential pagination, match semantics, or any constraints or side effects beyond the search being a read operation.
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 compact and front-loaded: the core action is in the first sentence, and the second sentence adds valuable usage guidance without excess. Every sentence earns its place.
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?
This is a simple one-parameter search tool and the output schema exists, so the description does not need to explain return values in depth. It covers purpose, usage context, and query semantics sufficiently, though fuller behavioral constraints such as result limits or exact/fuzzy matching would make it complete.
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 schema provides no description for the single 'query' parameter, but the description compensates by explaining that the term is searched for as a fact-check across profile documents. This gives the agent a clear mental model of what to pass, though exact matching behavior is not specified.
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 verb ('Search'), a specific resource ('profile documents'), and the expected output ('matching excerpts'). It also distinguishes itself from the sibling get_profile by noting this is cheaper for checking a single fact.
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?
It explicitly says when to use this tool: 'when you only need to check one fact' and names the alternative (get_profile) that is better for fuller retrieval. The concrete example ('whether a specific tool, employer or metric appears anywhere') gives an agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool only reports configuration state ('which config file was loaded and which rules are actually active'), strongly implying a read-only inspection rather than a mutation. It stops short of explicitly stating side-effect-free or auth requirements, but for a zero-parameter status tool 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?
Two sentences, no fluff: the first states the tool's purpose, the second gives the key usage trigger and benefit. The most useful guidance ('Call this first if results look wrong or empty') is front-loaded and easy for an agent to act on.
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 zero-parameter diagnostic tool with an output schema, the description is complete: it explains the tool's role, when to invoke it, and what information it provides (config file and active rules). Nothing essential for correct invocation is missing.
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 and the schema already reflects this with 100% coverage, so no parameter documentation is needed. The baseline for 0 parameters is 4; the description adds no parameter-specific meaning because none is required.
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 uses a clear verb ('Show') with a specific resource ('what this server is currently configured to do') and then adds concrete detail: it reports which config file was loaded and which rules are active. This makes it distinct from sibling job/profile tools such as list_jobs or get_profile.
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 gives explicit usage guidance: 'Call this first if results look wrong or empty' and explains the advantage ('faster than guessing'). It does not explicitly name alternative tools or exclusion criteria, but the conditional guidance is clear and sufficient for a diagnostic tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It warns that ingested content is untrusted third-party data, forbids following embedded instructions or fetching embedded URLs, and discloses idempotent deduplication behavior.
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 purpose and moves logically through usage, security, and input requirements. Each section earns its place and there is no filler.
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 one-parameter ingest tool with an output schema already present and no annotations, the description covers the action, use cases, security caveats, required and optional item fields, and deduplication. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is almost opaque (0% description coverage, arbitrary item objects). The description compensates by specifying required fields (url, title) and optional fields (company, location, posted_date, description), which is the only real parameter guidance available.
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 first line states a specific verb and resource: 'Add postings you found elsewhere.' It also explicitly distances the tool from 'portal search,' which clearly differentiates it from siblings like search_jobs and list_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 gives clear when-to-use context: use when portal CLIs are unavailable or when another tool/agent provides a batch of listings. It does not explicitly name alternatives or state exclusion cases, so it lacks the strongest routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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, and it does so exceptionally well. It discloses a potentially surprising side effect: fetched data is 'written back to the job record.' It also includes a detailed security warning about untrusted_posting_text, third-party data, prompt injection risks, and the possibility of crafted postings manipulating profile tools.
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 structured effectively: purpose first, then parameter semantics, then side effects, then security. Every sentence adds necessary information, and the security section is important enough to warrant its length. There is no fluff or redundancy.
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?
The tool has one required parameter, an output schema to describe return values, and no annotations, so the description covers all remaining gaps: input meaning, behavioral side effects, and security precautions. Nothing an agent needs to invoke the tool safely and correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'job' as a string with zero description coverage, but the tool description fully compensates: 'job is a stored URL, or a portal job id.' This single sentence gives the agent enough semantic understanding to provide the correct argument, which is especially valuable because schema coverage is 0%.
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 opens with a specific verb and resource: 'Fetch a posting's full text and resolve remote status and salary.' It clearly distinguishes this tool from siblings like search_jobs or list_jobs by focusing on individual posting detail and enrichment. The additional context about writing results back to the job record further clarifies its unique role.
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 gives clear contextual guidance: use this when you need a posting's full text, its remote verdict, or salary band, and it explicitly notes that this is how a job earns a trustworthy remote_status. It does not explicitly list exclusions or compare with alternatives, but the use case is specific enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jobsearch-apply-mcp MCP server](https://glama.ai/mcp/servers/treymorgan/jobsearch-apply-mcp/badges/card.svg)](https://glama.ai/mcp/servers/treymorgan/jobsearch-apply-mcp)

Score Badge

Copy to your README.md:

[![jobsearch-apply-mcp MCP server](https://glama.ai/mcp/servers/treymorgan/jobsearch-apply-mcp/badges/score.svg)](https://glama.ai/mcp/servers/treymorgan/jobsearch-apply-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/treymorgan/jobsearch-apply-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server