Read-only MCP server for turva.dev's published service catalog, pricing and contact details. Five tools return JSON, including dated agent-readiness and security evidence with verification links. Connect over Streamable HTTP without an API key. The server answers questions about turva.dev and does not scan other websites or run audits.
Scored across 5 tools
Each tool returns a distinct category of information—readiness score, contact details, principles, security evidence, and service catalog. Descriptions include explicit cross-references to prevent confusion, and no two tools overlap in purpose.
All tool names follow a consistent get_<noun> pattern with clear, descriptive second words. The naming is uniform, predictable, and accurately reflects each tool's function.
Five tools is well-scoped for a lightweight informational MCP server. Each tool covers a necessary aspect of the site's public profile without redundancy or unnecessary bloat.
The tool set covers the apparent domain completely: readiness, security evidence, services/pricing, contact, and operating principles. Descriptions also cross-reference related tools, leaving no obvious dead ends or missing information for common user queries.
Returns turva.dev's own agent-readiness score from an independent public scanner (isitagentready.com), including category sub-scores, with the measurement date and verification links. 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it is read-only and returns static JSON compiled into the Worker, noting it changes nothing and updates only on deploy. This goes beyond the annotations by explaining the static nature and update behavior.
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 is concise and well-structured, using two sentences to cover purpose, usage, and alternatives. It front-loads the key action and result, with no superfluous detail.
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?
Despite having no output schema, the description sufficiently describes the returned content: score, category sub-scores, measurement date, and verification links. It also provides usage context and distinguishes from a sibling tool, making the tool's role complete.
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 has no parameters, so there is no parameter information to add beyond the empty schema. The description provides relevant output context instead, which is appropriate given the zero-parameter interface.
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 clearly states that the tool returns turva.dev's agent-readiness score from an independent public scanner, including category sub-scores, measurement date, and verification links. It also distinguishes itself from get_security_evidence, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: when a user asks how turva.dev scores, whether claims are verifiable, or what proof backs the audit service. It also names the alternative for web-security scan results, providing clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the official ways to reach turva.dev and what starting an engagement takes: the email address, the Signal link, the LinkedIn profile, the business ID and location, the correspondence languages, the first-reply time, and the access an audit needs. Use this when a user asks how to contact turva.dev, 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotation, the description reveals that the tool returns static JSON compiled into the Worker, changes nothing, and updates only on deploy. This gives the agent a deeper understanding of the data's nature and freshness.
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 is well-organized: it first states the output contents, then gives usage guidance, then differentiates from a sibling, and finally notes the static nature. Each sentence adds unique value with no redundancy or unnecessary detail.
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?
Since there is no output schema, the description compensates by enumerating the exact fields returned (email, Signal, LinkedIn, business ID, location, languages, reply time, access needs). This gives the agent a complete picture of what to expect from the tool.
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 has zero parameters, so there is nothing ambiguous to explain. The description correctly implies that no input is required, and the schema confirms an empty properties object, making parameter semantics entirely clear.
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 clearly states the tool's purpose: returning official contact and engagement-starting details for turva.dev, including a specific list of items. It also distinguishes itself from the sibling tool get_services, making its scope unambiguous.
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 instructions are given for when to use this tool: when a user asks about contacting turva.dev, starting an audit, or required access. It also specifies the alternative (get_services) for pricing inquiries, providing clear routing guidance.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavioral detail: it returns static JSON compiled into the Worker, changes nothing, and updates only on deploy. This clarifies the data lifecycle and that no side effects occur, going beyond the structured hints.
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 pack all essential information: the returned content, when to use it, alternatives, and read-only/deploy behavior. The main action is front-loaded, and every sentence contributes value without redundancy.
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 no parameters, no output schema, and annotations covering safety, the description fully covers what the tool returns, its usage context, alternatives, and behavioral guarantees. Nothing an agent needs to call 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 has zero parameters, and the schema is trivially covered (100% with no properties). The description adds no parameter-specific semantics because there are none; per the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description does not need to compensate.
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 the specific verb 'returns' with a clear resource 'turva.dev's engagement principles' and enumerates the content (async-only, least access, scanner numbers, open/verifiable). It explicitly distinguishes itself from siblings by naming get_services and get_contact, so an agent can easily tell them apart without opening their 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?
Provides explicit when-to-use guidance ('when a user asks how turva.dev works with clients or what rules an engagement follows') and names alternatives with their conditions ('for what is sold and what it costs use get_services instead, and for how to start use get_contact'). This fully routes the agent to the correct 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), with the 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by stating 'Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.' This clearly discloses side-effect-free behavior and update characteristics, matching the readOnly and idempotent 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?
The description is concise, consisting of two sentences that cover purpose, usage, and behavioral notes without redundant information. It is well-structured and front-loads the core function.
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?
Given the absence of parameters and output schema, the description provides all necessary context: what the tool returns, when to use it, and its side-effect-free nature. It also names sibling distinctions, making the tool's role fully clear.
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 has no parameters, and the schema correctly reflects an empty object. The description adds no unnecessary parameter details, and since there are no parameters to explain, the description is fully adequate.
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 clearly states the tool returns the latest public web-security scan results for turva.dev's own domain, naming specific sources (Hardenize, Internet.nl site and mail) and including the scan date. It explicitly distinguishes from get_agent_readiness, so an agent can easily differentiate.
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?
The description explicitly says 'Use this when a user asks about turva.dev's own security posture or wants evidence beyond agent-readiness scores.' It also names the alternative tool for the agent-readiness score, providing direct guidance on when to use this tool versus the sibling.
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 together with the diagnosis they follow. 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds context that the data is static JSON compiled into the Worker and only changes on deploy, which reinforces the read-only nature. No contradiction exists.
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 is clear and well-structured, but it contains some repetition when listing services and pricing details (e.g., listing the services twice). It could be tightened slightly, but it remains accessible and not overly verbose.
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 no parameters and no output schema, the description covers all necessary context: what the tool returns, what it includes, when to use it, and how it differs from sibling tools. The agent has complete information to decide and invoke 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 has no parameters, so there is nothing to document. The description does not need to elaborate on parameter semantics; the schema fully covers this aspect. A score above baseline is warranted because the absence of parameters is itself clear.
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 clearly states that the tool returns turva.dev's service catalog, enumerating the specific services and mentioning engagement model and pricing. It also distinguishes itself from sibling tools by explicitly noting what it does not cover (contact info and principles).
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?
The description explicitly instructs when to use this tool ('when a user asks what turva.dev offers, what it costs, or how an engagement works') and when to use alternatives (get_contact for reach info, get_principles for rules). This provides clear decision guidance.
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_contactget_agent_readiness1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"get_principles1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"get_security_evidence1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"get_services1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Independent trust scores, tool surfaces and change history for MCP servers.
Add one secure layer between your agents and this server.
