Read Novaeon Studio (AI agent factory, SAP agents) as markdown and send an inquiry.
Scored across 4 tools
The three read tools target different granularities: one page, all pages concatenated, and a synthesized overview with links. They are distinguishable in principle, but get_full_content and get_studio_overview overlap in content and an agent might grab all of it when one page would suffice.
Every tool follows the same verb_noun snake_case pattern (get_full_content, get_page, get_studio_overview, submit_inquiry). Prefix and style are uniform across the whole set.
Four tools is on the lean side, but it matches the scope of a small studio site: read one page, read everything, read a summary, send a message. Every tool has a clear reason to exist with no filler.
The surface covers the full content-read plus contact lifecycle for a brochure site, with the overview acting as a sitemap. Minor gaps only, such as no direct page listing or search, which agents can work around via the overview.
The complete site copy (all sections) as one markdown document (llms-full.txt).
| 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 openWorldHint=false, so the safety profile is covered. The description usefully discloses the output shape (one markdown document, llms-full.txt) but omits the trait that most affects behavior for a whole-site dump: size/token cost and whether content is truncated.
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?
A single short sentence with the scope qualifier ('all sections') and the output format front-loaded. Nothing redundant or padded.
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 no-parameter, no-output-schema read tool the description covers what is returned and in what form. The one meaningful gap is magnitude — an agent has no signal about how large this response will be relative to get_page.
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 disambiguate; baseline 4 applies. The mention of llms-full.txt adds a small amount of context about the source of the content.
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 resource and scope: the complete site copy across all sections, returned as a single markdown document, with the underlying artifact named (llms-full.txt). It is clearly distinguishable from get_page by the 'all sections' framing, though it never names that sibling.
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?
Usage is only implied: 'all sections' suggests this is the whole-site option versus a single-page fetch, but the description never says when to choose it over get_page or warns that it is the expensive choice. The agent must infer the branching condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Markdown version of one novaeon.studio page. Examples: "/", "/ro/", "/de/", "/legal-notice", "/privacy".
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Page path or full https://novaeon.studio URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the output format (Markdown) and sample paths, but says nothing about missing pages, redirects, or other runtime 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?
Two short sentences, front-loaded with the core behavior and followed by useful path examples. No wasted text.
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 one-parameter read tool with annotations and full schema coverage, the description covers purpose and output format adequately. A note on error handling or sibling differentiation would make it 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?
Schema description coverage is 100%, including that the path can be a page path or full URL. The examples reinforce accepted path shapes but do not add syntax or constraints beyond the schema.
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 resource and return format: a Markdown version of one novaeon.studio page. It is clear what the tool does, but it does not distinguish itself from siblings such as get_full_content or get_studio_overview.
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 examples show valid path formats but give no guidance on when to use this instead of get_full_content or get_studio_overview. There are no exclusions or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Concise overview of Novaeon: what the studio builds, how it works and links to every page. Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the operation is safe (readOnlyHint: true). The description adds crucial behavioral context by specifying the output is a 'concise' summary and formatted in Markdown, which goes beyond basic safety 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?
It is a single, powerful sentence that defines the scope, content, and format of the output without unnecessary jargon or fluff.
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 tool with zero parameters, the description is complete by defining exactly what kind of information is included in the output (scope, content categories, and format).
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?
With zero parameters and 100% schema coverage, the baseline score applies. The description is sufficient for this parameter-less 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 explicitly states its function: providing a concise overview of Novaeon, detailing what the studio builds and how it operates. This clearly defines the tool's purpose as a high-level summary tool compared to specific detail retrieval.
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?
While it doesn't explicitly contrast itself with sibling tools like get_page, the phrasing 'concise overview' implies it should be used when the user needs a summary rather than deep, specific content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an inquiry to Novaeon on behalf of a person (same as the contact form; they reply by email). Only call this when the person asked to contact Novaeon and agreed to share their name and email. Rate limited.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the person | |
| Yes | Email address Novaeon should reply to | ||
| phone | No | Phone number (optional) | |
| company | No | Company and/or role (optional) | |
| consent | Yes | Must be true: the person agrees Novaeon stores these details to answer (https://novaeon.studio/privacy). | |
| message | Yes | What they need (project, problem, questions). At least 10 characters. | |
| language | No | Preferred language code, e.g. en, ro, de (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write, open-world, non-idempotent and non-destructive, and the description adds meaningful context beyond them: the reply-by-email channel and the 'Rate limited' trait, which annotations do not express. It stops short of explaining failure behavior or what a rate-limit hit looks like, so not 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 tight sentences: purpose first, then the consent gating, then the rate-limit caveat. No redundancy and every clause carries actionable information.
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 write tool with open-world side effects and no output schema, the description covers purpose, consent precondition, delivery channel, and rate limiting — enough to call it correctly. Slight gap: no guidance on what success/failure looks like since there is no 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?
Schema description coverage is 100% and each parameter (name, email, phone, company, consent, message, language) is documented in the schema itself. The description only reiterates the name/email sharing condition, adding no field-level meaning beyond the schema, so baseline 3 applies.
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 states a specific verb and resource ('Send an inquiry to Novaeon') plus the delivery mechanism ('same as the contact form; they reply by email'). This unambiguously separates it from the read-only siblings (get_full_content, get_page, get_studio_overview), which are all content-fetching tools.
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 gating is given: 'Only call this when the person asked to contact Novaeon and agreed to share their name and email.' The precondition (explicit request + consent) is exactly the when-to-call signal an agent needs, and no sibling overlaps so no alternative routing is required.
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_full_contentget_pageget_studio_overviewsubmit_inquiryRead authorized public pages as Markdown or HTML metadata. Operated by an autonomous AI agent.
Agent document workspace with wallet auth. Create, update and share markdown docs. By AutEng.ai
Markdown workspace for AI agents: read, write, organize, and share markdown documents.
Ask Universal Agents what we sell (Interplay), pricing, and FAQs; draft an intro email.
Add one secure layer between your agents and this server.
