Read-only MCP server that answers questions about turva.dev from its published data. Five tools return JSON: the service catalog with prices, contact and operator details, engagement principles and dated agent-readiness and security evidence with verification links. Connect over Streamable HTTP. You need no API key. The server does not scan other websites or run audits.
Scored across 5 tools
Each tool targets a clearly distinct informational need: readiness score, contact, principles, security evidence, and services. The descriptions explicitly cross-reference to prevent confusion (e.g., readiness vs. security evidence, contact vs. services vs. principles). No overlapping purposes remain.
All five tools follow the same get_<noun> pattern consistently. The convention is predictable and easy to scan.
Five tools are well-scoped for a read-only informational server about turva.dev. Each tool represents a distinct content area without redundancy or bloat.
The surface covers the main informational domains: evidence (agent-readiness and security), contact details, engagement principles, and services/pricing. No obvious read-only gaps exist, and write operations are intentionally absent given the static-JSON design.
Returns turva.dev's own agent-readiness score from an independent public scanner (isitagentready.com), including category sub-scores, with the measurement date and a link to the scanner's start page, where a new check can be run (the link does not open the recorded reading). Use this when a user asks how turva.dev scores, whether its claims are verifiable, or what proof backs the audit service. For web-security scan results, which are a separate measurement, use get_security_evidence instead. Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| scans | Yes | |
| domain | Yes | |
| measured_at | Yes | Date of the reading, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: the data is static JSON compiled into the Worker, so it only updates on deploy, and the scanner link does not reopen the recorded reading. That staleness caveat is exactly the kind of context an agent needs and cannot get from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return value before the usage guidance, and each sentence carries information. The parenthetical about the link not opening the recorded reading is slightly clunky but earns its place as a behavioral caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description supplies everything the agent needs: what is returned, when to call it, what it cannot do (link behavior), how fresh the data is, and which sibling handles the adjacent case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's framing of what the returned record contains is a bonus rather than a parameter concern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns) and resource (turva.dev's agent-readiness score from isitagentready.com), including what the payload contains (category sub-scores, measurement date, scanner link). It explicitly distinguishes itself from the sibling get_security_evidence, so the agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger conditions (user asks how turva.dev scores, whether claims are verifiable, what backs the audit) and an explicit alternative for the adjacent case: web-security results belong to get_security_evidence. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns who runs turva.dev and the official ways to reach it: the operator and business details, the email address, the Signal link, the LinkedIn profile, the correspondence languages, the first-reply time and the access an audit needs. Use this when a user asks who is behind turva.dev, how to contact it, how to start an audit or what access has to be granted. For what is sold and what it costs use get_services instead. Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| Yes | ||
| signal | Yes | |
| Yes | ||
| location | Yes | |
| operator | Yes | |
| engagement | Yes | |
| business_id | Yes | |
| first_reply | Yes | |
| channel_note | Yes | |
| how_to_start | Yes | |
| correspondence_languages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds valuable context beyond them: it 'returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.' This tells the agent the result is stable and side-effect free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose and return contents, then adds targeted usage guidance, an alternative-tool pointer, and a concise behavioral note. Every sentence 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description is fully complete: it enumerates the returned contact details, explains when to call it, names the sibling to avoid, and discloses its static read-only nature. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to explain about parameter usage. The schema coverage is 100%, and the description adds no unnecessary parameter information, matching the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Returns') and a precise resource: who runs turva.dev and the official contact/audit-access details. It also distinguishes itself from get_services by naming the alternative explicitly, making the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Use this when a user asks who is behind turva.dev, how to contact it, how to start an audit or what access has to be granted.' It also excludes the sibling alternative: 'For what is sold and what it costs use get_services instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns turva.dev's engagement principles: async-only, least access, the result shows up in scanner numbers, and open and verifiable. Use this when a user asks how turva.dev works with clients or what rules an engagement follows. For what is sold and what it costs use get_services instead, and for how to start use get_contact. Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| rules | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar for extra value is met here. The description adds concrete context by explaining the data is static JSON compiled into the Worker, changes nothing, and only updates on deploy—useful behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry the full message: what is returned, when to use it, and which sibling tools cover adjacent cases. The read-only clarification is folded in efficiently without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter, the description covers output content, usage triggers, sibling routing, and behavioral guarantees. An output schema exists, so return-value shape is already handled; nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and 100% schema description coverage, so the baseline is 4. The description correctly implies there is no input to configure and focuses on output content, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns turva.dev's engagement principles,' and lists the actual content of those principles. It also differentiates from siblings by explicitly naming get_services and get_contact as covering different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Use this when a user asks how turva.dev works with clients or what rules an engagement follows.' It also states exclusions and alternatives: use get_services for pricing and get_contact for how to start, leaving no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the latest public web-security scan results for turva.dev's own domain (Hardenize, Internet.nl site and mail), each with its scan date. Use this when a user asks about turva.dev's own security posture or wants evidence beyond agent-readiness scores. For the agent-readiness score itself, which is a separate measurement, use get_agent_readiness instead. Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| scans | Yes | |
| domain | Yes | |
| measured_at | Yes | Date of the scans, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely new context beyond them: the JSON is static, compiled into the Worker, changes nothing, and updates only on deploy — which tells the agent the data can be stale relative to deploys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: content first, usage/alternative second, behavioral caveat third. No filler, and the most decision-relevant routing information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation in prose. Combined with full routing guidance and the static/deploy caveat, an agent has everything needed to select and call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly avoids inventing parameter-like filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the latest public web-security scan results (Hardenize, Internet.nl site and mail) for turva.dev's own domain, each with a scan date. It explicitly distinguishes itself from the sibling get_agent_readiness by naming the separate agent-readiness measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition (user asks about turva.dev's own security posture or wants evidence beyond agent-readiness scores) and names the alternative tool with the exact condition that routes to it (for the agent-readiness score, use get_agent_readiness instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns turva.dev's service catalog: the Shopify agent storefront check, agent-readiness audit, advisory, implementation, agent operations, and MCP server design, plus the engagement model and pricing (fixed list prices for the Shopify agent storefront check, audit, advisory and implementation; agent operations and MCP server design on request), and two implementation add-ons that carry a fixed price and are sold only with the diagnosis they follow, bought with it, with its report, or after the report and before implementation starts. Use this when a user asks what turva.dev offers, what it costs, or how an engagement works. For how to reach turva.dev use get_contact instead, and for the rules an engagement follows use get_principles. Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| currency | Yes | |
| services | Yes | |
| engagement | Yes | |
| pricing_note | Yes | |
| vat_included | Yes | |
| pricing_model | Yes | |
| bundled_implementation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the response is static JSON compiled into the Worker, changing nothing and updating only on deploy. It stops short of describing the response shape, which the output schema presumably carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and routing sentences are front-loaded and efficient, but the pricing clause runs into a single dense, hard-to-parse construction about add-ons ('bought with it, with its report, or after the report and before implementation starts'). The information earns its place, but one sentence carries too much and hurts readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a static catalog read with an output schema and full annotation coverage, the description supplies everything an agent needs: what it returns, when to call it, and which siblings to use instead. Return-value details are correctly delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema explicitly forbids additional properties, so there is no parameter surface to document. Baseline 4 applies; the description correctly implies a no-argument read with no formatting options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (returns turva.dev's service catalog and pricing) and enumerates the exact offerings, engagement model, and pricing structure. It explicitly distinguishes itself from siblings by naming get_contact and get_principles, so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions ('when a user asks what turva.dev offers, what it costs, or how an engagement works') and names the two alternative tools with the conditions that select them. Nothing about when to prefer this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_security_evidence2 fields changedOutput schema / properties / scans / items / properties / measured_atAdded value: +{
+ "description": "Date of this reading, YYYY-MM-DD, when it differs from the top-level date.",
+ "type": "string"
+}Output schema / properties / scans / items / requiredPrevious value: -[
- "provider"
-]New value: +[
+ "provider",
+ "url"
+]get_security_evidence1 field changedOutput schema / properties / scans / items / requiredPrevious value: -[
- "provider",
- "url"
-]New value: +[
+ "provider"
+]get_contact2 fields changedOutput schema / properties / operatorAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "background": {
+ "type": "string"
+ },
+ "business_id": {
+ "type": "string"
+ },
+ "company_page": {
+ "description": "The turva.dev page that states the business details.",
+ "type": "string"
+ },
+ "legal_form": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "run_by": {
+ "type": "string"
+ },
+ "team": {
+ "type": "string"
+ },
+ "vat_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "run_by",
+ "legal_form",
+ "business_id",
+ "vat_id",
+ "location",
+ "team",
+ "background",
+ "company_page"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "email",
- "signal",
- "linkedin",
- "business_id",
- "location",
- "engagement",
- "correspondence_languages",
- "first_reply",
- "channel_note",
- "how_to_start"
-]New value: +[
+ "email",
+ "signal",
+ "linkedin",
+ "business_id",
+ "location",
+ "engagement",
+ "correspondence_languages",
+ "first_reply",
+ "channel_note",
+ "how_to_start",
+ "operator"
+]get_agent_readiness3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "measured_at": {
+ "description": "Date of the reading, YYYY-MM-DD.",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "scans": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "categories": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "result": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "provider",
+ "result",
+ "note",
+ "categories",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "measured_at",
+ "note",
+ "scans"
+ ],
+ "type": "object"
+}get_contact3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "business_id": {
+ "type": "string"
+ },
+ "channel_note": {
+ "type": "string"
+ },
+ "correspondence_languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "email": {
+ "type": "string"
+ },
+ "engagement": {
+ "type": "string"
+ },
+ "first_reply": {
+ "type": "string"
+ },
+ "how_to_start": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "linkedin": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "signal": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "email",
+ "signal",
+ "linkedin",
+ "business_id",
+ "location",
+ "engagement",
+ "correspondence_languages",
+ "first_reply",
+ "channel_note",
+ "how_to_start"
+ ],
+ "type": "object"
+}get_principles3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "model": {
+ "type": "string"
+ },
+ "rules": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "rationale": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "rationale"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "model",
+ "rules"
+ ],
+ "type": "object"
+}get_security_evidence3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "measured_at": {
+ "description": "Date of the scans, YYYY-MM-DD.",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "scans": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "note": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "result": {
+ "type": "string"
+ },
+ "scale": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "provider",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "measured_at",
+ "scans",
+ "note"
+ ],
+ "type": "object"
+}get_services3 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "bundled_implementation": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "price": {
+ "type": "number"
+ },
+ "requires": {
+ "description": "The id of the service this add-on is sold with.",
+ "type": "string"
+ },
+ "sold_separately": {
+ "type": "boolean"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "unit": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "price",
+ "unit",
+ "requires",
+ "sold_separately",
+ "summary"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "engagement": {
+ "additionalProperties": false,
+ "properties": {
+ "communication": {
+ "type": "string"
+ },
+ "notes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "communication",
+ "notes"
+ ],
+ "type": "object"
+ },
+ "pricing_model": {
+ "type": "string"
+ },
+ "pricing_note": {
+ "type": "string"
+ },
+ "services": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "deliverable": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "minimum_commitment": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "price": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "const": "on request",
+ "type": "string"
+ }
+ ],
+ "description": "EUR, VAT not included, or on request."
+ },
+ "sample_url": {
+ "description": "A published sample of the deliverable, where one exists.",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "unit": {
+ "type": "string"
+ },
+ "url": {
+ "description": "The turva.dev page that describes the service.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "url",
+ "price",
+ "summary",
+ "deliverable"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "vat_included": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "pricing_model",
+ "pricing_note",
+ "currency",
+ "vat_included",
+ "engagement",
+ "services",
+ "bundled_implementation"
+ ],
+ "type": "object"
+}get_contactPublic, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Public read-only MCP server for HODLXXI agent identity, trust, receipts, and verification.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Add one secure layer between your agents and this server.
