perplexity-control-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Several tools have overlapping functionality: sonar_chat, agent_create, and web_search all involve web-searching capabilities, which could confuse an agent. However, the descriptions clearly delineate their use cases, and the async sonar tools are distinct. Overall, some ambiguity remains but descriptions mitigate it.
Naming Consistency2/5
Tool names are inconsistent in their verb/noun ordering. Some use verb_noun (list_models, estimate_cost), while others use noun_verb (api_key_generate, web_search, sonar_chat). There are consistent sub-patterns like sonar_async_* and api_key_*, but no unified convention across the set.
Tool Count5/5
14 tools is well within the ideal range for a server covering Perplexity's API surface. Each tool addresses a distinct feature area such as API key management, embeddings, search, async jobs, and cost estimation, without feeling bloated or sparse.
Completeness3/5
The tool set covers core workflows for search, chat, embeddings, and API key management, but notable gaps exist. There is no way to cancel an async Sonar job, list existing API keys, or list/delete agents. These missing lifecycle operations could cause agent failures in certain management scenarios.
Average 4/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly discloses the async behavior (returns request_id for polling) and references the POST endpoint. However, it omits any mention of side effects, rate limits, error handling, or whether the job is persisted. It adds basic behavioral context but not enough for a fully informed agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two sentences, and directly front-loaded with the core purpose. It includes the endpoint, the return type, and the intended use case without any redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no annotations, no output schema), the description is far too sparse. It only explains the submit-and-poll flow and misses critical details about message formatting, search filters, or error responses. For a tool with this many options, the description is not sufficient for correct usage in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no parameter explanations. The only parameter-related hint is 'Ideal for sonar-deep-research model', which aligns with the default but does not explain any of the 12 parameters like messages, search filters, temperature, or max_tokens. The description adds virtually no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Submit') and resource ('asynchronous deep research job'), names the exact API endpoint, and distinguishes this from siblings by emphasizing the asynchronous nature and the returned request_id. It is specific enough to be differentiated from sonar_chat or sonar_async_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for async deep research jobs) and explicitly directs the agent to poll with sonar_async_get. It also suggests 'sonar-deep-research' as the target model. However, it does not explicitly state when not to use it or mention synchronous alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions live web grounding and filter capabilities, which are useful, but it does not elaborate on response format, rate limits, authentication requirements, or whether the call is synchronous. Some behavior is disclosed, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose and immediately useful capabilities. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a rich schema with 12 parameters and no output schema, the description does not explain the return structure or how it differs from the async sibling tools. This leaves an agent without critical information for correct invocation and result interpretation, making it inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all parameters, including detailed explanations like the '-' prefix for domain exclusions. The description only restates that domain, recency, and location filters are supported, adding no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs chat completions with live web grounding using Perplexity Sonar models and specifies the endpoint. This distinct verb+resource combination differentiates it from sibling tools like web_search and the async sonar variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for grounded chat conversations but does not explicitly state when to use this tool versus alternatives such as web_search or the async sonar submission tools. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds useful context about full page content retrieval, structured output, and up to 5 parallel queries. However, it does not explicitly state that this is a read-only operation, nor does it disclose rate limits, error behavior, or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action and return type. Every clause adds information: the HTTP method, return structure, parallel query support, filters, and specialized modes. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema), the description does a good job covering the essential behavior: it states the return format, major capabilities, and special modes. It does omit potential details like result ordering, truncation behavior, and error handling, but for a search tool with this level of schema documentation, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description summarizes key parameter groups (domain filters, date filters, academic/SEC modes) and mentions the 5-query limit, but it does not add significant meaning beyond the schema's own parameter descriptions. It serves as a high-level overview rather than adding new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Perform a raw web search'), the resource ('POST /search'), and the specific return format ('structured result objects with URL, title, and text content'). It also names distinctive capabilities (parallel queries, filters, academic/SEC modes) that separate it from sibling tools like sonar_chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance. It mentions the tool is a 'raw web search' which implies a direct search function, but it never references alternatives (e.g., sonar_chat for conversational search) or exclusions. Context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the endpoint and that vectors are returned in base64 format, but omits potential behavioral details such as statelessness, authentication requirements, input limits, or error behavior. The base64 note adds value but the description is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose with endpoint, use cases, and return format. Each sentence earns its place, is front-loaded, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values. It mentions base64 vectors but does not describe the response object structure (e.g., data array, index, usage). For a tool with four parameters and no nested objects, this is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all parameters. The description does not add meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates dense vector embeddings for text strings, with specific use cases (semantic search, similarity, RAG). It does not explicitly distinguish itself from the sibling tool embeddings_contextualized, so it misses the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (semantic search, similarity comparison, RAG) making the intended context clear. However, it does not mention when not to use this tool or suggest alternatives like embeddings_contextualized, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the authentication method (uses PERPLEXITY_API_KEY) and what the tool returns (auth_token, timestamp, token_name). However, it does not mention potential side effects, such as whether the key is immediately active or if there are rate limits, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and every sentence adds useful information: the action, endpoint, return values, and authentication requirement. There is no fluff or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers the action, endpoint, return values, and authentication requirement, which is nearly complete. It could be slightly more explicit about the environment variable being mandatory, but overall it is well-rounded for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter (token_name) with a description, giving 100% schema coverage. The description also mentions 'optional token_name' but does not add meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a new Perplexity API key' with a specific endpoint (POST /generate_auth_token). This distinguishes it from sibling tools like api_key_revoke and api_key_rotate, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its name and function but does not explicitly state when to use this tool over alternatives like rotate or revoke. It provides a prerequisite (PERPLEXITY_API_KEY must be set) but no explicit 'when to use' or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' and 'GET' imply a read-only operation, but it does not explicitly disclose any other behaviors such as authentication, pagination, or rate limits. This is partial but not complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the verb, resource, and endpoint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list endpoint with no output schema, the description is sufficiently complete for basic understanding. It states that it lists all async jobs, but lacks details on response format or pagination; however, these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The baseline for 0 parameters is 4, and the description need not add any parameter-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all async Sonar jobs' with the specific verb 'List' and resource 'async Sonar jobs', and includes the HTTP endpoint 'GET /v1/async/sonar'. This clearly distinguishes it from siblings like sonar_async_get and sonar_async_submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sonar_async_get for retrieving individual jobs or sonar_async_submit for creating them, leaving the agent to infer usage solely from naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: the revoked key 'will immediately stop working' and the action is 'irreversible'. Since no annotations are provided, the description carries the full burden, and these details meaningfully inform the agent of consequences beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences with front-loaded action, endpoint, and immediate consequence. No redundant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple revoke operation with a single parameter and no output schema, the description provides sufficient context: what is revoked, that it's immediate, and that it's irreversible. It does not explain return values, but this is minor for an irreversible action where the main concern is the consequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes auth_token as 'The API key (auth_token) to revoke' with 100% coverage. The tool description does not add extra semantic meaning for the parameter, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Revoke an existing Perplexity API key'. It specifies the resource (API key) and includes the endpoint '(POST /revoke_auth_token)', which makes it distinct from sibling tools like api_key_generate and api_key_rotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (for existing keys) but does not explicitly contrast with alternatives like rotate or generate. It lacks explicit 'when to use' or 'when not to use' guidance, making the usage guidance merely implied rather than clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the core behavioral trait (contextualization) and the input structure. However, with no annotations, it leaves gaps about output format, error behavior, and any restrictions (e.g., number of chunks). It does not explicitly state whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct role: purpose, differentiation, input syntax. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a reader to understand the tool's purpose and how to structure input. However, it omits any mention of return values or how the embeddings are associated with chunks, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds the high-level structure ('each inner array is a document's chunks') which is already present in the schema. It does not add new details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Generate' with a specific resource ('context-aware embeddings for document chunks') and explicitly contrasts with 'standard embeddings', distinguishing it from the sibling tool 'embeddings_create'. The endpoint reference adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for context-aware embeddings where chunks are influenced by surrounding chunks, producing better representations for RAG. This implies the use case (RAG) and contrasts with standard embeddings, but it does not explicitly name alternative tools or give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the async nature and the possible outcome (status or result), but doesn't elaborate on polling behavior, response structure, or error handling. The GET method is mentioned, suggesting read-only, but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that leads with the action and includes the endpoint. No verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the main purpose and outcome. It could benefit from mentioning what the response looks like more concretely, but the 'status or result' phrasing gives an adequate overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage for the single parameter, with a clear description referencing sonar_async_submit. The description text only restates the request_id in the URL, adding no additional semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (status or result of an async Sonar job), and includes the URL pattern. It distinguishes from siblings by specifying a single job via request_id, as opposed to sonar_async_list or sonar_async_submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after submitting an async job and wanting to check its status or retrieve the result. It clearly identifies the target as a specific job, but doesn't explicitly mention alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool supports multi-step reasoning, web search, URL fetching, and custom tools, and notes the required model/preset. However, it does not mention side effects like cost, rate limits, authentication requirements, or the structure of the response. This is modest but insufficient behavioral detail for a create-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a distinct purpose: the first states what the tool does, the second lists capabilities, the third clarifies a key parameter constraint. No fluff, no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, nested objects, and no output schema, the description provides a reasonable high-level overview but lacks information about the response format, error behavior, or how the agent runs (e.g., synchronous vs async). The schema fills parameter details, but the absence of output schema means the description should have explained what the caller receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by stating the critical constraint that one of model, models, or preset must be provided, which is not encoded in the schema's required list (only 'input' is required). This helps the agent invoke the tool correctly despite the schema implying flexibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an agent response using the Perplexity Agent API, with a specific HTTPS endpoint (POST /v1/agent). It distinguishes itself from sibling tools by highlighting multi-step agentic reasoning, web search, URL fetching, and custom function tools, which sets it apart from simple chat or search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when multi-step reasoning or tool use is needed, as opposed to simpler chat/search tools. It also provides a clear usage requirement that either model, models, or preset must be provided. However, it does not explicitly name alternatives or state when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explicitly states that the tool estimates cost 'before sending', implying no request is executed, and describes the return breakdown. It does not cover potential limitations like pricing freshness, but the key safety-relevant behavior is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains zero filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description covers the return structure ('breakdown by input tokens, output tokens, and tool invocations'), which is sufficient for a straightforward estimator. It could mention pricing source or assumptions, but these are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description echoes the parameters (input tokens, output tokens, tool invocations) but adds no new syntax, constraints, or format details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and resource ('USD cost of a request'), clearly stating the tool's function. It distinguishes itself from sibling tools as the only cost estimation tool, with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before sending it' provides clear usage context, indicating when to invoke this tool. However, it does not mention alternatives or explicitly state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly states the sequence (generates, verifies, revokes), the return value (new key and rotation status), and a critical caveat (key shown only once and must be saved). This gives the agent essential information about side effects and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, then detailing the workflow and ending with a critical warning. Every sentence serves a purpose with no filler or redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of a rotation operation, the description covers all essential aspects: the steps performed, the return value, and the one-time visibility of the new key. There is no output schema, but the return value is clearly stated. The description is complete enough for an agent to understand what will happen and what to do afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter (token_name), so the schema fully documents it. The description does not add extra meaning to the parameter, but the baseline for high coverage is 3, and the schema's own description is sufficient. No additional value from the description is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Rotate' with the resource 'API key', clearly distinguishing it from sibling tools like api_key_generate and api_key_revoke by describing the combined workflow (generate → verify → revoke). This is a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when rotating the current API key. It does not explicitly mention alternatives or exclusions, but the workflow description implies it is for replacing an existing key rather than simply generating or revoking. This is clear context without explicit 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently states that the tool 'Makes a minimal test request to the Sonar API,' indicating a low-impact, non-destructive operation. It does not explicitly mention 'read-only' or potential side effects, but the description is clear about the main behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and include only essential details. Every sentence adds value, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description covers the purpose (connectivity and key verification) and the mechanism (minimal request to Sonar API), which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema. According to the rubric, a baseline of 4 is appropriate for 0 parameters, and the description does not need to add parameter semantics because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test API connectivity and verify the configured PERPLEXITY_API_KEY is valid and working.' It uses a specific verb ('test') and resource (connectivity/key), and mentions the underlying Sonar API, distinguishing it from sibling tools like api_key_generate or list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case for when to call the tool (verifying connectivity and key validity), giving the agent context to decide when it is appropriate. However, it does not explicitly mention alternatives or exclusions, so it falls short of an explicit when-to-use vs. when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It transparently states what the tool returns (descriptions, context lengths, pricing) and adds the valuable detail that prices are in USD per million tokens. It implicitly indicates a read-only operation, which is appropriate for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver complete information without any fluff. The main purpose is front-loaded, and the pricing unit clarification is a valuable addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does and the nature of its output. It's a self-contained list operation with no missing contextual requirements like authentication or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameter details. Baseline of 4 applies since no parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available Perplexity models', and specifies the exact information returned (descriptions, context lengths, pricing). This distinguishes it from sibling tools like sonar_chat or api_key_generate, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: whenever a user needs an overview of available models and their metadata. It doesn't explicitly exclude alternative tools, but given the absence of any other listing tool among siblings, the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![perplexity-control-mcp MCP server](https://glama.ai/mcp/servers/itsablabla/perplexity-control-mcp/badges/card.svg)](https://glama.ai/mcp/servers/itsablabla/perplexity-control-mcp)

Score Badge

Copy to your README.md:

[![perplexity-control-mcp MCP server](https://glama.ai/mcp/servers/itsablabla/perplexity-control-mcp/badges/score.svg)](https://glama.ai/mcp/servers/itsablabla/perplexity-control-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/itsablabla/perplexity-control-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server