CODENIVERSE MCP

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

No annotations provided, so description carries full burden. It indicates a read operation and mentions canonical URL, but does not detail return format, error handling, or other behavioral aspects. Adequate but could be richer.

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 efficient sentences: first states purpose and parameter, second gives usage instruction. Front-loaded with key info, no wasted words.

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 single-parameter tool with no output schema, the description is complete: explains what it does, how to call it (slug from sibling), and what to do with the response (cite URL). No 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?

Schema coverage is 100% with good parameter description. The tool description adds little beyond the schema, just emphasis on reading full content. Baseline 3 is appropriate.

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 it reads full content of Insights articles by slug, distinguishing it from sibling search_articles which returns summaries. It also specifies to cite the canonical URL.

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 implies using this after search_articles by mentioning slug from search_articles and provides a usage rule (cite canonical URL). Lacks explicit when-not-to-use but context is clear.

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?

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like read-only nature, side effects, or auth requirements. It only describes content, not 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?

Description is concise (a few sentences) and front-loaded with the main purpose and use cases. No unnecessary words.

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 no output schema, the description adequately summarizes return content (founders, experience, principles, contacts). Could be more explicit about structure, but sufficient for a simple 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?

No parameters exist, and schema coverage is 100%. Description does not need to add param info. Baseline score of 4 is appropriate.

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?

Description clearly states it retrieves the profile of CODENIVERSE company itself, not a search for others, and lists covered aspects (founders, experience, principles, contacts). It distinguishes from siblings which are articles, pages, services, search, and lead submission.

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 says when to use: when the user asks who the company is, who the CEO is, how reliable it is. Also notes it's not a search system for other companies, implying when not to use. No alternative tools are mentioned, but siblings are not similar.

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?

With no annotations provided, the description carries the transparency burden. It communicates that the tool returns full page content and instructs the assistant to always cite the page URL, but it does not disclose potential failure modes, output shape, or other behavioral constraints.

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 one compact sentence that includes purpose, scope, usage guidance, and output instruction. It has no padding or redundant restatement of the tool name.

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 single-parameter retrieval tool, the description provides sufficient context: what is returned, what page families exist, and how to cite URLs. It does not cover edge cases like unknown slugs, but the high schema coverage and low parameter count make it fairly 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 schema already documents the slug parameter well with format guidance and examples, so the baseline is strong. The description adds value by listing the exact valid page categories and explaining the services/<slug> pattern for the 12 services, giving richer semantic context.

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 specifies a concrete action — reading the full content of one CODENIVERSE page — and enumerates the valid slug categories such as about, contact, faq, terms, privacy, services, and services/<slug>. It also distinguishes itself from sibling tools by emphasizing that it provides details beyond what other tools give.

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 states when to use it: when the user needs service details or company information beyond what other tools provide. It does not name specific sibling alternatives or list exclusion conditions, but it gives clear contextual 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?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions that the output includes a short summary and a link to the service page, which gives some insight into what the tool returns. However, it does not state any side effects, access requirements, or whether the data is static or dynamic. For a simple read-only listing, this is adequate but not rich, warranting a mid-range score.

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 a single sentence that front-loads the core purpose (listing 12 services with summary and link) and then provides usage context. Every part serves a function, with no redundancy or fluff. It is appropriately concise and well-structured.

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 tool's simplicity (no parameters, no output schema), the description is fully complete. It states what the tool returns (list of services, summary, link) and when to use it. There are no additional complexities like authentication or side effects that need explanation. The description covers all necessary information for an agent to select and invoke the tool 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 zero parameters, and the schema coverage is 100% (empty properties). Per the rubric, the baseline for 0 parameters is 4. The description does not add parameter-specific details because there are none, but it provides contextual information about the content, which is sufficient. No deduction needed.

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: listing the 12 services offered by CODENIVERSE, with a summary and link. The verb 'list' is explicit, and the resource (services) is well-defined. It also differentiates from siblings like get_company_profile or get_article by focusing specifically on service offerings.

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 states when to use the tool: 'use when the user asks what work this company accepts or what can be hired for.' This is clear usage guidance. However, it does not mention when not to use it or suggest alternative tools, so it falls short of a perfect score per the rubric.

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?

No annotations are provided, so the description must carry the burden. It discloses that the tool returns title, description, and URL, and instructs to always reference the URL in responses. However, it does not mention pagination, sorting, or any side effects (likely read-only). Adequate but lacks depth.

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 a single sentence but covers the main action, scope, and output. It could be more concise by separating the behavioral instruction, but it is not overly verbose. The front-loading is adequate.

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 tool's simplicity (one parameter, no output schema, no nested objects), the description is complete: it explains what is searched, what fields are returned, and how to use the results. No missing critical information.

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% because the only parameter 'query' has a description. The tool description adds minimal value beyond the schema, stating 'from search query' which is obvious. Baseline 3 is appropriate.

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 searches for articles written by the CODENIVERSE team, specifies the topics (AI agent, automation, etc.), and explains it returns title, description, and URL. It distinguishes from siblings like get_article (retrieves a single article) and search_faq (searches FAQ).

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 implies usage for searching team articles but does not explicitly state when to use this tool versus alternatives (e.g., when to use get_article instead). No exclusions or prerequisites are mentioned.

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?

No annotations are provided, so the description carries full burden. It reveals that answers include citations ('ตอบโดยอ้างลิงก์หน้าต้นทางด้วย'), but does not disclose whether results are exact matches or fuzzy, or whether pagination exists. Mentions '58 ข้อ' implying a fixed set, but not explicit.

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 a single sentence covering purpose, usage guideline, and citation behavior. It is efficient but could be slightly more structured (e.g., separate sentences for purpose and guidelines).

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 output schema and no annotations, the description should explain what the tool returns beyond citations. It mentions citation links but not the result format (e.g., list of Q&A pairs). Adequate for a simple search tool but could be more comprehensive.

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% for the single query parameter. The description provides a usage tip: use single words or short phrases for better results ('คำสั้นเจอมากกว่าประโยคยาว'), which adds value beyond schema constraints.

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 searches official CODENIVERSE Q&A covering specific topics (service conditions, duration, price, hiring, after-delivery care). It differentiates from siblings by emphasizing it's for official company Q&A and should be used before answering conditional questions.

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 to use this tool before answering company conditional questions ('ใช้ก่อนตอบคำถามเชิงเงื่อนไขของบริษัทเสมอ'). This provides clear when-to-use guidance and implies alternatives like search_articles are for other contexts.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It discloses the key side effect—sending the information to the CODENIVERSE team—and clarifies that this is not a CRM write. It also describes the expected follow-up (email reply within the same business day) and imposes user-confirmation and data-integrity requirements, which is strong transparency for this kind of action tool.

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 a single dense paragraph, but every sentence contributes: purpose, non-purpose, usage triggers, data-integrity rules, confirmation requirement, and expected team response time. It is slightly long, but the length is justified for a mutation tool with consent and data-handling concerns.

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 5-parameter mutation tool with no annotations and no output schema, the description covers the necessary context: when to use it, what prerequisite data is needed, what safeguards to follow, and what happens after submission. Nothing essential for an agent to call this tool 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?

Schema description coverage is 100%, so the schema already documents each parameter clearly. The tool description reinforces the rule not to fabricate names or emails and says to ask the user if information is missing, but it does not add much parameter-specific meaning beyond what the input schema provides. Baseline 3 is appropriate.

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 this tool submits a request to the CODENIVERSE team so they can contact the user back, and explicitly distinguishes it from saving a lead into the user's CRM. It also names concrete trigger cases: discussing a project, requesting a quote, or asking to be contacted. This makes it easy to differentiate from the sibling read/search 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?

The description gives explicit when-to-use conditions and provides important preconditions: use only real user-provided data, ask for missing name/email, and confirm with the user before invoking. The 'not CRM' clarification further prevents misuse. While it does not mention sibling tools by name, all siblings are content-retrieval tools with no overlap.

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