Skip to main content
Glama
JigSawFr

eurodns-mcp

by JigSawFr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get a contact profile, or list them

eurodns_contact_get_profile
Read-onlyIdempotent

Retrieve a contact profile by ID or list account profiles with filters for type and role. Read profile details before updating or setting as default.

Instructions

Returns one reusable contact profile — the registrant, admin, technical or billing identity attached to domains — by id, or lists the account’s profiles when id is omitted, filtered by type and by the roles isOrg, isAdmin, isTech and isBilling, paged. It reads the profile only, not the contacts a registered domain carries, which eurodns_domain_get returns. Read a profile before eurodns_contact_save_profile, which needs every field; eurodns_contact_set_as_default_profile chooses which one future orders use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNumeric id of the contact profile to return in full. Omit it to list the account’s profiles, filtered by type and role.
pageNo1-based page number. There is no page meaning everything: walk pages until a short one comes back.
sizeNoResults per page, 1 to 500. A wide page is truncated by the character limit, so prefer a filter to a large size.
typeNoFilter on the contact type: PRIVATE_PERSON, COMPANY, ORGANISATION or PUBLIC_BODY.
isOrgNoKeep only profiles usable as the registrant (owner) contact.
isTechNoKeep only profiles usable as the technical contact.
isAdminNoKeep only profiles usable as the administrative contact.
isBillingNoKeep only profiles usable as the billing contact.
sortFieldNoResult field to sort on, spelled as in the response items. Unsorted when omitted.
sortOrderNoASC or DESC; only read with sortField.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesResponse body as returned by the API.
statusYesUpstream HTTP status code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.10.0
    • addedInput schema / properties / id / description
      Added value: +"Numeric id of the contact profile to return in full. Omit it to list the account’s profiles, filtered by type and role."
    • addedInput schema / properties / isAdmin
      Added value: +{
+  "description": "Keep only profiles usable as the administrative contact.",
+  "type": "boolean"
+}
    • addedInput schema / properties / isBilling
      Added value: +{
+  "description": "Keep only profiles usable as the billing contact.",
+  "type": "boolean"
+}
    • addedInput schema / properties / isOrg
      Added value: +{
+  "description": "Keep only profiles usable as the registrant (owner) contact.",
+  "type": "boolean"
+}
    • addedInput schema / properties / isTech
      Added value: +{
+  "description": "Keep only profiles usable as the technical contact.",
+  "type": "boolean"
+}
    • addedInput schema / properties / page
      Added value: +{
+  "description": "1-based page number. There is no page meaning everything: walk pages until a short one comes back.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / size
      Added value: +{
+  "description": "Results per page, 1 to 500. A wide page is truncated by the character limit, so prefer a filter to a large size.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / sortField
      Added value: +{
+  "description": "Result field to sort on, spelled as in the response items. Unsorted when omitted.",
+  "type": "string"
+}
    • addedInput schema / properties / sortOrder
      Added value: +{
+  "description": "ASC or DESC; only read with sortField.",
+  "enum": [
+    "ASC",
+    "DESC"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / type
      Added value: +{
+  "description": "Filter on the contact type: PRIVATE_PERSON, COMPANY, ORGANISATION or PUBLIC_BODY.",
+  "enum": [
+    "PRIVATE_PERSON",
+    "COMPANY",
+    "ORGANISATION",
+    "PUBLIC_BODY"
+  ],
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "id"
-]
  2. First observedv0.9.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description reinforces this by stating it reads the profile only and never modifies data. No contradictions exist.

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 long but densely informative, covering retrieval, listing, filtering, pagination, sorting, and relationships to sibling tools. It avoids filler while sacrificing some brevity for completeness.

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?

With 10 optional parameters and an output schema, the description covers the main decision points: id vs list, filters, pagination, sorting, and relationship to domain contacts. It is complete enough for an agent to select and invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100% with detailed descriptions on every parameter, including pagination, filtering, and sorting semantics. The description adds extra practical notes like 'prefer a filter to a large size' and 'walk pages until a short one comes back', going slightly 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: return one contact profile by id or list the account's profiles when id is omitted. It also distinguishes itself from sibling tools like eurodns_domain_get and eurodns_contact_save_profile, making its purpose unambiguous.

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

Usage Guidelines5/5

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

The description and parameter docs give explicit usage guidance: omit id to list, walk pages until a short one returns, prefer filters to large sizes, and sortOrder is only read with sortField. It also tells the agent to read before saving, providing practical context for when to use the tool.

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

Deploy Server

Other Tools