CODENIVERSE MCP

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: it returns the complete article body plus a canonical url, and the agent is instructed to attribute that url whenever the content is reused — a real constraint that annotations cannot express.

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 compact clauses that front-load the purpose, then the identifier, then the attribution rule — no filler. The only minor weakness is that the citation instruction arrives abruptly with no framing of what 'the canonical url provided' refers to for an agent that has not yet seen a response.

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 one-parameter, read-only lookup with no output schema, the description covers what the agent needs: what comes back (full article content), how to select it (slug), and the attribution obligation. The language mismatch (Thai description, English tool/sibling names) and the unstated search_articles-to-slug workflow are the only residual gaps.

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?

There is a single required parameter with 100% schema coverage, and the schema already explains the slug format and that it comes from search_articles. The description only restates that the item is identified by slug, adding no format, length or sourcing detail beyond the schema — the 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?

States a specific verb ('อ่านเนื้อหาเต็ม' – read the full content) and a specific resource (CODENIVERSE Insights articles), plus the identifier used to select one (slug). It implicitly separates itself from search_articles by emphasizing 'full content' rather than search, but never names that sibling explicitly, so the differentiation is inferred rather than stated.

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?

Use is implied: you fetch one article by slug, and the citation rule ('always cite the canonical url') gives conditional output guidance. However, the description never says when to reach for this instead of search_articles or get_page, nor any prerequisite such as 'obtain the slug from search_articles first' — that hint lives only in the schema, not the description.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds value by disclosing the kind of content returned (founders, experience, principles, contact) rather than restating the annotations. Minor gap: no indication of static vs. live data 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?

A single, front-loaded sentence gives scope, clause excluding company search, content list, and triggers. Every clause earns its place with 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?

With zero params and no output schema, the description carries the return-value burden and does so by listing what the profile covers. Complete enough for an agent to call it and interpret the result; only the exact return structure remains unspecified.

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 applies and there is nothing extra the description could clarify. The description correctly implies no input is needed, since it is scoped to one company.

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 (the CODENIVERSE company profile) and explicitly disclaims being a company-search system, which separates it from siblings like search_articles and search_faq. It also enumerates the content covered (founders, experience, principles, contact channels), so an agent knows exactly what it returns.

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: use when the user asks who the company is, who the CEO is, or how trustworthy it is. It also implicitly excludes company-search via the parenthetical. No explicit when-not list beyond that, so not a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds value beyond that: it specifies that the response is the *full* page content and imposes an output convention (always cite the page url). With no output schema, this disclosure of return shape is genuinely useful.

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 sentences, front-loaded with the action, then the usage condition and output rule. The slug enumeration is long but earns its place as a usage constraint; nothing is 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 single-parameter read tool with no output schema, the description covers what is returned (full page content), the domain of valid inputs, and the required output convention. Only the absence of explicit sibling routing keeps it from a 5.

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 coverage is 100%, so the baseline is 3, but the description goes further by enumerating the valid slug universe (the static pages plus services/<slug> for all 12 services), which effectively acts as an enum hint not present in 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 verb (อ่านเนื้อหาเต็ม = read full content) and resource (one CODENIVERSE web page), and enumerates the exact page set (about, contact, faq, terms, privacy, services/<slug>, all 12 services). An agent can distinguish this from get_article or get_company_profile purely from the description.

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?

Offers a usage condition ("use when you need service details or company info beyond what other tools provide"), which implies a boundary with siblings, but never names which sibling to prefer for which case (get_company_profile, get_article, list_services). The routing guidance is real but left to inference.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety needs no restating. The description adds the useful return shape (12 items, brief summary, service page link), which annotations cannot convey and no output schema exists to cover.

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 compact sentence pair: content first, usage trigger second, no filler or repetition of the annotations.

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 params and no output schema, the description carries the return-value burden and does so adequately. It could note that results are static company content (e.g. language of the returned text), but 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly implies a fixed, unfiltered listing of all 12 services.

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 concrete resource (the 12 service offerings of CODENIVERSE, a Thai software dev company) and what comes back with them (short summaries plus links to service pages). Scope is unambiguous and clearly distinct from get_company_profile or get_page, though it never names those siblings.

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 when the user asks what this company does or what they can be hired for. No exclusions or alternative routing (e.g. point to get_company_profile for history/contact) are mentioned, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world corpus, so the safety profile is covered. The description adds value beyond them by disclosing the shape of the result (title, description, url) and a hard behavioral requirement that answers must cite the article url — information the annotations do not carry. It omits ranking order and result-count limits.

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 compact clauses: what is searched, what is returned, how to use the result. The scope information is front-loaded and nothing is redundant. It could be tightened slightly, but every sentence earns its place.

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 single-parameter read-only search tool with rich annotations and full schema coverage, the description supplies everything an agent still needs: the corpus boundary, the return fields, and the citation obligation. No output schema exists, yet the return values are described inline, so nothing material 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?

Schema description coverage is 100% and the single 'query' parameter already documents that a single word or short phrase works better than a long sentence, including an example. The description only restates 'from a search term', adding no syntax or formatting detail beyond the schema, so the baseline of 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 (search) plus resource (articles authored by the CODENIVERSE team) and enumerates the covered topic areas (AI agent, automation, cloud, SEO, digital transformation), which makes the corpus scope unambiguous. It also names the returned fields. It stops short of explicitly contrasting with siblings like search_faq or get_article, so a 4 rather than a 5.

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: the reader infers it should be called for keyword lookups over the article corpus, and the closing line mandates citing the article url in the answer. There is no explicit statement of when NOT to use it, nor a pointer to search_faq or get_article as alternatives, leaving routing to inference.

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

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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered; the description adds real value beyond them by disclosing corpus size (58 items), the content boundaries of that corpus, and an output obligation ('ตอบโดยอ้างลิงก์หน้าต้นทางด้วย' — cite the source page link in the answer). It does not discuss result limits or ranking behavior, keeping it below 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 compact clauses — what it searches, when to use it, and how to present results — with the resource and its scope front-loaded. Nothing is padding, though the parenthetical topic list is somewhat dense for a single sentence.

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 single-parameter read-only lookup with full schema coverage and annotations, the description supplies everything an agent needs: scope, when to invoke, and the citation requirement for the answer. The absence of an output schema is largely mitigated by the citation instruction, though return shape (list of Q&A vs single match) remains unstated.

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 the schema itself already carries the key query advice (short keyword beats long sentence), so the schema does the heavy lifting. The description adds no further guidance on how to shape the query string, making this the adequate baseline of 3.

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 ('ค้น' / search) and a specific resource (the CODENIVERSE official FAQ, 58 items) and enumerates the topic scope (terms of service, duration, pricing, hiring, post-delivery care). This clearly separates it from siblings like search_articles and get_article without the agent needing to open 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?

Explicitly instructs 'ใช้ก่อนตอบคำถามเชิงเงื่อนไขของบริษัทเสมอ' — always use this before answering conditional/terms questions about the company, which is a concrete triggering condition. It does not explicitly name when to prefer a sibling (e.g. search_articles for non-FAQ content), so it stops short of full alternative routing.

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

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

Annotations already disclose the safety profile (not read-only, open-world, not idempotent, not destructive), but the description adds real value on top: the message goes to an external team, the reply arrives by email within the same business day, and a confirmation step is required before invocation. It doesn't discuss rate limits or duplicate-submission handling, so not a full 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?

Purpose and the CRM disambiguation come first, then the trigger conditions, then the data-integrity and confirmation constraints, then the response SLA. Each sentence carries a distinct, actionable instruction with no repetition of the schema.

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?

This is a fire-and-forget outbound submission with no output schema, and the description closes exactly that gap by telling the agent the outcome (email reply within one business day) so it can set expectations. The anti-fabrication and confirmation rules cover the remaining risk for a one-way external send.

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 coverage is 100%, so the baseline is 3. The description goes further by constraining how required fields get populated — never invent names or emails, ask the user first — which is the main failure mode for a form-filling tool and isn't captured by the per-field 'do not guess' notes on the required properties alone.

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: sending a request to the CODENIVERSE team so they contact the user back. It explicitly disambiguates from the plausible misreading (saving a lead into the user's own CRM), which is exactly the confusion a sibling named 'submit_lead' invites.

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?

Names concrete triggering conditions (user wants to discuss a project, request a quote, or be contacted back) and adds hard preconditions: only use real user-supplied data, ask the user for a missing name or email, and confirm intent before calling. The siblings are all read-only retrieval tools, so no further routing is needed.

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