株式会社一創 コーポレートサイト

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

Discloses that HTML is stripped and output is truncated at 15000 characters. Lacks mention of potential network latency or error behavior, but since no annotations exist, these details are adequately covered.

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 concise sentences with no redundancy. Purpose and key constraints are front-loaded, making it easy to scan.

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 simplicity of the tool, description covers how to call it, what it returns, and output formatting. Missing details like error handling are not critical for this read-only operation, and no output schema is provided, so the described behavior is sufficient.

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 descriptions are in Japanese; the tool description provides English equivalents and clarifies usage with examples (URLs and IDs). Adds value beyond the schema by making parameters more accessible and confirming mutual exclusivity implicitly.

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 the tool fetches full text of a single article from issoh.co.jp, distinguishing it from search tools by specifying 'full text' and 'one article'.

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 mentions acceptance by URL or ID, and provides URL examples. However, it does not explicitly contrast with sibling search tools, though the naming implies the difference.

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 responsibility. It indicates a read-only retrieval ('Return...') but doesn't disclose potential caveats like rate limits, failure modes, or whether the URLs are consistently canonical across scenarios. The absence of annotations lowers the score, though the action is simple and likely side-effect-free.

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 concise sentences: the first states what it does, the second states when to use it. No filler or redundant information. Effectively front-loaded 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 simplicity (0 params, no output schema, no annotations), the description adequately covers the tool's purpose and usage. It doesn't describe the exact return format, but for a simple company info tool, that may be unnecessary. Could benefit from mentioning the structure of the returned data, but overall sufficient.

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?

Tool has 0 parameters, which meets the baseline of 4. The description correctly implies no input is needed, and there is nothing to explain about parameters. The schema coverage is 100% trivially since no properties exist.

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 company profile of 株式会社一創 and canonical URLs for services, portfolio, and contact form. It distinguishes from sibling tools like get_article and search_services by focusing on company info and contact URLs rather than content 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?

Explicitly states when to use: 'Use this when the user asks who they are or how to contact / request a quote.' This provides clear triggers and implies alternatives (search tools for content) without listing them.

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?

The description discloses the output format ('Returns titles, URLs and excerpts') and indicates it does not return full content by directing to get_article. However, it does not explicitly state that the operation is read-only or has no side effects, though this is implied by its nature.

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 succinct and well-structured: it states the purpose, lists topics, clarifies terminology, mentions return fields, and gives a follow-up instruction. Every sentence adds value without 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 search tool, the description provides sufficient context: source domain, topic categories, term definitions, return format, and next step. It could mention pagination or sorting, but these are not critical for the tool's primary purpose.

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 description adds semantic meaning beyond the schema, particularly for the post_type parameter (defining 'column' and 'tech' orientations) and clarifies the scope of the query. This complements the schema descriptions, which are clear but laconic.

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 function: 'Search Japanese articles published on issoh.co.jp' with explicit topic coverage and clarification of the 'column' vs 'tech' distinction. This is a specific verb+resource+scope that effectively distinguishes it from other 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 provides a workflow hint ('Call get_article afterwards') but does not explicitly state when to use this tool over sibling search tools (search_case_studies, search_services). It implies usage based on the content type, but lacks direct comparative 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?

No annotations are provided, so the description carries the behavioral transparency burden. It communicates that the operation is a read-only search over published materials, which is useful. However, it does not mention ordering behavior, pagination, result format, permissions, or any constraints beyond the schema-provided limit semantics.

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 two concise sentences with no filler. The first sentence states exactly what is searched and by whom, and the second sentence gives a concrete usage example, making it easy to parse quickly.

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 read-only search tool with two fully documented parameters and no output schema, the description covers the essential context: content domain, entity, and typical user intent. It does not describe the shape of returned items, but that is a minor gap given the low complexity.

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%: both `query` and `limit` are already described in the input schema, including default and range for `limit`. The description adds no parameter-specific meaning, 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 uses a specific verb-resource pair: 'Search the published project portfolio (制作実績) and customer references (導入企業の声)' of the named company. It also clarifies the intended question type ('do they have experience with X?') and distinguishes the tool from siblings like search_services and search_articles by content domain.

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 when to use the tool: 'Use this to answer "do they have experience with X?" style questions.' It does not explicitly name alternatives or exclusions, but the use case is clear enough for an agent to make a reasonable selection among sibling search tools.

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, the description carries the burden of behavioral disclosure. It does mention query omission behavior, but it does not address pagination/limit interplay or return format. The phrase 'list every service' is potentially misleading given the limit default of 10, though the schema itself carries a similar inconsistency.

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 two sentences with no filler. It front-loads the core action and resource, then provides targeted usage guidance and a key query-omission behavior. 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?

This is a simple, low-parameter search tool with a fully documented schema, so the description is largely complete. It covers purpose, typical use cases, and query omission. Lack of output schema is acceptable for a list-returning search tool, though a brief mention of return type would strengthen it.

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 baseline is 3. The description adds use-case context but does not materially enrich the meaning of 'query' or 'limit' beyond what the schema already documents. The category list in the description helps with query formulation but is not parameter-specific.

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 uses a specific verb ('Search') and a clear resource ('services offered by 株式会社一創') with concrete categories. It also distinguishes itself from sibling tools like search_articles and search_case_studies by focusing on services.

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 context: 'Use this when the user is looking for a development vendor, a quote, or a partner for a specific technology.' It does not explicitly contrast with sibling search tools, but the service scope is clear enough for differentiation.

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