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

With no annotations, the description carries the full burden of behavioral disclosure. It states exactly what data is returned, explicitly declares what is not computed (on-time percentage, defaulter flag), and adds a QRMP interpretation caveat. It does not cover failure modes or data freshness, but for a read-only summary tool the key behavioral traits are disclosed.

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. The first sentence front-loads the specific output metrics; the second sentence adds essential interpretive caveats. Every clause earns its place and there is no unnecessary elaboration.

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 2-parameter read-only tool with no output schema, the description explains the output components and the key interpretation caveat. It is slightly terse about the exact return format or field names, but it is sufficient 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?

Schema description coverage is 100% — both gstin and financial_year have detailed descriptions with examples. The tool description does not add any parameter-level meaning beyond the schema, so the baseline score of 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 identifies the tool as returning a filing history summary per return type, listing the specific metrics: filed count, last period filed, months since, and average filing lag. The clause 'Facts only — no on-time percentage or defaulter flag is computed' implicitly distinguishes it from a compliance-judgment tool. It does not explicitly name a sibling tool, so it stops short of 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?

The description says no on-time percentage or defaulter flag is computed and instructs the agent to 'apply your own thresholds', which gives clear contextual guidance on when this tool is appropriate. The QRMP caveat also helps the agent interpret multi-month gaps correctly. However, it never explicitly mentions an alternative tool or a when-not-to-use condition.

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?

Since no annotations are provided, the description carries the full burden. It does disclose the key behavioral output: the filing preference is reported quarterly across the financial year. However, it doesn't mention possible response values, data freshness, authorization requirements, or edge cases such as invalid GSTINs or years with no filing data.

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 concise sentence with no wasted words. It communicates the core query and the quarterly granularity up front, making it easy for an agent to scan and understand.

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 two-parameter lookup with no output schema or nested objects, the description provides enough context: it identifies the entity, the year scope, and the quarterly output dimension. Minor gaps remain around exact returned values and error behavior, but these are not critical for an initial tool selection decision.

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 input schema already documents both parameters well, with format patterns and examples, so schema coverage is 100%. The description itself does not add parameter-level detail, but it does clarify that the response is organized by quarter, which relates to the financial_year parameter. This matches the baseline for fully documented schemas.

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 expresses the tool's purpose: reporting whether a taxpayer files Monthly or Quarterly (QRMP) for each quarter of a financial year. It names the resource (GSTIN filing preference) and the query scope, though it doesn't explicitly contrast with sibling tools like get_gstin_returns or get_gstin_compliance.

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 when to use the tool: when you need a taxpayer's filing frequency preference for a given GSTIN and financial year. It provides no explicit guidance about when not to use it or which sibling tool would be more appropriate for related needs such as returns or compliance.

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 transparency burden. It does disclose that the result includes return fields and spans 'every' return in a financial year, but it omits potential pagination, ordering, empty-result behavior, and any rate-limit or authorization context. No contradiction with annotations exists.

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 short and front-loads the return type, but the sentence is ungrammatical and slightly confusing: 'Every GSTR-1 / GSTR-3B (and other type) return a GSTIN...' This undermines clarity despite the brevity.

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, the description covers the core purpose and some output fields, but since there is no output schema and no annotations, it should also clarify result structure, pagination, and edge cases. The description is minimally adequate but leaves notable 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 description coverage is 100%, so the input schema already documents gstin and financial_year with formats and examples. The description adds only the contextual scope 'given financial year' but does not meaningfully extend the parameter semantics, matching the 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?

The description identifies the resource (GSTIN tax returns: GSTR-1/GSTR-3B and other types) and names the key output fields (period, filing date, status, ARN). However, it is grammatically awkward ('Every ... return a GSTIN filed...') and does not explicitly contrast with siblings like get_gstin_compliance, so it stops short of full sibling differentiation.

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?

No guidance is provided about when to choose this tool over alternatives such as verify_gstin, get_gstin_compliance, or get_gstin_filing_preference, nor any when-not-to-use guidance. The phrase 'filed in the given financial year' implies the query context, but the description does not state usage boundaries or exclusions.

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 must carry the behavioral disclosure burden. It does so by stating that the tool is free and does not consume a credit, which is a non-obvious behavioral trait. It also clearly implies a read-only operation. However, it does not mention potential nuances like reset timing or whether the count includes the current call, leaving minor gaps.

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 extremely concise, using two short sentences to convey the core function and the cost-related advantage. Every word earns its place, and the key information is front-loaded.

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 zero-parameter, read-only reporting tool with no output schema, the description is complete. It tells the agent exactly what question the tool answers (calls made today) and the important operational detail (free). Nothing critical is missing for an agent to invoke and interpret 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 schema description coverage is 100%, so there is nothing to add. The baseline for zero-parameter tools is 4, and the description appropriately focuses only on the tool's purpose and cost, not on parameters.

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 what the tool does: it reports the number of calls made by the API key today. This specific resource and function distinguishes it from the sibling tools, which are all GSTIN/HSN lookup or search operations.

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 clear context by explicitly noting that the tool is free and does not consume a credit. This implies it can be safely used for monitoring usage without cost, though it does not explicitly discuss when to use it over alternatives or state exclusions.

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 disclosure burden. It clearly states the output shape and proactively warns that the tool does not return a GST rate, explaining why. It doesn't cover invalid-code or not-found error behavior, but that is a minor gap for a simple lookup 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?

Two sentences with no filler. The first sentence states the core return value, and the second delivers the critical caveat about GST rates. Every phrase 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 lookup with no output schema, the description gives the essential information: input type, returned fields, and the prominent non-goal. An agent has enough context to invoke it correctly and avoid the most likely misuse.

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 input schema already documents code as a required 2-8 digit HSN/SAC string, so schema coverage is 100%. The description reinforces the same format but adds no substantial new parameter-level meaning beyond what the schema provides.

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 specifies what the tool returns: the official description for a 2-8 digit HSN/SAC code plus the chapter/heading/subheading it belongs to. It also distinguishes itself from a search tool by being code-based, though it never explicitly names the sibling alternative.

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 intended use is clear: given a 2-8 digit HSN/SAC code, retrieve the official description and taxonomy position. It also provides an explicit when-not by warning that no GST rate is returned, though it does not name alternatives like search_hsn_codes.

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 full burden of behavioral disclosure. It usefully discloses the data source (data.gov.in RoC-wise Company Master Data), refresh cadence (roughly quarterly), and field scope limitations. It does not describe behavior for missing/invalid CINs or the response shape, but these are minor gaps for a simple direct lookup.

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 tightly written sentences: the first front-loads the core lookup behavior and data scope, the second clarifies boundary conditions. No filler words or redundant restatements.

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 gives enough context: exact lookup by CIN, data scope, source, and refresh frequency. It lacks explicit return/error behavior, but this is a minor gap for such 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?

The input schema already documents the only parameter, cin, with a clear description and example (U72900MH2015PTC269555), so schema coverage is 100%. The description adds little beyond framing 'by CIN' and the data source; it does not provide additional format or validation semantics.

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 ('direct ... lookup') and resource ('company-master by CIN'), and explicitly scopes the data to company master fields only, excluding directors, charges, filings, and financial statements. This makes it easy to distinguish from search_mca_companies and other 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?

It clearly communicates that this tool is for exact CIN-based company-master lookups and that it will not return directors, charges, filings, or financial statements, so the agent knows when not to use it. It stops short of explicitly naming the alternative tool to use when a CIN is unavailable (search_mca_companies), but the intended use case is strongly implied.

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 clearly discloses that the match is probabilistic, scored, and returns a confidence band, and explicitly warns against presenting as fact. With no annotations, this is essential and fully covers the tool's behavioral characteristics.

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 well-structured: purpose first, then the caveat, then the instruction. Each sentence adds necessary context, though it is slightly wordy for a simple tool.

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 tool with no output schema, the description covers the essential aspects: purpose, probabilistic nature, confidence band, and required user-facing caveat. Nothing critical 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 gstin parameter is fully documented with type, length, and example. The description adds no further parameter meaning, meeting the baseline for high schema coverage.

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 (matches) and resource (GSTIN to probable company in MCA registry). It distinguishes from siblings like lookup_mca_company (by company name) and verify_gstin (verification) by focusing on the matching task.

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 provides clear context for when to use the tool (matching GSTIN to company) and instructs how to present results (as probable, point to mca.gov.in), but does not explicitly contrast with sibling tools or state when not to use it.

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 behavioral burden and meaningfully discloses the match-ranking behavior: exact matches first, then descriptions starting with the term, then containing it. This is valuable for interpreting results. It stops short of describing the return shape or limit behavior, but the disclosed ranking is a substantive behavioral trait.

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 with no filler. The core purpose is front-loaded, and the second sentence adds genuinely useful ranking behavior that justifies 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 simple search tool, the description covers the input and the ordering semantics well. However, with no output schema and no annotations, the return format and the meaning of limit are left implicit, which could require an agent to infer or test these details at call time.

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 no parameter-specific detail beyond the schema; it only reframes the query as a 'term'. The schema documents query and kind, but the limit parameter has no semantic description, and the tool description does nothing to compensate for that gap.

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 action ('Find') and resource ('HSN/SAC codes') with an explicit input condition ('free-text description'). The free-text qualifier implicitly distinguishes it from the sibling lookup_hsn_code, though it does not name that alternative explicitly.

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 establishes the primary usage context: use this when you have free text and need HSN/SAC codes. It does not list exclusions or explicitly name alternatives, but the intended use case is clear and not misleading.

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 full burden. It mentions fuzzy matching, optional filters, and pagination, which is useful, but it does not disclose rate limits, return format, result count limits, or whether the search is case-insensitive or how pagination behaves. For a read/search tool this is acceptable but far from transparent.

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?

One sentence with a clear subject and qualifiers. It front-loads the core behavior ('fuzzy company-name search') and packs in optional filters plus pagination. No wasted words, though it could have added a sentence on usage alternatives.

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 annotations and no output schema, the description is the only guidance. It explains the searching behavior, but lacks explicit guidance on when to use search vs lookup_mca_company, expected result shape, and any behavioral details like limit or ordering. Given the sibling set and the existence of a very similar 'lookup' tool, this is a notable gap.

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 only 50%: state and status have descriptions, but name and page do not. The description adds meaning by clarifying that the search is fuzzy and that state/status are optional filters, and pagination is paginated. It does not add detail on the page parameter's semantics beyond the schema, but the overall behavior is clarified enough for an agent to use the parameters correctly.

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') over a specific resource ('MCA registry') with fuzzy matching, optional state/status filters, and pagination. It does not explicitly differentiate from sibling lookup_mca_company, but the word 'search' vs 'lookup' and 'fuzzy' implies it. A clear purpose statement overall.

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?

No explicit guidance on when to use this tool vs alternatives. Siblings include lookup_mca_company (exact lookup) and other registry tools, but the description does not mention them or exclusion criteria. The context implies a fuzzy search use case, but nothing is stated.

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 meaningfully discloses that every call queries the GST network in real time and is not served from a cache, which is valuable behavioral context. But with no annotations and no mention of error behavior, rate limits, or response format, the burden is only partially met.

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 focused sentences front-load the core lookup purpose and returned data, then add the optional profile extension. There is no filler or repetition of schema details.

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 there is no output schema, the description enumerates the main output fields and the optional extended profile, which is sufficient for a simple lookup tool. Minor gaps remain around invalid GSTIN handling and operational constraints, but they are not critical for 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?

The schema already documents gstin with a concrete example, and the description compensates for the undocumented include_profile boolean by explaining exactly which additional fields it returns. This adds real semantic value beyond the bare 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?

The description states a specific verb and resource: 'Look up the live GST registration for a GSTIN' and enumerates the returned fields. This distinguishes it from sibling tools like get_gstin_returns or resolve_gstin_to_company, which differ in action and data scope.

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 provides clear context on what data is returned and how to opt into the extended profile with include_profile. However, it does not explicitly say when to prefer this tool over its GSTIN-related siblings or state exclusions.

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