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 information domain: readiness scores, security scan evidence, services/pricing, contact details, and engagement principles. The descriptions explicitly cross-reference nearby tools (e.g., readiness vs. security evidence, services vs. contact/principles), making selection unambiguous.
All tools follow a strict get_<noun> snake_case pattern: get_agent_readiness, get_contact, get_principles, get_security_evidence, get_services. There are no deviations or mixed conventions.
Five tools is well-scoped for a static information/evidence server about turva.dev. Each tool corresponds to a distinct user question category, and none feels redundant or missing.
The surface covers the likely informational needs: proof/readiness scores, security evidence, service catalog and pricing, contact/audit-start details, and engagement principles. No obvious lifecycle gaps exist for a read-only static-content server.
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 | A caveat that the scores are a point-in-time reading by an independent scanner and that the scan url opens the scanner's start page. |
| scans | Yes | Readings from independent scanners, one per entry. |
| domain | Yes | The domain the reading is about. |
| 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 cover readOnly/idempotent/non-destructive, but the description adds material traits beyond them: the payload is static JSON compiled into the Worker, changes nothing, and refreshes only on deploy. It also warns that the embedded link does not open the recorded reading, a non-obvious behavioral caveat.
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?
Four sentences that are front-loaded with purpose and contents before usage and behavior. Each sentence carries distinct information, though the description is on the denser end and could be tightened slightly.
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?
With an output schema present and no input parameters, the description needn't explain return values. It nonetheless covers provenance, freshness cadence, the sibling alternative, and a link caveat, leaving nothing an agent needs 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 the baseline is 4. The description still characterizes the returned payload (sub-scores, measurement date, link), though an output schema exists and already documents the response shape.
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 own agent-readiness score from an independent public scanner') and enumerates the contents: category sub-scores, measurement date, and scanner link. It clearly distinguishes itself from sibling tools by naming the distinct data source (isitagentready.com).
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?
Explicitly names the triggering conditions ('when a user asks how turva.dev scores, whether its claims are verifiable, or what proof backs the audit service') and routes the agent away from the wrong tool ('For web-security scan results... use get_security_evidence instead'). Both when-to-use and the closest alternative 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 | The email address for starting an engagement. | |
| signal | Yes | A link that opens a Signal chat with the operator. |
| Yes | The URL of the operator's LinkedIn profile. | |
| location | Yes | The city and country where the business is based. |
| operator | Yes | Who runs turva.dev and the registered business behind it. |
| engagement | Yes | How an engagement is communicated, async_only for written exchange with no calls. |
| business_id | Yes | The Finnish business ID of the business. |
| first_reply | Yes | How soon the first reply comes and by which channels, and that LinkedIn has no set reply time. |
| channel_note | Yes | Which channel suits which kind of message, and that there are no calls. |
| how_to_start | Yes | The steps to start an engagement and the access an audit needs, one per entry. |
| correspondence_languages | Yes | ISO 639-1 codes of the languages the correspondence is held in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the payload is static JSON compiled into the Worker, mutates nothing, and only refreshes on deploy — which tells the agent the data can be stale relative to the live site. It stops short of a 5 only because it says nothing about caching or response size.
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 resource and its contents, then usage, then the sibling exclusion, then the behavioral note — a sensible ordering. The long enumeration of returned fields is slightly redundant given an output schema exists, but each clause still helps an agent judge relevance.
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 tool with a full output schema and four annotations, the description covers everything an agent needs: what it returns, when to call it, when to call something else, and how the data is produced/refreshed. 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, so per the rubric the baseline is 4. The description correctly implies a no-argument call and needs to add no parameter meaning; there is nothing further the schema could document.
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 operator/contact details of turva.dev) and enumerates the concrete payload (email, Signal, LinkedIn, languages, first-reply time, audit access). It also explicitly carves out the sibling boundary against get_services, so an agent can differentiate it without opening schemas.
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 list ('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') and names the alternative tool (get_services) with the condition that selects it. Nothing 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.
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 | The service model the principles belong to, agent_readiness_audit for the agent-readiness audit. |
| rules | Yes | The principles an engagement follows, one per entry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint:false and openWorldHint:false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the payload is static JSON compiled into the Worker, mutates nothing, and only refreshes on deploy — which tells the agent the answer can be stale relative to a release. It stops short of mentioning any auth or rate-limit behavior, so it is short of a 5.
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, front-loaded with what is returned, then when to use it, then sibling routing and behavioral caveats. Every sentence carries distinct information 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?
An output schema exists, so the description need not document return values. For a zero-parameter, read-only static-content tool with full annotation coverage, the description supplies everything an agent needs to select and call 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 per the baseline rule a 4 applies. The description correctly says nothing about inputs, and there is no schema surface left unexplained.
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 engagement principles') and enumerates the actual content (async-only, least access, scanner-visible results, open and verifiable), so an agent knows exactly what payload to expect. It also explicitly separates itself from get_services and get_contact, so it is distinguishable from siblings without opening any 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 an explicit trigger ('Use this when a user asks how turva.dev works with clients or what rules an engagement follows') plus routing rules for the two adjacent intents — pricing/offerings go to get_services, onboarding goes to get_contact. Nothing about when-not-to-use 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.
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 | Why turva.dev publishes the scan results of its own domain. |
| scans | Yes | Web-security scan results, one per provider and test. |
| domain | Yes | The domain the scans are about. |
| 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 readOnly/idempotent/non-destructive, and the description reinforces that while adding a trait the annotations cannot express: the data is static JSON compiled into the Worker, changes nothing, and refreshes only on deploy. That freshness/provenance caveat is genuinely useful for an agent deciding whether to present the results as current.
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, front-loaded with what is returned and scoped before the routing guidance. Every sentence carries load: purpose, when-to-use/alternative, and the read-only/static-data note.
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 prose explanation, and the description still names the three sources and the scan-date field. For a zero-parameter, read-only lookup tool, an agent has everything needed to select and call 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 the baseline is 4 and there is no argument syntax the description could clarify. It does implicitly bound the output by naming the three scan sources and the included scan date, which adds a little orientation for a no-arg call.
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'), names the domain scope (turva.dev's own domain), and enumerates the three underlying sources (Hardenize, Internet.nl site and mail). It explicitly distinguishes itself from the sibling get_agent_readiness, so an agent can route between them 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 an explicit when-to-use condition ('when a user asks about turva.dev's own security posture or wants evidence beyond agent-readiness scores') and names the alternative plus the condition that selects it ('For the agent-readiness score itself ... use get_agent_readiness instead'). Both the use case and the exclusion are stated, leaving nothing to inference.
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. The Shopify agent storefront check and the audit each link a published sample report in sample_url, a fictional worked example of the deliverable. Use this when a user asks what turva.dev offers, what it costs, how an engagement works, or what a delivered report looks like. 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 | ISO 4217 code of every price, EUR. |
| services | Yes | The services with their prices. |
| engagement | Yes | How an engagement is run. |
| pricing_note | Yes | The VAT treatment by customer type, the services quoted per engagement and the rule for the add-ons. |
| vat_included | Yes | Whether the prices include VAT. False means every price excludes VAT. |
| pricing_model | Yes | The pricing model. fixed_list_prices means fixed list prices, apart from the services priced on request. |
| bundled_implementation | Yes | Implementation add-ons that are sold only with another service. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/closed-world, but the description adds genuinely new behavior: the data is static JSON compiled into the Worker, so it updates only on deploy. That's useful context for an agent reasoning about staleness. It doesn't state response size or shape, but the output schema covers that.
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 and scoped well in the first and third sentences, but the pricing/add-on sentence is a long run-on with redundant phrasing ('bought with it, with its report, or after the report and before implementation starts'). Detail that belongs in the returned payload is restated in the description.
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, the description gives enough to know what's covered (offerings, fixed vs. on-request pricing, sample URLs) and what isn't (contact, principles). Nothing needed to invoke it correctly 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?
The tool takes zero parameters, so the baseline is 4. The description does not need to compensate for anything since there is nothing to parameterize.
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?
Opens with a specific verb+resource ('Returns turva.dev's service catalog') and enumerates the catalog's contents — offerings, engagement model, pricing, add-ons, sample reports. An agent can distinguish this from get_contact, get_principles, and get_agent_readiness without opening any 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?
Explicit trigger conditions: 'Use this when a user asks what turva.dev offers, what it costs, how an engagement works, or what a delivered report looks like.' It also names the two alternative tools (get_contact, get_principles) and the conditions that select them.
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_services1 field changedOutput schema / properties / services / items / properties / duration_fromAdded value: +{
+ "description": "The event the duration counts from, where the service states one.",
+ "type": "string"
+}get_agent_readiness9 fields changedOutput schema / properties / domain / descriptionAdded value: +"The domain the reading is about."Output schema / properties / note / descriptionAdded value: +"A caveat that the scores are a point-in-time reading by an independent scanner and that the scan url opens the scanner's start page."Output schema / properties / scans / descriptionAdded value: +"Readings from independent scanners, one per entry."Output schema / properties / scans / items / properties / categories / additionalProperties / descriptionAdded value: +"The category score as text, out of 100."Output schema / properties / scans / items / properties / categories / descriptionAdded value: +"Sub-scores by category. Each key is a category name: discoverability, content, bot_access_control, api_auth_mcp_a2a_discovery or commerce."Output schema / properties / scans / items / properties / note / descriptionAdded value: +"Who runs the scanner and a reminder that the reading is the scanner's and can be re-run by anyone."Output schema / properties / scans / items / properties / provider / descriptionAdded value: +"The domain of the scanner that produced the reading."Output schema / properties / scans / items / properties / result / descriptionAdded value: +"The scanner's overall result as text, giving the score out of 100 and the level reached."Output schema / properties / scans / items / properties / url / descriptionAdded value: +"The scanner's start page, where a new check can be run. It does not show the recorded reading."get_contact21 fields changedOutput schema / properties / business_id / descriptionAdded value: +"The Finnish business ID of the business."Output schema / properties / channel_note / descriptionAdded value: +"Which channel suits which kind of message, and that there are no calls."Output schema / properties / correspondence_languages / descriptionAdded value: +"ISO 639-1 codes of the languages the correspondence is held in."Output schema / properties / correspondence_languages / items / descriptionAdded value: +"An ISO 639-1 language code."Output schema / properties / email / descriptionAdded value: +"The email address for starting an engagement."Output schema / properties / engagement / descriptionAdded value: +"How an engagement is communicated, async_only for written exchange with no calls."Output schema / properties / first_reply / descriptionAdded value: +"How soon the first reply comes and by which channels, and that LinkedIn has no set reply time."Output schema / properties / how_to_start / descriptionAdded value: +"The steps to start an engagement and the access an audit needs, one per entry."Output schema / properties / how_to_start / items / descriptionAdded value: +"One step as a sentence."Output schema / properties / linkedin / descriptionAdded value: +"The URL of the operator's LinkedIn profile."Output schema / properties / location / descriptionAdded value: +"The city and country where the business is based."Output schema / properties / operator / descriptionAdded value: +"Who runs turva.dev and the registered business behind it."Output schema / properties / operator / properties / background / descriptionAdded value: +"The professional background of the person who runs the business."Output schema / properties / operator / properties / business_id / descriptionAdded value: +"The Finnish business ID of the business."Output schema / properties / operator / properties / legal_form / descriptionAdded value: +"The legal form of the business."Output schema / properties / operator / properties / location / descriptionAdded value: +"Where the business is based: city, region and country."Output schema / properties / operator / properties / name / descriptionAdded value: +"The trading name of the business."Output schema / properties / operator / properties / run_by / descriptionAdded value: +"The person who runs the business."Output schema / properties / operator / properties / team / descriptionAdded value: +"Who works at the business and how clients work with them."Output schema / properties / operator / properties / vat_id / descriptionAdded value: +"The VAT identification number of the business."Output schema / properties / signal / descriptionAdded value: +"A link that opens a Signal chat with the operator."get_principles5 fields changedOutput schema / properties / model / descriptionAdded value: +"The service model the principles belong to, agent_readiness_audit for the agent-readiness audit."Output schema / properties / rules / descriptionAdded value: +"The principles an engagement follows, one per entry."Output schema / properties / rules / items / properties / id / descriptionAdded value: +"Stable identifier of the principle."Output schema / properties / rules / items / properties / rationale / descriptionAdded value: +"What the principle means in practice and why it holds."Output schema / properties / rules / items / properties / title / descriptionAdded value: +"The principle in a short phrase."get_security_evidence10 fields changedOutput schema / properties / domain / descriptionAdded value: +"The domain the scans are about."Output schema / properties / note / descriptionAdded value: +"Why turva.dev publishes the scan results of its own domain."Output schema / properties / scans / descriptionAdded value: +"Web-security scan results, one per provider and test."Output schema / properties / scans / items / properties / measured_at / descriptionPrevious value: -"Date of this reading, YYYY-MM-DD, when it differs from the top-level date."New value: +"Date of this reading, YYYY-MM-DD, on a reading that carries its own date. It can equal the top-level date."Output schema / properties / scans / items / properties / note / descriptionAdded value: +"What passed in full and where the points were lost. Absent when the provider adds no note."Output schema / properties / scans / items / properties / provider / descriptionAdded value: +"The name of the scan provider."Output schema / properties / scans / items / properties / result / descriptionAdded value: +"The overall result as text, for a provider that reports passed categories instead of a number. Absent when a numeric score is given."Output schema / properties / scans / items / properties / scale / descriptionAdded value: +"The range of the score, written as low-high. Absent when there is no numeric score."Output schema / properties / scans / items / properties / score / descriptionAdded value: +"The numeric score, on the range given in scale. Absent when the provider reports a text result."Output schema / properties / scans / items / properties / url / descriptionAdded value: +"The provider's public report page for the domain."get_services1 field changedOutput schema / properties / engagement / properties / notes / items / descriptionAdded value: +"One term of an engagement as a sentence."get_services22 fields changedOutput schema / properties / bundled_implementation / descriptionAdded value: +"Implementation add-ons that are sold only with another service."Output schema / properties / bundled_implementation / items / properties / id / descriptionAdded value: +"Stable identifier of the add-on."Output schema / properties / bundled_implementation / items / properties / name / descriptionAdded value: +"The name of the add-on."Output schema / properties / bundled_implementation / items / properties / price / descriptionAdded value: +"Price in EUR, VAT not included."Output schema / properties / bundled_implementation / items / properties / sold_separately / descriptionAdded value: +"Whether the add-on can be bought without its service. False means it cannot."Output schema / properties / bundled_implementation / items / properties / summary / descriptionAdded value: +"What the add-on covers and when it is bought."Output schema / properties / bundled_implementation / items / properties / unit / descriptionAdded value: +"What the price covers, such as fixed."Output schema / properties / currency / descriptionAdded value: +"ISO 4217 code of every price, EUR."Output schema / properties / engagement / descriptionAdded value: +"How an engagement is run."Output schema / properties / engagement / properties / communication / descriptionAdded value: +"How an engagement is communicated, async_only for written exchange with no calls."Output schema / properties / engagement / properties / notes / descriptionAdded value: +"Terms of an engagement, one per entry, covering access, scope, dates and completion."Output schema / properties / pricing_model / descriptionAdded value: +"The pricing model. fixed_list_prices means fixed list prices, apart from the services priced on request."Output schema / properties / pricing_note / descriptionAdded value: +"The VAT treatment by customer type, the services quoted per engagement and the rule for the add-ons."Output schema / properties / services / descriptionAdded value: +"The services with their prices."Output schema / properties / services / items / properties / deliverable / descriptionAdded value: +"What the customer receives and when."Output schema / properties / services / items / properties / duration / descriptionAdded value: +"How long delivery takes, where the service states one."Output schema / properties / services / items / properties / id / descriptionAdded value: +"Stable identifier of the service."Output schema / properties / services / items / properties / minimum_commitment / descriptionAdded value: +"The shortest term the service is sold for, where one applies."Output schema / properties / services / items / properties / name / descriptionAdded value: +"The name of the service."Output schema / properties / services / items / properties / summary / descriptionAdded value: +"What the service covers and its scope."Output schema / properties / services / items / properties / unit / descriptionAdded value: +"What the price covers, such as fixed, month or day. Absent when the price is on request."Output schema / properties / vat_included / descriptionAdded value: +"Whether the prices include VAT. False means every price excludes VAT."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"
+]Public, 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.
