EuropassMCP

by Tsadoq

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a clear and separate concern: document creation, a specific CV section, validation/export, or a single code-list lookup. Even the lookup tools are unambiguously separated by resource type, and the add_* tools are distinguished by the section they populate.
Naming Consistency5/5
All tool names follow a predictable lower_snake_case verb_noun pattern: create_, set_, add_, validate_, export_, lookup_, and search_. The add_* family clearly maps to CV sections, and the lookup_* tools consistently represent code-list lookups.
Tool Count5/5
Twelve tools is well-scoped for a CV-building server: one for document creation, four for content sections, one validator, two exporters, and three code-list lookups. There are no redundant or near-duplicate tools inflating the set.
Completeness3/5
The core Europass sections and the validation/export pipeline are covered, but the entry lifecycle is incomplete: added work, education, language, and digital skill entries cannot be edited or removed, and there is no clean tool for reading back the current CV state. This creates avoidable dead ends when an agent makes a mistake.
Average 4.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- 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?
No annotations are provided, so the description must disclose side effects and constraints. It only says 'Add'—implying mutation—but does not mention whether it modifies the draft, if it is idempotent, if overwriting occurs, or what happens on conflict. There is no note about auth, rate limits, or failure modes, leaving a significant transparency gap for a write operation.
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 three compact sentences with no filler. It is front-loaded with the core purpose, then adds the 'separately' rule and a lookup tip. Slight room to improve by mentioning the draft_id parameter, but overall it is efficiently structured and to the point.
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 no annotations and an output schema that presumably describes the return, the description covers the main usage rules (single language per call, mother tongue handling, code lookup). However, it omits any behavioral expectations such as result handling, error cases, or safety implications, which are important for a mutating tool. The schema fills parameter semantics well, but the description could be more transparent about side effects.
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?
The schema already gives thorough descriptions for both `draft_id` and the nested `skill` object (including the CEFR level explanation and `mother_tongue` semantics). The description adds the practical hint to look up language codes and emphasizes 'mother tongues included', which is useful but overlaps with the schema's note. It does not decode the nested structure further, so it adds only marginal value beyond the schema.
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 action ('Add one language') and the resource (the person's language skill). It also explicitly notes the one-at-a-time behavior ('Add every language separately') and points to a sibling tool (`lookup_language`) for code resolution, distinguishing it from other add-type siblings like `add_work_experience` or `add_digital_skill`.
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 direct usage rules: add each language in its own call, include mother tongues, and verify language codes via `lookup_language`. This effectively tells an agent when to invoke this tool and how to prepare parameters, though it doesn't explicitly mention alternatives; the context is sufficient to select this over sibling add-tools.
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 burden. It explicitly discloses that the tool appends after existing jobs and preserves the submission order in the printed CV, which is non-obvious and valuable. It does not cover error cases or side effects, but for an append operation 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 short sentences with the main verb first and an explanatory second sentence. 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 is a simple append operation; the description plus the rich input schema and output schema cover what an agent needs. The ordering behavior, which is the only non-obvious detail, is explained. No critical information is missing.
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?
The description adds no parameter-specific information; the ordering note does not explain any field. However, the input schema already documents draft_id and the full WorkExperience object with per-field descriptions, so the agent is not left guessing. The description's omission is acceptable, yielding a baseline score.
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 verb ('Add'), a concrete resource ('one job to the CV'), and the ordering clause clarifies the operation's place in the document. It is clearly distinct from sibling tools like add_education or add_language_skill.
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 instructs the agent to submit jobs in print order (most recent first for Europass), which is a practical usage rule for multiple calls. It does not explicitly name alternative tools or when-not conditions, so the usage is implied rather than explicit.
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 full burden of explaining behavior. It discloses the output shape ('[code, label] pair'), ordering ('likeliest first'), coverage ('every language Europass knows'), and a caveat about languages not accepted as a mother tongue. This is substantive and goes well beyond a bare lookup description.
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 well-structured. The first sentence states the core purpose, and the second adds output format, ordering, coverage, and a relevant caveat. Every sentence earns its place without redundancy or padding.
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 simple one-parameter lookup tool with an output schema available, the description is complete enough. It covers what the query means, what the response looks like, how results are ordered, and an important validation caveat. No critical operational detail is missing.
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?
The single required parameter 'query' has 0% schema description coverage. The description clarifies that the query is a language name, which provides basic meaning, but it does not add detail on accepted formats, examples, or ambiguity handling. It partially compensates for the empty schema but leaves some semantics 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 clearly states the tool's purpose: find Europass-recognised language codes from a language name. It specifies the verb ('find'), the resource ('language codes Europass recognises'), and the input ('a language you can name'), distinguishing it from sibling lookup_country and search_occupation tools.
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: call this when you have a language name and need its code, and it notes coverage ('every language Europass knows'). However, it does not explicitly state when not to use it or name alternatives such as add_language_skill or validate_cv, leaving the routing somewhat implicit.
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?
Since no annotations are provided, the description carries the behavioral burden. It explicitly discloses that the operation appends one item after existing entries, rather than replacing or clearing them. It does not mention error behavior or preconditions like draft existence, but the key state-changing behavior is communicated clearly.
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, front-loaded sentence with no filler. It communicates the core action and the append behavior in a compact and immediately usable form.
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 straightforward single-item append operation with a documented schema and an output schema, the description plus input schema is sufficient for correct invocation. It could mention that the target draft must already exist, but the required draft_id parameter and the verb 'add' imply that sufficiently.
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 50%, and the description adds no per-parameter detail beyond reinforcing that 'studies' refers to a single qualification/training period. The schema itself documents fields such as title, start_date, and organisation, so the description contributes only marginal semantic value over the schema.
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 action ('Add') and the resource ('one qualification or training period'), which unambiguously identifies the education domain and distinguishes it from sibling add_* tools like add_work_experience or add_language_skill. The phrase 'after those already added' adds useful ordering context without obscuring the core purpose.
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 tells the agent this tool is for appending a single education entry to an existing draft, with the ordering clue 'after those already added.' It does not explicitly name alternatives or when-not-to-use conditions, but the resource type is specific enough to guide tool selection among the siblings.
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 full burden and discloses meaningful behavior: invalid drafts are refused rather than exported, and the output is always a schema-valid Europass document. It does not mention potential side effects or persistence, but the return behavior is described.
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, purposeful sentences: the main action comes first, followed by the critical validation behavior and a helpful pointer. No filler, 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?
For a single-parameter export tool with an output schema, the description explains the key validation gate and the prerequisite to validate first, making it sufficiently complete for an agent. Slightly more detail on how the XML is delivered or how it differs from export_pdf would add completeness, but output schema covers return shape.
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?
The only parameter, draft_id, is fully described in the schema with 100% coverage. The tool description adds no extra parameter meaning beyond the workflow context of validating first, so the baseline for full schema coverage applies.
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?
Description uses the specific verb 'Write' and resource 'finished CV as Europass XML', clearly distinguished from the sibling export_pdf by naming the target format. The validation guarantee further reinforces what the tool does.
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?
Explicitly instructs to call validate_cv first to find out what is missing, establishing a clear precondition for use. It implies the tool is for finished, validated drafts, but does not explicitly contrast with export_pdf or state 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.
Behavior4/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 explicitly states that the tool 'replaces anything set before' and 'overwrites rather than merges,' which is critical non-obvious behavior for an agent to know. It also highlights that this section is mandatory in a finished CV, providing additional context beyond a simple mutation.
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, with the core action and overwrite behavior front-loaded in the first sentence. Every phrase earns its place: the scope, the mandatory nature, the update cadence, and the overwrite semantics. There is 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, two parameters (one being a nested object), and an output schema, the description covers the crucial non-obvious facts: the section is required and the operation overwrites rather than merges. The input schema documents field formats and required names, and the output schema exists, so return-value details are unnecessary. Nothing essential is missing for correct invocation.
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?
The description does not enumerate parameters or explain their meaning beyond telling the agent to send 'full details.' Schema coverage is 50% at the top level: draft_id is described, while the info parameter relies on the nested PersonalInfo definition, which does contain descriptions for each field. The description adds general guidance about completeness but does not compensate for the missing top-level info parameter description beyond what the schema already provides.
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: 'Record who the CV is about, replacing anything set before.' This clearly identifies the tool's function and, combined with the sibling list (add_work_experience, add_education, etc.), unambiguously distinguishes it from tools that modify other CV sections. It also communicates the unique scope of this section.
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 says when to use the tool ('Send it again with the full details whenever you learn more') and clarifies that it should always be populated because 'a finished CV cannot leave out' this section. It does not explicitly name alternatives or exclusions, but sibling tool names make those alternatives obvious. The overwrite warning is a useful usage caveat.
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 full burden. It discloses two meaningful behaviors: the append semantics ('after those already added') and the Europass free-text pitfall. It could mention return values or error cases, but the key side effects are covered.
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-load the core action and then justify the one-per-call rule with a concrete reason. There is no filler, no repetition of the tool name, and 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?
For a simple two-parameter append tool, the description plus schema covers required inputs, append behavior, and the main usage trap. An output schema exists, so return format need not be described. Minor omissions like duplicate handling are not essential for correct invocation.
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 description coverage is only 50%, and the description compensates by clarifying that the skill parameter must be a single skill, not a list. It also reinforces the draft context via 'after those already added'. The draft_id and the optional description field are already adequately documented in the schema.
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 verb ('Add'), a clear resource ('digital or computer skill'), and an explicit append position ('after those already added'). It also differentiates from sibling tools like add_language_skill and add_work_experience by narrowing the scope to digital skills.
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 a strong operational rule: make one call per skill, because Europass prints the field as free text and a combined call would be treated as a single long skill name. It does not explicitly name alternatives or state when not to use the tool, but the context is clear enough.
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?
No annotations are provided, so the description must carry behavioral disclosure. It does so by stating that creation is for a new empty CV, that the chosen name persists for the rest of the conversation, and that duplicate names are refused rather than replaced. This is meaningful behavioral information beyond simple creation.
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 purpose appears in the first sentence, followed only by essential naming and collision behavior. Every sentence earns its place without 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?
For a simple one-parameter creation tool with an output schema, the description covers everything an agent needs: what the tool does, how to choose the parameter value, how the name is used later, and what happens on a duplicate. No critical guidance 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 schema already describes draft_id as 'Name of the draft to work on, as given to `create_cv`.' The description adds practical meaning: the caller should pick a short, memorable name and use it throughout the conversation. It also clarifies uniqueness expectations by noting that used names are refused.
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 action and resource: 'Start a new, empty CV under a name of your choosing.' This clearly distinguishes create_cv from the sibling tools, which populate, validate, or export a CV. The naming guidance reinforces what the tool is for.
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 makes it clear this is the initialization step for a CV lifecycle and that choose a short conversational name identifies the draft going forward. It also tells the agent that reusing an existing name is refused, which prevents accidental overwrite behavior. It does not explicitly compare against alternatives, but the 'start a new, empty' wording provides sufficient context.
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 behavioral burden and exceeds it: it implies read-only checking, reassures about safety, and details the nature of the report (issue location plus close code-list suggestions). This gives the agent a realistic expectation of the tool's 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?
Two tightly written sentences: the first states the core purpose, the second adds safety and output specifics. Every sentence contributes value, and the most important information is front-loaded.
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 single-parameter tool with an output schema, the description plus schema fully covers usage timing, validation behavior, and report content. There are no missing pieces an agent would need to call it 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?
The schema already fully describes draft_id with a pointer to create_cv, providing 100% coverage. The description adds no parameter-specific detail, so the baseline score of 3 is appropriate.
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 ('Check the draft against the Europass schema') and outcome ('report what is wrong'), clearly distinguishing this validation tool from the sibling create/modify/export/lookup tools. It leaves no ambiguity about what the tool does.
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 explicitly says the tool is safe to call at any point and that unfinished CVs are expected to have issues, giving the agent clear context on when to invoke it. It does not name alternatives, but no sibling tool offers validation, so no exclusion is necessary.
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 burden of behavioral disclosure. It transparently states refusal conditions, the fact that the XML is embedded as an attachment, and why a link is returned instead of the file. It also discloses the naming constraint regarding reading the name back from the link. These are critical behaviors with no contradiction from annotations (none present).
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 longer than typical but every sentence adds crucial information: purpose, validation refusals, XML embedding, link response rationale, and naming constraints. It is front-loaded with purpose, and the structure flows logically. Slightly lengthy, but no redundant content.
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 no output schema, the description fully explains what will be returned (a link) and how to use it. It covers all necessary operational aspects: validation, attachment, link handling, and naming. An agent has everything it needs to call this tool correctly and interpret the result.
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 only parameter (draft_id) is fully described in the schema, but the description adds valuable extra context: the constraint that a draft meant for a PDF should have an ordinary name readable from the link. This goes beyond the schema's 'Name of the draft' and gives the agent deeper insight into parameter validity.
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 clear and specific action: 'Lay the finished CV out as a PDF, with its Europass XML inside it.' It identifies the resource (finished CV) and the output (PDF with embedded XML). It also distinguishes itself from export_xml by mentioning validation and the XML attachment, making it clear what this tool uniquely does.
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 explains refusal conditions (invalid draft, server cannot make PDFs) and instructs the agent on how to handle the result (give the link to the user or read the resource). It contrasts with export_xml by referencing validation behavior, but does not explicitly list alternative tools for different scenarios. Still, the guidance is sufficient for an agent to know when to use this tool and what to do with the response.
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?
No annotations are provided, so the description carries full burden. It discloses multi-language support, return format ([code, label] pairs), ordering (likeliest first), and behavior for near-empty queries. This adds meaningful behavioral context beyond the tool name.
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 with zero fluff. The primary purpose is front-loaded in the first sentence, and the second sentence adds necessary detail on language support and output shape. No wasted words.
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 single-parameter lookup with an output schema, the description covers language matching, return structure, ordering, and the empty-query edge case. Nothing essential is missing for correct invocation.
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?
Schema coverage is 0%, and the description fully compensates by explaining the 'query' parameter as a country name in any language, including matching behavior and output format. This makes the parameter's semantics clear without needing to open the schema.
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 verb+resource: 'Find the country codes Europass recognises for a country you can name.' Clearly distinguishes from sibling CV-building tools by focusing on country code lookup.
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 purpose is clear enough that an agent knows when to use it for country code lookups, but the description does not explicitly name alternatives or exclusions. It doesn't compare to lookup_language or other tools, so while context is clear, it lacks explicit 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, the description carries the full burden and uses it well. It explains that matches are returned as [code, label] pairs and that results are ordered by likelihood. This gives the agent useful behavioral expectations beyond the raw 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 compact, front-loaded with the main purpose, and every sentence adds value. The second paragraph provides essential search and output-format details without unnecessary fluff.
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 simple one-parameter search tool with an output schema, the description covers the key aspects: what to search, how to phrase the search, and what the result format is. No critical information for invoking the tool 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?
Schema description coverage is 0%, but the description fully compensates for the single query parameter. It explains what the query should represent (a job description), how to phrase it (profession-level terms), and what the response pairs look like. This is exemplary parameter guidance.
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: finding occupation codes for a described job. It names the specific resource (ISCO-88 occupation codes) and the action (find/search), making it easy to distinguish from siblings like create_cv or lookup_country.
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 concrete guidance on how to query: search for the profession as ISCO-88 words it, not the person's own job title. It doesn't explicitly name alternative tools or exclusion conditions, but for a single-query search tool this is sufficient usage context.
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:

[![EuropassMCP MCP server](https://glama.ai/mcp/servers/Tsadoq/EuropassMCP/badges/card.svg)](https://glama.ai/mcp/servers/Tsadoq/EuropassMCP)

Score Badge

Copy to your README.md:

[![EuropassMCP MCP server](https://glama.ai/mcp/servers/Tsadoq/EuropassMCP/badges/score.svg)](https://glama.ai/mcp/servers/Tsadoq/EuropassMCP)

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/Tsadoq/EuropassMCP'

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