MSG91 is a cloud communication platform that helps businesses improve customer engagement, streamline communication workflows, and increase operational efficiency through reliable, multi-channel communication solutions.
Scored across 3 tools
The three tools have mostly distinct roles: get_msg91_api_docs browses the hierarchy level-by-level, search_msg91_docs answers natural-language questions, and quickstart-msg91 loads skill instructions. Browse vs. search could occasionally be confused for the same lookup, but the descriptions make the intended use of each clear.
Two tools follow a verb_noun snake_case pattern (get_msg91_api_docs, search_msg91_docs), but quickstart-msg91 uses a hyphenated noun-only form that breaks the pattern. The mixed convention is still readable but not fully predictable from name alone.
Three tools is on the lean side but appropriate for a documentation-access server, with each tool covering a genuinely different access mode (browse, search, quickstart). Nothing extraneous and nothing obviously missing at this scale.
The surface covers the full docs workflow: orientation via quickstart, discovery via hierarchical browsing, and targeted lookup via search, including OpenAPI endpoint retrieval. Minor gap is that there is no direct 'fetch page by URL' shortcut outside the browse path, but agents can work around it.
Browse the MSG91 API docs, one level at a time. Call it without arguments to get the top level: the modules and pages with a short description and the endpoints they hold. Call it with path set to a module's or page's link (or path) to get what is inside it; each listing links the next level. Call it with path set to an endpoint's link ending in ".openapi.yml" to get that endpoint as an OpenAPI file: method, url, headers, query params, path variables, a request body example and sample responses. Fetch only the level you need.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | A link from a listing, exactly as given (e.g. "https://docs.example.com/sms/llms.txt" or ".../sms/send-sms.openapi.yml"), or just the path ("sms", "sms/send-sms.openapi.yml"). Leave it out for the top level. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral value beyond that: what each level returns (modules/pages with short descriptions and endpoints; OpenAPI file with method, url, headers, params, body example, sample responses) and the progressive-disclosure pattern. Missing only pagination/size or failure-mode context.
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 sentences, each doing distinct work: entry point, mid-level navigation, endpoint detail retrieval, and a usage constraint. The no-argument case is front-loaded so the agent sees the default behavior first. No redundancy with the schema text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it describes what a top-level listing contains, what nested listings link to, and the exact fields in the OpenAPI endpoint response. For a single-optional-param read-only tool this is complete enough to invoke correctly without experimentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter's own description already covers accepting a full link from a listing or a bare path, and omitting it for top level. The description reinforces this but adds no syntax or format detail the schema lacks. Baseline 3 applies since the schema does the heavy lifting for a single optional parameter.
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 (Browse) and resource (MSG91 API docs) plus the distinguishing mechanic: one level at a time, progressive disclosure. An agent immediately knows it's a navigational fetch tool. It doesn't explicitly name search_msg91_docs or quickstart-msg91 as the alternatives, so the differentiation from siblings is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use rules per argument shape: omit `path` for the top level, pass a module/page link for its contents, pass a `.openapi.yml` link for endpoint detail. The closing 'Fetch only the level you need' is an explicit usage constraint. It stops short of saying when to prefer search_msg91_docs instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quickstart for the MSG91 API Call this to load the full instructions for this skill before doing the task.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds the sequencing behavior (load instructions before acting), but says nothing about what the instructions contain, how large they are, or whether re-calling is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the action is front-loaded. It is slightly garbled ("MSG91 API Call this to load..." reads as two clauses fused without punctuation), but size is appropriate for a no-arg 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?
With zero params, no output schema and adequate annotations, the definition is close to sufficient. It still leaves the agent unsure what the call returns and how it overlaps with the two sibling documentation tools, which is the main open question for a primer 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level guidance is needed or missing.
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 action (load the full instructions for the MSG91 skill), which is more than a restatement of the name. It doesn't, however, differentiate itself from sibling get_msg91_api_docs, which a reader would reasonably assume also returns MSG91 documentation.
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?
"Call this ... before doing the task" gives one clear usage trigger, which is genuinely useful sequencing guidance. There is no statement of when NOT to use it or how it relates to get_msg91_api_docs and search_msg91_docs, so the agent must guess between three apparently overlapping documentation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the MSG91 documentation with a natural-language question. Returns the most relevant passages with their page URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, e.g. "how do I send a WhatsApp template message" | |
| collectionIds | Yes | Always send exactly these collection ids, unchanged: they are the documentation sites searched. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds value by disclosing the return shape (relevant passages plus page URLs), but says nothing about result count, ranking, or what happens with a vague query.
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, both load-bearing: the first states what it does and how, the second states what comes back. Nothing is padded or buried.
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 semantic search with fully documented schema and no output schema, the description covers purpose and return shape adequately. The one real gap is disambiguation from the two sibling docs tools, which an agent would still have to guess at.
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%, including a worked example for "query" and an explicit instruction for "collectionIds," so the baseline is 3. The description adds no parameter detail beyond restating that the query is natural language.
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 ("Search") and resource ("MSG91 documentation") plus the input style (natural-language question), so the purpose is unambiguous. It does not distinguish itself from the siblings get_msg91_api_docs or quickstart-msg91, leaving the agent to infer whether those overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by "with a natural-language question," which tells the agent the input shape but not the conditions under which this tool beats get_msg91_api_docs or quickstart-msg91. No exclusions or alternatives are named.
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.
get_msg91_api_docsquickstart-msg91search_msg91_docs
Add one secure layer between your agents and this server.