Request quotes for video, shooting, social media, ad media, design, web and events in Japan.
Scored across 7 tools
Tools target distinct areas (awards, subsidies, media, services, quotes, creator registration), but two overlaps exist: list_ad_media can also return TVer rates, and submit_quote_request with kind CREATOR returns creator registration info, duplicating get_creator_registration_info. Descriptions largely clarify which to use, so confusion is limited.
All tool names use snake_case with a consistent verb_noun pattern (find_*, get_*, list_*, submit_*). No mixed conventions or vague verbs.
Seven tools is well-scoped for an information and quote-request assistant, covering discovery, rate lookup, and submission without excessive surface. Each tool appears to earn its place.
Core discovery and submission workflows are covered, but after submitting a quote request there is no tool to check status, update, or cancel it. Pricing is only available for TVer, leaving a gap for other media or production cost inquiries.
Use this when the user asks which advertising awards they can enter, or when entries open. Returns advertising awards and their next entry period (open now / expected next), with the organizer, categories, entry fee and eligibility where known. Regional awards are returned only when a matching prefecture is given, and are listed first. International awards are returned only when includeInternational is true. category is one of: TVCM / WEB動画 / ラジオCM / 新聞 / 雑誌 / OOH交通 / デジタルWeb / PR / BtoB / キャンペーン総合 / デザイン / パッケージ / 学生 / その他. Dates are for reference only.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. | |
| limit | No | Maximum number of results. Default 15, maximum 30. | |
| category | No | Award category to filter by. | |
| openOnly | No | Set true to return only awards accepting entries now. | |
| prefecture | No | Japanese prefecture, in Japanese (e.g. 香川県). Adds the regional awards for that prefecture. | |
| includeInternational | No | Set true to include international awards. Default false. |
| Name | Required | Description |
|---|---|---|
| note | No | Notes that apply to the result, in Japanese. |
| error | No | Reason the request could not be answered, in Japanese. |
| awards | No | Matching awards. Can be empty. |
| message | No | Message for the user, in Japanese. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| notAvailable | No | true when the tool is not available for the given role. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is already known. The description adds meaningful ordering semantics ('regional awards are listed first'), scoping behaviour for regional and international results, and a caveat that dates are for reference only. It does not describe pagination or the exact shape of the returned entry-period object, but with an output schema and annotations covering the rest, this is strong.
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?
Front-loaded with the triggering question, then capabilities, then conditional rules and category enumeration. No redundant sentences; every clause carries useful 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?
With an output schema present, the description focuses on what the schema cannot convey: when to call it, conditional inclusion of regional/international awards, result ordering, and the category vocabulary. Nothing needed for correct invocation 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 already 100%, so parameter descriptions carry most of the load. The description still adds value by spelling out the allowed `category` list, clarifying the conditional effect of `prefecture` and `includeInternational`, and implying `openOnly` through the open-now concept. It does not cover `role` or `limit`, hence not a 5.
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 ('Returns advertising awards and their next entry period') and explicitly ties it to a user intent ('Use this when the user asks which advertising awards they can enter, or when entries open'). This distinguishes it from siblings like find_subsidies and list_ad_media without 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?
It names the triggering user questions and gives explicit conditional rules: regional awards appear only with a matching prefecture and are listed first; international awards appear only when includeInternational is true. This is a rare case of when-to-use and behavioural conditions being spelled out completely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about public subsidies or grants in Japan that may cover advertising or video production costs. Returns currently open national and local programs listed on jGrants (the Japanese government's subsidy portal) whose eligible costs include, or may include, advertising or video production. Programs confirmed to cover advertising costs come first, then by nearest deadline. Can be filtered by prefecture (nationwide programs are always included) and industry. Results are for reference only; eligibility and award are not guaranteed.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. | |
| limit | No | Maximum number of results. Default 10, maximum 20. | |
| industry | No | Industry keyword in Japanese (e.g. 製造業 / 宿泊業 / 小売業). | |
| prefecture | No | Japanese prefecture, in Japanese (e.g. 香川県). Nationwide programs are always included. |
| Name | Required | Description |
|---|---|---|
| asOf | No | |
| note | No | Notes that apply to the result, in Japanese. |
| error | No | Reason the request could not be answered, in Japanese. |
| message | No | Message for the user, in Japanese. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| subsidies | No | Matching programs. Can be empty. |
| notAvailable | No | true when the tool is not available for the given role. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive, closed-world profile, so the description adds the behavioral layer that matters: ordering rules (confirmed advertising coverage first, then nearest deadline), prefecture filtering behavior (nationwide programs always included), and an explicit no-guarantee disclaimer. It doesn't discuss rate limits, data freshness, or pagination.
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?
Front-loaded with the trigger condition, then scope, source, ranking rules, filters, and disclaimer in four dense sentences with no filler. Every sentence carries information an agent needs to decide whether and how to call it.
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?
An output schema exists and annotations cover the safety profile, so the description need not explain return values. It nonetheless supplies the source (jGrants), ranking logic, filter semantics, and a confidence caveat, leaving no practical gap for correct invocation.
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 all four parameters, including the nationwide-always-included note. The description reinforces the prefecture/industry filtering and adds ordering semantics, but says nothing about the `role` parameter or the `limit` default, so it stays at the baseline.
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 (find) and resource (public subsidies/grants in Japan), with a narrow scope qualifier: programs whose eligible costs include advertising or video production. It is clearly distinguishable from siblings like find_ad_awards or list_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?
Opens with an explicit trigger condition ("Use this when the user asks about public subsidies or grants in Japan that may cover advertising or video production costs"), which is strong, actionable context. It does not name a when-not case or an alternative tool, but no sibling overlaps this niche enough to require that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user is a videographer, editor or production company asking how to register as a creator with Ad Arch. Returns the registration page URL and the fixed facts about registration (free of charge, who can register, the steps, confidentiality). Does not register anyone. Does not return information about workload or income.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. |
| Name | Required | Description |
|---|---|---|
| note | No | Notes that apply to the result, in Japanese. |
| error | No | Reason the request could not be answered, in Japanese. |
| facts | No | Fixed facts about registration. |
| message | No | Message for the user, in Japanese. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| registerUrl | No | Creator registration page. |
| notAvailable | No | true when the tool is not available for the given role. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral boundaries beyond that: it performs no registration action and deliberately withholds workload/income data, which prevents an agent from over-trusting the 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?
Four short sentences, front-loaded with the trigger condition and followed by return contents then exclusions. Every sentence carries information, though the closing exclusions could be folded more tightly.
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 low-complexity, zero-required-parameter lookup with annotations and an output schema present, the definition covers trigger, scope, return contents and boundaries. An agent has everything it needs to call this 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?
There is a single optional 'role' parameter with a fully documented enum (schema coverage 100%), so the schema carries the semantic burden. The description gestures at user types but never names the role parameter or explains how the enum value shapes the response; 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 names a specific resource (creator registration info for Ad Arch) and the exact audience that triggers it, plus explicitly states what it returns. It is trivially distinguishable from the unrelated siblings (find_ad_awards, get_tver_ad_monthly_rate, submit_quote_request).
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 gives a clear when-to-use condition tied to user type (videographer, editor, production company) and adds explicit when-not-to-use negatives ('Does not register anyone', no workload/income info). It does not name a sibling alternative, but no sibling is a plausible substitute, so this is close to complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how much a TVer ad costs in a specific Japanese prefecture or city. TVer is a Japanese ad-supported TV streaming service. Given a prefecture and city, returns the lowest monthly rate for that area (JPY, excluding tax, guide only), the minimum campaign length and the area's population. For areas where the rate is quoted individually, no figure is returned. allCities: true returns only the names and populations of the municipalities in the prefecture, ordered by population, without rates. Does not return per-plan rates or audience estimates. Video production costs are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, ward, town or village, in Japanese (e.g. 高松市). If omitted, the most populous city in the prefecture is used. | |
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. | |
| allCities | No | Set true to list the municipalities in the prefecture (names and populations only, no rates). | |
| prefecture | Yes | Japanese prefecture, in Japanese including the suffix (e.g. 香川県). |
| Name | Required | Description |
|---|---|---|
| area | No | |
| note | No | Notes that apply to the result, in Japanese. |
| areas | No | With allCities: the municipalities in the prefecture, ordered by population. No rates. |
| error | No | Reason the request could not be answered, in Japanese. |
| rules | No | |
| message | No | Message for the user, in Japanese. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| minMonths | No | Minimum campaign length in months. |
| planTypes | No | |
| howToOrder | No | |
| population | No | |
| prefecture | No | |
| monthlyFrom | No | |
| notAvailable | No | true when the tool is not available for the given role. |
| monthlyFromYen | No | Lowest monthly rate in JPY, excluding tax. null when the rate is quoted individually. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, non-destructive, non-open-world operation, and the description adds substantial behavioral context: rates are JPY excluding tax and guide-only, no figure is returned where pricing is quoted individually, allCities returns only names/populations ordered by population, and production costs are excluded.
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?
Five tight sentences, front-loaded with the trigger and core return contract, with exclusions trailing. No filler or repetition of the title.
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 an output schema present, the description need not detail return shape, yet it still communicates the return contract, edge case (no figure for individually quoted areas), and limits. Nothing an agent needs to select or invoke 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?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by stating that allCities results are ordered by population and that omitting city defaults to the most populous municipality. It adds real meaning, though role semantics are left entirely to 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, resource, and scope: returns the lowest monthly ad rate for a TVer ad in a given prefecture/city, plus minimum campaign length and population. The TVer definition and the not-returned exclusions make it clearly distinguishable from siblings like list_ad_media or find_ad_awards.
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?
Opens with an explicit trigger ('Use this when the user asks how much a TVer ad costs in a specific Japanese prefecture or city') and clarifies the allCities variant's purpose. It lists exclusions (per-plan rates, audience estimates, production costs) but does not name alternative sibling tools for those adjacent questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which advertising media Ad Arch can arrange, or wants the facts about one medium. Returns the media and, for each, what Ad Arch handles, the lead time to start (where it is fixed), the buying unit, the video format, and how to request a quote. If a prefecture is given (city optional; defaults to the most populous city), also returns the lowest monthly rate for TVer ads in that area (JPY, excluding tax, guide only). media narrows the list to media whose name contains that text; if nothing matches, the full list is returned. purpose is required. Returns no Ad Arch prices other than TVer.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, ward, town or village, in Japanese (e.g. 高松市). | |
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. | |
| media | No | Part of a medium's name, to narrow the list (e.g. シネアド / サイネージ / 折込). | |
| target | No | Intended audience (e.g. 20代の求職者 / 近所の家族連れ). | |
| purpose | Yes | What the advertising is for (e.g. 採用 / 見学会の集客 / 新商品の告知). Required. | |
| industry | No | The user's industry (e.g. 工務店). | |
| prefecture | No | Japanese prefecture of the target area, in Japanese (e.g. 香川県). |
| Name | Required | Description |
|---|---|---|
| note | No | Notes that apply to the result, in Japanese. |
| about | No | |
| error | No | Reason the request could not be answered, in Japanese. |
| message | No | Message for the user, in Japanese. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| available | No | Advertising media Ad Arch can arrange. |
| notListed | No | |
| quoteNote | No | |
| notAvailable | No | true when the tool is not available for the given role. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/destructive annotations, the description discloses non-obvious behavior: the `media` filter silently falls back to the full list on no match, the TVer figure is guide-only and tax-excluded, and no other Ad Arch prices are returned. It does not discuss pagination or result sizing, so it stops short of fully covering 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?
Front-loaded with the usage trigger, followed by return contents and conditional rate logic. Dense but every sentence carries information; the only mild redundancy is restating the quote-request information already implied by the mandate list.
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 7-parameter tool with an output schema, the description covers the trigger, the returned fields, the filter/fallback semantics, the geographic condition, and the price-scope caveat. Given the output schema carries the return shape, nothing an agent needs to invoke 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?
Schema coverage is 100%, so the baseline is 3, and the description adds meaning on top: `media` is a substring match on the medium name (not an exact key), and `city` is optional and defaults to the most populous city. `purpose` is confirmed as required. It says nothing about role/target/industry beyond what the schema already documents.
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 (list advertising media) and enumerates the per-medium facts returned (handled services, lead time, buying unit, video format, quote method). It clearly separates itself from siblings like get_tver_ad_monthly_rate by framing the TVer rate as a conditional add-on rather than the tool's core job.
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 this when the user asks which advertising media Ad Arch can arrange, or wants the facts about one medium" gives an explicit trigger condition, and it notes the prefecture/city condition for TVer rates. It does not, however, name an alternative tool to use when the user wants only the TVer rate, so an agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what services Ad Arch offers, or what information is needed before requesting a quote. Returns the request types Ad Arch accepts (filming, video production, YouTube, social media, TVer ads, other ad media, design, websites, events, other creative work, other) with the items to confirm before a quote for each type, and the service packages Ad Arch has published, with the deliverables and typical lead time of each (this list can be empty). Optional category filters the service packages only (e.g. 制作 / TVer / SNS / 採用). Does not return prices.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. | |
| category | No | Text to filter the service packages by category (e.g. 制作 / TVer / SNS / 採用). |
| Name | Required | Description |
|---|---|---|
| note | No | Notes that apply to the result, in Japanese. |
| error | No | Reason the request could not be answered, in Japanese. |
| message | No | Message for the user, in Japanese. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| services | No | Published service packages. Can be empty. |
| howToSend | No | |
| howWeWork | No | |
| hearingRule | No | |
| notAvailable | No | true when the tool is not available for the given role. |
| requestKinds | No | Request types accepted, with the items to confirm before a quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile (readOnlyHint, non-destructive, closed-world), and the description adds real behavioral detail beyond them: the package list may be empty, the category parameter narrows packages only, and prices are deliberately excluded. These are useful expectations an agent could not infer from the schema.
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 usage trigger is front-loaded and the long middle sentence is dense with genuinely useful return-content detail rather than filler. The enumeration of request types is somewhat verbose but earns its place by telling the agent what to expect.
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 two-parameter read tool with an output schema and safety annotations, the description is nearly complete: it covers when to call it, what returns, and the key exclusion (no prices). The only gap is silence on the role parameter's effect, which the schema does document.
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 both role and category are already documented, and the description's note that category filters service packages only largely restates the schema wording. The role parameter is not mentioned at all in the description, so no meaning is added beyond the schema baseline.
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 names a specific verb and resource (list services Ad Arch offers) and enumerates exactly what comes back: accepted request types with pre-quote confirmation items, plus published service packages with deliverables and lead times. It is far more precise than the title alone, though it never explicitly contrasts itself with siblings like list_ad_media or get_tver_ad_monthly_rate.
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 states a clear trigger: use when the user asks what services are offered or what information is needed before requesting a quote, which implicitly routes the quote flow to submit_quote_request. No explicit when-not-to-use or named alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this only when the user has explicitly asked to request a quote or an arrangement from Ad Arch and has confirmed the details to send. Submits one request (quote only is accepted) and returns a reference number and the expected response time. Side effect: stores the request, including the company name, contact name and email, and shares it with Ad Arch staff and the Ad Arch group office in charge; a confirmation email may be sent to that email address. Each kind has required items; if hearing does not cover them, nothing is stored and the missing items are returned. Nothing is stored unless agreeToTerms is true. An identical request from the same email within 24 hours returns the existing reference number. A submitted request is not a contract; a contract is formed only after the user accepts a written quote and Ad Arch confirms. Staff reply within about 2 business hours (weekdays 9:00–18:00 JST). kind: SHOOTING = filming (location and preferredDates required) / VIDEO = video production / YOUTUBE = YouTube channel management or videos / SNS = social media filming or management / TVER = TVer ads / MEDIA = other advertising media (medium name in mediaName) / DESIGN = design / WEB = website / EVENT = event / CREATIVE = other creative work / OTHER = other, or quote only / CREATOR = registering as a creator or production company (returns the registration page; nothing is stored).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Type of request. See the list in the tool description. | |
| role | No | The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company. | |
| Yes | Contact email address. | ||
| phone | No | Phone number (optional). | |
| detail | Yes | The request in the user's own words or as confirmed by the user, in any language. Up to 2000 characters. | |
| hearing | No | Items required for the quote and the user's answers (not needed for OTHER). If any required item is missing, the request is not stored and the missing items are returned. | |
| location | No | Filming or event location (e.g. 香川県高松市). | |
| mediaName | No | Name of the advertising medium, for kind MEDIA (e.g. 地元ラジオ / 駅のサイネージ). | |
| prefecture | No | Prefecture where the company is located, in Japanese (e.g. 香川県). Leave empty for companies outside Japan and write the country in detail. | |
| budgetRange | No | Approximate budget (optional). | |
| companyName | Yes | Company name (trade name for sole proprietors). | |
| contactName | Yes | Name of the contact person. | |
| agreeToTerms | Yes | Whether the user has agreed to the terms of use, which include sharing the request with the office in charge and being recorded as a prospect. The request is not stored unless true. | |
| preferredDates | No | Preferred dates or period; a range is fine. |
| Name | Required | Description |
|---|---|---|
| note | No | Notes that apply to the result, in Japanese. |
| error | No | Reason the request could not be answered, in Japanese. |
| notice | No | |
| message | No | Message for the user, in Japanese. |
| missing | No | The missing items. |
| accepted | No | true when the request was stored. |
| needRole | No | true when the call was made without `role`; nothing else is returned. |
| termsUrl | No | |
| needHearing | No | true when required items are missing; nothing was stored. |
| receiptNote | No | |
| registerUrl | No | For kind CREATOR: the creator registration page. |
| notAvailable | No | true when the tool is not available for the given role. |
| receiptNumber | No | Reference number of the stored request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that data is stored and shared with Ad Arch staff and the group office, that a confirmation email may be sent, that nothing is stored unless agreeToTerms is true or when hearing items are missing, and that a duplicate request within 24 hours returns the existing reference number. The 24-hour dedup window is a nuance against idempotentHint=false, but since calls beyond that window or with different payloads do create new records, it is not a true contradiction.
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?
Front-loads the critical usage precondition and keeps every sentence informative, but the long inline enumeration of kind values makes it a dense wall of text. The content earns its place, though the kind list could be structured more readably.
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 complex 14-parameter mutation tool with an output schema present, the description covers side effects, consent gating, validation failure behavior, dedup behavior, SLA, and the legal disclaimer (not a contract until a written quote is accepted). Nothing an agent needs to invoke 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: it explains each kind value (SHOOTING = filming with location and preferredDates required, MEDIA needs mediaName, CREATOR returns the registration page), and the hearing/required-items failure mode. It does not enumerate the required items for every kind, so it falls short of a 5.
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 ('Submits one request... returns a reference number and the expected response time') and immediately scopes it ('quote only is accepted'). An agent can distinguish it from the read-only sibling tools without opening 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?
Gives a strong precondition: 'Use this only when the user has explicitly asked to request a quote or an arrangement from Ad Arch and has confirmed the details to send.' It also clarifies the CREATOR path (returns the registration page, nothing stored). It does not, however, differentiate itself from the sibling get_creator_registration_info, which appears to overlap with the CREATOR kind.
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.
creator_registerfind_ad_awards7 fields changedInput schema / properties / category / descriptionAdded value: +"Award category to filter by."Input schema / properties / includeInternational / descriptionAdded value: +"Set true to include international awards. Default false."Input schema / properties / limit / descriptionPrevious value: -"既定15・最大30"New value: +"Maximum number of results. Default 15, maximum 30."Input schema / properties / openOnly / descriptionPrevious value: -"今受付中のものだけ"New value: +"Set true to return only awards accepting entries now."Input schema / properties / prefecture / descriptionAdded value: +"Japanese prefecture, in Japanese (e.g. 香川県). Adds the regional awards for that prefecture."Input schema / properties / role / descriptionPrevious value: -"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"New value: +"The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "awards": {
+ "description": "Matching awards. Can be empty.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "eligibility": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "entryWindow": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "fee": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "organizer": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "region": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scope": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Reason the request could not be answered, in Japanese."
+ },
+ "message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Message for the user, in Japanese."
+ },
+ "needRole": {
+ "description": "true when the call was made without `role`; nothing else is returned.",
+ "type": "boolean"
+ },
+ "notAvailable": {
+ "description": "true when the tool is not available for the given role.",
+ "type": "boolean"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Notes that apply to the result, in Japanese."
+ }
+ },
+ "type": "object"
+}find_subsidies5 fields changedInput schema / properties / industry / descriptionPrevious value: -"業種の言葉（例: 製造業／宿泊業／小売業）"New value: +"Industry keyword in Japanese (e.g. 製造業 / 宿泊業 / 小売業)."Input schema / properties / limit / descriptionPrevious value: -"既定10・最大20"New value: +"Maximum number of results. Default 10, maximum 20."Input schema / properties / prefecture / descriptionPrevious value: -"例: 香川県（全国の制度は常に含む）"New value: +"Japanese prefecture, in Japanese (e.g. 香川県). Nationwide programs are always included."Input schema / properties / role / descriptionPrevious value: -"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"New value: +"The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "asOf": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Reason the request could not be answered, in Japanese."
+ },
+ "message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Message for the user, in Japanese."
+ },
+ "needRole": {
+ "description": "true when the call was made without `role`; nothing else is returned.",
+ "type": "boolean"
+ },
+ "notAvailable": {
+ "description": "true when the tool is not available for the given role.",
+ "type": "boolean"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Notes that apply to the result, in Japanese."
+ },
+ "subsidies": {
+ "description": "Matching programs. Can be empty.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "adCost": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "areas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "deadline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "institution": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "maxLimitYen": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "subsidyRate": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_creator_registration_infoget_tver_ad_monthly_ratelist_ad_medialist_services3 fields changedInput schema / properties / category / descriptionAdded value: +"Text to filter the service packages by category (e.g. 制作 / TVer / SNS / 採用)."Input schema / properties / role / descriptionPrevious value: -"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"New value: +"The user's position: company = a business commissioning production or advertising / creator = a videographer, editor or other creator / agency = an advertising agency or production company."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Reason the request could not be answered, in Japanese."
+ },
+ "hearingRule": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "howToSend": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "howWeWork": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Message for the user, in Japanese."
+ },
+ "needRole": {
+ "description": "true when the call was made without `role`; nothing else is returned.",
+ "type": "boolean"
+ },
+ "notAvailable": {
+ "description": "true when the tool is not available for the given role.",
+ "type": "boolean"
+ },
+ "note": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Notes that apply to the result, in Japanese."
+ },
+ "requestKinds": {
+ "description": "Request types accepted, with the items to confirm before a quote.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "askFor": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "name",
+ "askFor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "services": {
+ "description": "Published service packages. Can be empty.",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "category": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "deliverables": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "qty": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "spec": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unit": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "leadTime": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tagline": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tip": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "whatWeDo": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}request_ordersubmit_quote_requestsuggest_mediatver_area_plancreator_register1 field changedInput schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"find_ad_awards1 field changedInput schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"find_subsidies1 field changedInput schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"list_services1 field changedInput schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"request_order4 fields changedInput schema / properties / agreeToTerms / descriptionPrevious value: -"ご利用条件（担当する拠点への共有・見込み先としての記録を含む）に本人が同意したら true。同意が無ければ送らない"New value: +"ご本人がご利用条件（担当する拠点への共有・見込み先としての記録を含む）に同意したかどうか。true でない場合は受け付けない"Input schema / properties / hearing / descriptionPrevious value: -"聞き取りの答え。その種類の askFor を全部入れる（OTHER は不要）。埋まっていない項目があると受け付けず、足りない項目が返る"New value: +"見積に必要な項目とご本人の答え（OTHER は不要）。揃っていない項目があると受け付けられず、足りない項目が返る"Input schema / properties / hearing / items / properties / item / descriptionPrevious value: -"項目（list_services の askFor、または窓口が missing で返した項目名）"New value: +"見積に必要な項目の名前"Input schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"suggest_media1 field changedInput schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"tver_area_plan1 field changedInput schema / properties / role / descriptionPrevious value: -"相手の立場（最初に1問だけ選択肢で聞いた答え）：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。必ず付ける"New value: +"相手の立場：company＝制作・広告を頼む側の企業／creator＝制作者・クリエイター／agency＝広告代理店・制作会社（同業）。立場によって使えるツールが違う"creator_registerfind_ad_awardsfind_subsidieslist_servicesrequest_ordersuggest_mediatver_area_planSchedule and publish to YouTube, TikTok, Instagram, X, Threads & Facebook. Japanese-language SaaS.
Find Moovtips services (3D websites, SEO, AI voice agent, ads, UGC) and send a quote request.
Videos that make your business go viral, made for you.
Find, vet and budget bookable influencers, photographers and videographers for brand campaigns.
Add one secure layer between your agents and this server.
