peaka-mcp-server

Official

by peakacom

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.12.2
Disambiguation5/5
Each tool has a clearly distinct purpose, covering project management, query lifecycle, caching, metadata discovery, connections, and semantic layer operations. No two tools have overlapping responsibilities; even similar tools like peaka_execute_sql_query and peaka_execute_query are differentiated by raw SQL vs. saved query execution.
Naming Consistency5/5
All tools follow a consistent 'peaka_verb_noun' pattern (e.g., peaka_list_projects, peaka_create_query, peaka_delete_cache). The imperative verb is always first, followed by the noun, making the set predictable and easy to navigate for an agent.
Tool Count4/5
With 32 tools, the server covers a broad domain (queries, caches, metadata, connections, semantic layer) and each tool serves a specific function. While the count is high, it is justified by the scope, though some tools could potentially be consolidated (e.g., peaka_create_cache and peaka_create_cache_batch).
Completeness4/5
The tool surface covers CRUD for queries and caches, metadata discovery, connection management, and semantic layer operations. Minor gaps exist—such as missing update for semantic catalogs or project deletion—but the core workflows for querying and caching are fully supported.
Average 4.3/5 across 32 of 32 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 26 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
Describes limited results when tables are not cached, but lacks details on whether the tool supports DML (INSERT/UPDATE/DELETE) or only SELECT. No mention of rate limits, timeout, or output format. Annotations provide no additional safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and well-structured preconditions. Slightly verbose but each part earns its place, guiding the agent effectively.
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?
Missing details on return format, error handling, and whether the tool can modify data. The caching guidance helps, but overall incomplete for a query execution tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (projectId has description, query does not). The description adds no parameter-specific meaning beyond the schema, focusing only on pre-conditions.
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 runs SQL queries on Peaka. It distinguishes from siblings like peaka_list_tables and peaka_get_project_metadata by focusing on execution, but does not differentiate from the similar peaka_execute_query sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step preconditions: check metadata, check caching, warn user, and handle caching. Clear when to use and what to do before invoking.
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?
Annotations already declare readOnlyHint=true, so the description's read-only nature is redundant. However, it adds useful scoping ('given catalog and schema') and a prerequisite workflow, providing moderate extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose, one for usage guidance. No redundant phrases, though it could be slightly more compact. Structure is front-loaded and efficient.
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?
The tool is simple, and the description covers the core action and a key prerequisite (projectId). However, it omits prerequisites for catalogId and schemaName (e.g., calling peaka_list_catalogs and peaka_list_schemas), and does not mention output format or limits, leaving some informational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (projectId has a description, catalogId and schemaName do not). The description adds that the tool requires 'given catalog and schema' but does not elaborate on format, purpose, or how to obtain these parameters, leaving gaps for the agent.
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 clear verb-resource pair ('List all available tables') and specifies scope ('for a given catalog and schema'), distinguishing it from sibling tools like peaka_list_catalogs and peaka_list_schemas.
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 explicitly instructs to call peaka_list_projects first if projectId is unknown, providing a clear usage prerequisite. It does not, however, mention alternatives or when not to use this tool, but the context is sufficient for correct invocation.
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?
Annotations already declare readOnlyHint=true; description does not contradict. Description adds workflow context but no additional behavioral details beyond parameter usage (e.g., no mention of return format or limitations).
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: first states purpose, second provides critical workflow guidance. No filler or redundancy.
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?
Covers essential usage (what it does, prerequisite) but omits return format and error conditions. Since there is no output schema, describing the output would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only projectId has a description). The tool description does not explain catalogId or add semantic value beyond the schema. The workflow guidance references projectId but not its format or meaning.
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?
Clearly states it lists all available schemas for a given catalog, with specific verb and resource. Distinguishes from sibling tools like peaka_list_tables and peaka_list_columns.
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?
Provides explicit workflow guidance: if projectId unknown, call peaka_list_projects first and persist the chosen ID. Lacks explicit when-not-to-use alternatives, but the prerequisite is clearly conveyed.
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?
Annotations already indicate it's not read-only and not destructive. The description adds workflow context (required prior calls) but does not disclose whether the refresh is asynchronous, how long it may take, or any side effects. The behavioral disclosure is adequate but 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?
Two short paragraphs. The first sentence states the purpose, the second provides workflow instructions. No unnecessary words, efficient and front-loaded.
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?
The tool has no output schema, so the description should clarify what the agent can expect as a return value (e.g., status, success/failure). It does not. Parameter documentation is decent, but the lack of result description leaves a gap for an action-oriented tool.
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%. The description adds context for cacheId (source endpoint) but simply restates the schema for projectId. Since the schema already covers parameters well, the description provides only marginal 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 action ('Trigger a full refresh') and the resource ('existing cache in the Peaka project'), with a specific verb and resource. It distinguishes itself from the sibling 'peaka_refresh_cache_incremental' by specifying 'full refresh'.
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 guidance: request the cacheId from 'peaka_get_cache_statuses', and if projectId is unknown, call 'peaka_list_projects' first. It implies the context for use (full refresh) but doesn't compare with the incremental alternative, which is a minor gap.
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?
Annotations already provide readOnlyHint=true, indicating a read operation. The description adds the 'single call' performance trait but no further behavior details. This is adequate given the annotation coverage.
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 short (two sentences plus an additional paragraph), front-loaded with the core purpose, and no unnecessary words. Every sentence adds value.
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 tool's simplicity (3 params, no output schema), the description covers the core functionality and usage context. It could mention the return type, but the purpose is clear enough for an agent.
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 description does not need to add parameter semantics. It briefly mentions optional filtering, which aligns with the schema. Baseline score applies.
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 explicitly states that the tool gets metadata for all catalogs, schemas, and tables in a single call. This clearly distinguishes it from sibling tools like peaka_list_catalogs or peaka_list_schemas, which focus on individual resource types.
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 guides when to use the tool (to discover data structure before writing queries) and provides a prerequisite step (call peaka_list_projects if projectId unknown). It does not explicitly state when not to use it, but the context is clear.
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?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds that it lists 'all projects accessible for the user,' which aligns. No additional behavioral details are provided, but the annotations cover the main safety aspect.
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 sentences, directly stating the purpose and usage. No unnecessary words, and the key action is front-loaded. Every sentence adds value.
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 complete for a simple list tool with one optional parameter and no output schema. It explains what it does and why to use it. Minor omission: it does not describe the return format, but the tool name implies a list of projects.
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 has 100% description coverage for the single 'search' parameter, including its behavior (optional case-insensitive filter). The tool description does not add any additional parameter information, so the schema carries the full burden.
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 'List all projects accessible for the user' with a specific verb and resource. It distinguishes from siblings by indicating this is the tool to discover projectIds, which no other sibling does.
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 explicitly says 'Use this tool to discover projectIds, then pass the chosen projectId to subsequent tool calls,' providing clear context for when to use it. However, it does not explicitly state when not to use it or list alternatives, but given its unique role, this is sufficient.
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?
Annotations already indicate non-read-only (readOnlyHint false) and non-destructive (destructiveHint false). Description adds that it triggers a refresh and requires prior calls, but does not detail side effects or async 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?
Concise two-paragraph structure, front-loaded with purpose, followed by essential details. Every sentence adds value without redundancy.
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?
Adequate coverage of prerequisites and action, but missing any mention of return values or async nature since no output schema exists. Could be slightly more complete.
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%, but the description adds procedural context (e.g., 'Use the queryId returned from peaka_list_queries for queries whose queryType is "MATERIALIZED"' and workflow for projectId), enhancing usability beyond schema descriptions.
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 'Trigger a refresh on a materialized saved query' with a specific verb and resource, and distinguishes from siblings like refresh_cache by specifying the query type.
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?
Provides explicit guidance on prerequisites (projectId, queryId from peaka_list_queries for MATERIALIZED type) and instructs to call peaka_list_projects if projectId is unknown. Lacks explicit 'when not to use' but clear enough.
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?
Annotations already mark destructiveHint: true, but the description adds specificity: 'Removes the table mapping only; the saved query that backs it is not affected.' This clarifies the exact scope of destruction without contradicting annotations.
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 sentences plus a separate paragraph for usage guidance. No wasted words; information is front-loaded and easy to parse.
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 delete operation with 3 required params and no output schema, the description covers the action, scope, and prerequisite (projectId retrieval). Missing details on return value or side effects, but 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds no new semantic information about parameters beyond the schema, 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?
Description clearly states 'Delete a semantic table from a semantic catalog' and distinguishes that it removes only the table mapping, not the backing query. This differentiates from sibling tool peaka_delete_query which deletes the query itself.
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?
Provides explicit advice to call peaka_list_projects first if projectId is unknown and to remember the chosen ID. However, it does not explicitly state when to avoid this tool or suggest alternatives beyond projectId retrieval.
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?
Annotations already indicate readOnlyHint=true. The description adds that the response is an open-ended object map, providing context beyond what annotations offer. No contradictions.
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: two short paragraphs. First paragraph explains purpose and response format, second provides prerequisite workflow. No unnecessary words.
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 tool's simplicity (two required params, no output schema), the description covers purpose, response shape, and a prerequisite. It could mention that catalogId comes from peaka_list_catalogs, but not necessary for completeness.
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% with descriptions for both parameters. The description does not add extra semantic detail beyond the schema, so 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 explicitly states the tool gets table relationships (foreign keys) for a catalog, using specific verbs and resource. It distinguishes from sibling tools like peaka_list_tables or peaka_get_table_statistics by focusing on JOIN construction.
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 advises using this tool for JOIN construction and suggests calling peaka_list_projects first if projectId is unknown. However, it does not explicitly state when not to use it or compare with alternative tools like peaka_get_table_statistics.
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?
Annotations already indicate read-only. The description adds return value details and prerequisite steps. No mention of destructive effects, but none expected. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with clear front-loading of purpose. Could be slightly more structured, but no unnecessary words.
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?
Covers prerequisites and projectId discovery, but lacks details on error handling, exact return format (though partial), and parameter value sources. Adequate for a read-only listing tool.
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?
Only 25% schema description coverage; the description provides context for obtaining projectId and hints for other parameters indirectly, but lacks explicit semantics for catalogId, schemaName, and tableName.
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 lists all columns for a given table and specifies return values (names, data types, constraints). It distinguishes from siblings like peaka_list_tables by focusing on columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call peaka_get_project_metadata first to discover available catalogs, schemas, and tables, and to call peaka_list_projects if the projectId is unknown. Provides clear context for usage.
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?
Annotations declare readOnlyHint=true, and description confirms read-only listing. No additional behavioral details (e.g., pagination, rate limits) beyond return structure, but consistent.
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 paragraphs: one for purpose, one for usage. Front-loaded with core function, no superfluous text.
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?
Tool is simple; description covers purpose, return content, and required parameter workflow. Lacks mention of pagination, but overall sufficient for correct invocation.
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 covers 100% of parameters; description adds practical guidance on how to obtain projectId, which is valuable context 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?
Clearly states 'List all saved queries' with verb 'list' and resource 'saved queries', distinguishes from siblings like peaka_get_query (single query) by scope.
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?
Explicitly advises to retrieve projectId via peaka_list_projects if unknown, providing prerequisite workflow. Lacks direct comparison to alternative list tools like peaka_list_schemas, but context is clear.
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 adds behavioral context beyond the annotations by explaining that caching stores data locally to improve query performance, and that schedule expressions are optional at creation time. It does not contradict the annotations (readOnlyHint=false, destructiveHint=false). It could be richer on side effects or return behavior, but the provided context is useful.
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, with the core purpose in the first sentence, followed by an essential clarification about schedules, and a practical workflow note. No wasted words; each sentence contributes useful information.
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?
The description covers key workflow steps (projectId discovery) and schedule semantics, but it does not explain what the tool returns (e.g., cache ID or status) or mention how to verify creation success. Given there is no output schema, this is a notable gap. It also omits any prerequisites or failure modes, though the operation is a non-destructive create.
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 description explains ISO-8601 duration formats and examples (PT6H, P1D, P7D, P30D), adding meaning to the schedule parameters. It also clarifies that schedules can be omitted initially and set later. For projectId, it gives process guidance (list projects first). Required params like catalogId, schemaName, and tableName are not explicitly described, relying on their names, but the description compensates for the 50% schema coverage.
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 opens with 'Create a cache for a table in the Peaka project,' which clearly identifies a specific verb, resource, and scope. It implicitly differentiates from sibling tools like peaka_update_cache by noting schedule expressions can be set later, and from peaka_create_cache_batch by focusing on a single table.
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 concrete when-to-use guidance: it tells the agent to call peaka_list_projects first if the projectId is unknown and to ask the user which project to use. It also points to peaka_update_cache for setting schedule expressions later. However, it does not explicitly contrast with create_cache_batch or mention scenarios where caching is inappropriate.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false; description adds that it returns the created catalog including its id, which is useful but not comprehensive. No contradictions.
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 sentences plus usage note; no wasted words, well-structured with purpose first then usage guidance.
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 simple create with two parameters and no output schema, description covers purpose, return value, and prerequisite step adequately.
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% description coverage for both parameters; description adds usage context for projectId but no extra meaning for name beyond schema. Baseline is 3.
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?
Description states 'Create a semantic catalog' with a clear verb and resource, and explains what a semantic catalog is, distinguishing it from sibling tools like peaka_create_semantic_table.
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?
Provides explicit guidance: if projectId is unknown, call peaka_list_projects first and ask user. Lacks explicit when-not-to-use or alternatives, but context is clear.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description reinforces the destructive nature by stating 'Delete', but does not add additional behavioral details (e.g., irreversibility). Given the annotation coverage, this is adequate.
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 three sentences with zero fluff. It front-loads the purpose, then gives a usage hint, and finally a workflow step. Every sentence earns its place.
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 simple delete tool with two parameters, annotations, and no output schema, the description covers the action, parameter sources, and a necessary prerequisite. Nothing essential is missing.
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?
Both parameters have descriptions in the schema (100% coverage). The description adds value by specifying the source for queryId ('returned from peaka_list_queries') and implying the need to retain projectId across calls.
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 explicitly states 'Delete a saved query from the Peaka project' with a specific verb and resource. It distinguishes from sibling tools like peaka_create_query or peaka_get_query by focusing solely on deletion.
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 when-to-use guidance: 'Use the queryId returned from peaka_list_queries.' It also includes a prerequisite action: 'If you do not already know the projectId... call peaka_list_projects first.' It lacks explicit exclusion of alternative tools, but the context is sufficient.
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?
Annotations declare readOnlyHint=true, and description confirms it returns statistics. Description adds context about distinctFraction output, which is beyond annotations. No contradiction, but annotations already cover read-only nature.
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 succinct paragraphs: first explains what the tool does, second provides usage guidance. No unnecessary words, well-organized.
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 adequately explains the tool's purpose and output (distinctFraction) and includes usage flow. Since no output schema exists, it covers return values sufficiently but could mention the full return structure (identifiers + stats) more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only projectId has a description). The description does not elaborate on catalogId, schemaName, or tableName beyond their names. With low schema coverage, the description should compensate but does not.
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 it retrieves column-level statistics for a table, specifically per-column distinctFraction, with clear purpose for cardinality estimation and query optimization. This distinguishes it from sibling tools like peaka_list_tables or peaka_list_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call peaka_list_projects first if projectId is unknown and to remember the chosen projectId. This provides clear when-to-use and prerequisite 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?
Annotations already provide readOnlyHint=true, and the description aligns with that by stating 'list'. No additional behavioral details beyond the annotation are provided, and no contradictions.
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-loading the purpose first and usage guidance second. Every sentence is necessary, no redundancy or fluff.
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 simple listing tool with one required parameter and readOnlyHint, the description covers purpose, return content, and usage prerequisites. No output schema exists, but the description mentions what is returned, making it 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?
The single parameter projectId is fully described in the schema (100% coverage), so the description adds limited value. It does add context about when to call peaka_list_projects to obtain the projectId, which is helpful but not essential for parameter meaning.
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 resource 'catalogs', distinguishing it from sibling tools like peaka_list_schemas and peaka_list_tables. It specifies what is returned: catalog names, types, and connection info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call peaka_list_projects first if projectId is unknown, and to ask the user for the project. Also advises remembering the projectId for subsequent calls. This provides clear when-to-use and prerequisites.
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?
Annotations already provide readOnlyHint=true, so agent knows it's safe. Description adds that the tool queries a vector store and advises to remember projectId. No contradictions. Could mention return limits but overall good.
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 with front-loaded main action, then conditional logic. Every sentence is necessary and clear. No wasted words.
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?
While the description covers purpose and usage, it lacks details about return format (e.g., what exactly is returned, whether it's one or multiple matches). Without output schema, more specificity on the result would improve completeness.
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 2 required parameters with 50% coverage (projectId described, query not). Description adds context: projectId can be obtained via peaka_list_projects, and query is a question to search. This partially compensates but does not fully describe query format.
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 it queries question/sql pairs from Peaka's golden sql vector store, using specific verb 'query' and resource 'golden sql vector store'. It distinguishes from siblings like peaka_execute_sql_query and peaka_list_queries by focusing on retrieval of existing pairs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use this tool first to find an existing matching query; if not found, use other tools. Also provides prerequisite: if projectId is unknown, call peaka_list_projects first. This clearly tells when to use and when not to use.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, meaning the description must clarify behavior. It states the tool creates a new query (write but not destructive) and returns an ID for future execution, adding lifecycle context beyond annotations. It does not detail side effects on existing resources, but the creation behavior is clear.
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 plus a focused paragraph on projectId prerequisites. Every sentence adds value, no fluff, and important information is front-loaded.
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 covers the main purpose, return value, and a critical prerequisite (projectId). For a 5-parameter creation tool with no output schema, it is mostly complete. The distinction between PLAIN and MATERIALIZED query types is left to the schema, which is acceptable. The description could have mentioned the schedule parameter's purpose, but the schema describes it.
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?
With 100% schema coverage, the baseline is 3. The description does not elaborate on parameter meanings beyond the schema, except for a usage hint about projectId. The schema already provides adequate descriptions for all parameters including the nested schedule.
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 'Create' with the resource 'named, saved query' and identifies the Peaka project's semantic layer. It also mentions the return value (query object with ID) and how it connects to peaka_execute_query, distinguishing it from siblings like peaka_get_query or peaka_execute_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling peaka_list_projects first if the projectId is unknown, and to ask the user for confirmation—providing clear when-to-use guidance and a direct alternative tool reference.
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?
Annotations (readOnlyHint=false, destructiveHint=false) indicate this is a non-read, non-destructive operation. Description adds that the table is a queryable view over an existing saved query, clarifying its nature beyond annotations.
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 clear paragraphs: first explains core purpose, second gives usage guidelines. Front-loaded with the main action. 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?
Covers prerequisites and parameter sources. Lacks return value information (e.g., whether it returns an ID or success status), but given no output schema, this is a minor gap. Overall sufficient for an agent to invoke 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?
Schema coverage is 100% with descriptions for all parameters. Description adds workflow context for obtaining parameter values (e.g., how to get queryId, catalogId, projectId), which goes beyond the schema descriptions.
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?
Clearly states the verb (create), the resource (semantic table backed by a saved query), and the context (catalog/schema/table become a queryable view). Distinguishes from sibling tools like peaka_create_semantic_catalog and peaka_delete_semantic_table.
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?
Explicitly instructs to obtain queryId via peaka_create_query or peaka_list_queries, catalogId via peaka_create_semantic_catalog or peaka_list_catalogs, and projectId via peaka_list_projects. Provides a clear workflow. Lacks explicit when-not-to-use, but implied by prerequisites.
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?
Annotations only provide a title, so description carries full burden. 'Execute' implies mutation but no details on side effects, idempotency, error handling, or response format. Adequate but limited.
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, front-loaded with main action. No wasted words.
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?
No output schema, but description gives sufficient context for usage. Could mention expected output (e.g., query results) but not critical given low complexity.
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 describes projectId but not queryId. Description adds that queryId is a saved query ID and tells how to find it. Compensates for the 50% coverage.
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?
Clearly states the tool executes a saved query by ID. Distinguishes from siblings like peaka_execute_sql_query (raw SQL) and peaka_get_query (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: use peaka_list_queries to find IDs, and if projectId unknown, call peaka_list_projects and ask user. Includes step-by-step workflow.
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?
Annotations already indicate readOnlyHint=true. The description adds value by enumerating the possible statuses (e.g., COMPLETED, FAILED) that the tool can return, helping the agent understand expected outcomes. No contradictions.
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 short paragraphs: first states purpose and statuses, second gives usage guideline. Every sentence is essential. Front-loaded with purpose.
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 status check tool with no output schema, the description covers purpose, statuses, and a key precondition (projectId). Could mention what happens if no job exists, but overall adequate given low 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?
Schema description coverage is 100%, so the schema already documents both parameters. The tool description does not add new meaning beyond what is in the schema property descriptions.
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 ('Check') and resource ('metadata refresh job for a specific catalog'), and lists possible statuses. It is distinct from sibling tools that handle queries, caches, or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instruction on when to call peaka_list_projects first if projectId is unknown, and tells the agent to remember the chosen projectId. This gives a clear when-to-use and a concrete alternative.
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?
Annotations already mark readOnlyHint=true, so the read-only nature is clear. The description adds value by detailing the returned fields (displayName, inputQuery, queryType, auto-refresh schedule). It does not contradict annotations.
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 short paragraphs: first states purpose and return fields, second gives actionable workflow guidance. No extraneous information; every sentence 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?
For a simple read tool with no output schema, the description covers what the tool returns and how to obtain required parameters. It lacks error scenario details but is sufficient given the tool's simplicity.
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% (both parameters described in the input schema). The description does not add extra parameter-level semantics beyond what the schema already provides. 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 starts with 'Read a single saved query by its ID,' which clearly states the action (read) and the resource (saved query). It lists return fields (displayName, inputQuery, queryType, auto-refresh schedule), distinguishing it clearly from sibling tools like peaka_execute_query or peaka_delete_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: if projectId is unknown, call peaka_list_projects first and ask the user; remember the chosen projectId. It also hints that queryId comes from peaka_list_queries. This leaves no ambiguity about prerequisites and when to use the 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?
Annotations declare idempotentHint=true and destructiveHint=false; description adds value by specifying that schedule is only for materialized queries and ignored for plain ones, plus the at-least-one constraint. No contradiction with annotations.
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 with two paragraphs: first introduces purpose and constraints, second offers usage guidance. Every sentence adds value, no redundancy.
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 mutative tool with 5 parameters and no output schema, the description is fairly complete: covers purpose, param constraints, conditional behavior, and prerequisite. Could explicitly state that update is partial (only provided fields change), but implied.
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 covers 100% of parameters with descriptions. The description adds the important constraint that at least one of displayName, inputQuery, or schedule must be provided, which is not in the schema. Also provides guidance on projectId retrieval.
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 updates an existing saved query, specifying adjustable fields: displayName, SQL body, and auto-refresh schedule. It distinguishes from siblings by focusing on 'update' vs create/delete/refresh tools. The at-least-one constraint further clarifies 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 gives a clear prerequisite: call peaka_list_projects first if projectId is unknown. However, it does not explicitly compare with alternatives like peaka_create_query or peaka_refresh_materialized_query, though the name and context infer usage.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful context by revealing the batch behavior ('avoids partial-failure states') and confirming that each item supports the same schedule expressions as peaka_create_cache. It does not detail error handling or side effects, but with annotations covering the basic safety profile, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence, followed by usage comparison, schedule compatibility, and a necessary prerequisite note. All sentences contribute information; the only minor redundancy is repeating schedule examples already present in the schema, but this aids usability.
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 rich schema (100% parameter coverage) and annotations, the description covers purpose, when to use, batch semantics, and projectId handling. There is no output schema, so mentioning return values would be helpful, but the absence is not critical for a create action with clear side effects. Sibling tools like peaka_get_cache_statuses suggest follow-up monitoring, but this is not explicitly referenced.
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%, providing baseline clarity for projectId and items. The description adds value by linking schedule parameters to peaka_create_cache and reiterating ISO-8601 examples (PT6H, P1D, etc.), reducing ambiguity. It also supplies practical guidance for projectId resolution, which the schema alone does not offer.
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 specific action: 'Create caches for multiple tables in a single call.' It differentiates from the sibling peaka_create_cache by explicitly positioning this as the batch alternative for many tables, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this instead of repeated peaka_create_cache calls when caching many tables' and highlights the benefit of avoiding partial-failure states. It also instructs users to call peaka_list_projects if the projectId is unknown, covering prerequisites and fallback behavior.
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 that 'the response shape varies by connection type — only the type field is guaranteed', which adds value beyond the readOnlyHint annotation. While it doesn't cover other aspects like authorization or rate limits, the behavioral context about response variability is helpful for an 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 three sentences, each earning its place: purpose, key behavioral note, and usage workflow. It is front-loaded with the main action, and no unnecessary words are present.
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 read-only get tool with two parameters and no output schema, the description covers all necessary context: what it does, how responses vary, and how to obtain required IDs. It is fully sufficient without over-explaining.
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% with both parameters described. The description adds minimal extra semantics beyond the schema; it mentions how to obtain the connectionId via peaka_list_connections, but that is more usage guidance than parameter clarification. 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 'Get connection-specific configuration detail for a data source connection', using a specific verb and resource. It distinguishes from the sibling tool peaka_list_connections by noting that the response shape varies by connection type. This is a clear and specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use peaka_list_connections to discover the connectionId, and provides a workflow for projectId: if unknown, call peaka_list_projects and ask the user. It differentiates usage from other tools and gives decisive when-to-use guidance.
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?
Discloses key behaviors beyond annotations: asynchronous execution, long-running, returns immediately, and need to poll status. Annotations only indicate non-readOnly and non-destructive, so description adds significant value.
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?
Concise two-paragraph structure with front-loaded purpose and behavior, followed by usage tips. No redundant sentences; every sentence is informative.
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?
While the description covers trigger and polling, it does not specify the return value (e.g., whether it returns a refresh ID). Given no output schema, this omission slightly reduces completeness.
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 baseline is 3. The description adds practical guidance (e.g., ask user for projectId) but does not add new semantic meaning beyond what the schema 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 clearly states the action ('Refresh project metadata for a specific catalog') and resource, distinguishing it from sibling tools by emphasizing its asynchronous, long-running nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('only when a data source has structurally changed'), when not to use (implied not for routine), and provides step-by-step guidance on prerequisite calls and polling status.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a non-destructive mutation. The description adds that it updates an existing cache and only fetches new/changed rows, which implies no destructive changes. No contradictions. However, it does not discuss error handling or what happens if the cache does not exist, which could be improved.
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 plus a short workflow paragraph. Every sentence adds value—purpose, source of cacheId, and projectId resolution. No redundant or vague language.
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 tool has no output schema, the description could clarify the return value (e.g., success indicator or updated cache status). However, parameters are fully covered, and the workflow context is complete. The tool's purpose is straightforward, and missing output details are a minor gap.
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% with standard descriptions. The description adds value by specifying that cacheId comes from peaka_get_cache_statuses and providing a workflow to obtain projectId via peaka_list_projects if unknown. This goes beyond the schema's static descriptions, giving the agent actionable context.
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 that the tool triggers an incremental update on an existing cache, fetching only new/changed rows. It distinguishes itself from the sibling tool peaka_refresh_cache_full by noting it is much faster. The verb 'trigger' and resource 'cache incremental update' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (for fast incremental updates) and gives preconditions: use the cacheId from peaka_get_cache_statuses. It provides a workflow: if projectId unknown, call peaka_list_projects and ask the user. This guides the agent in correct invocation, including the need to retain the projectId for subsequent calls.
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?
The description goes well beyond the annotations by disclosing that the endpoint replaces (not merges) schedules, requiring both schedules to be supplied in full. It also warns that the backend may clamp the schedule and the response reflects the actual applied value. This is valuable behavioral context not inferable from readOnlyHint/idempotentHint/destructiveHint.
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: a first paragraph explaining purpose and key semantics, a second paragraph with workflow guidance. Every sentence adds necessary information without redundancy.
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 there is no output schema, the description explains what to check in the response (the applied schedule, which may be clamped). It also covers projectId acquisition. While it doesn't detail error handling or exact response format, it provides enough for an agent to use the tool 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 input schema already documents each parameter thoroughly with examples. The description adds the global constraint that both schedules must represent the full intended state (replace semantics) and provides ISO-8601 duration examples. This goes beyond the schema's per-parameter descriptions, so it earns a 4.
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 updates cache settings on an existing cache, specifically the schedules. It distinguishes itself from sibling tools like create_cache, delete_cache, and refresh_cache_full/incremental by focusing on replacing schedule configuration.
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 usage context: it tells the agent to call peaka_list_projects first if projectId is unknown and to ask the user. It also implies this is for modifying existing caches rather than creating or deleting them. However, it does not explicitly mention alternatives for other operations, so it's not a full when/when-not.
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 adds context beyond the destructiveHint annotation by clarifying that the cache is removed entirely but the underlying table is not affected. It does not mention other behavioral traits like authorization or rate limits, but given the tool's nature, this is sufficient.
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 with no wasted words. It starts with the core purpose, then adds the key behavior note and usage guidance in a clear, organized manner.
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 simple delete tool with two required parameters and no output schema, the description is complete. It covers the action, side effects, parameter sourcing, and prerequisite procedures, meeting all informational needs.
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?
Although the schema covers 100% of the parameters, the description adds value by explaining where to obtain the cacheId (from peaka_get_cache_statuses) and providing a workflow for the projectId, which helps the agent understand the parameters' origins and usage.
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 (delete), resource (cache in Peaka project), and explicitly says the underlying table is not affected, distinguishing it from sibling tools that delete queries or other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool (when you have cacheId from peaka_get_cache_statuses) and includes a fallback for obtaining the projectId (call peaka_list_projects first), effectively telling the agent how to proceed.
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?
Annotations already declare readOnlyHint=true, so the description does not need to repeat safety. It adds useful behavioral details (returns state, history, progress) without contradicting annotations.
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 paragraphs: first states purpose, second provides usage guidance. Every sentence adds value with no redundancy.
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?
Despite no output schema, the description explains the return content (caching state, execution history, progress). This is sufficient for a read-only tool with clear annotations.
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% for the single parameter projectId. The description adds context by explaining the workflow requirement (list projects first), which goes beyond the schema description.
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 'Get', the resource 'cache statuses for tables', and specifies the returned data: caching state, execution history, and progress. This distinguishes it from sibling tools like peaka_get_materialized_query_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: instructs to call peaka_list_projects first if projectId is unknown, and to remember the chosen projectId. This addresses a common prerequisite and helps the agent use the tool correctly.
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?
Annotations already declare readOnlyHint=true, so description need not repeat safety. It adds context on return values and parameter behavior (two modes), which is additional transparency beyond annotations.
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, no wasted words. Front-loaded with purpose, then parameter behavior, then workflow guidance. Perfectly concise.
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?
Despite no output schema, description specifies return fields (status, execution times, schedule settings). Covers both modes and prerequisite workflow. Sufficient for an agent to use 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?
Schema coverage is 100% so baseline 3. Description adds value: clarifies queryId source (peaka_list_queries with MATERIALIZED type) and workflow for projectId. These enrich meaning beyond 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?
Description uses specific verb 'inspect' and resource 'auto-refresh state of materialized saved queries'. Clearly distinguishes from siblings like peaka_refresh_materialized_query (which refreshes) and peaka_get_query (which gets query definition). Specifies return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use queryId (single) vs omit (list all). Provides critical prerequisite: if projectId unknown, call peaka_list_projects first and confirm with user. This is high-value 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?
Annotations declare readOnlyHint=true, and the description reinforces a read-only list operation. It adds details about returned fields but doesn't contradict annotations.
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 short paragraphs, each with a distinct purpose: purpose+returns and usage guidance. No filler, front-loaded with the core action.
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 simple list tool with one parameter and no output schema, the description covers purpose, return fields, usage guidance, and references a complementary sibling — complete for effective use.
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 covers the projectId parameter with a brief description, but the description adds significant value by explaining how to obtain the projectId (via peaka_list_projects) — essential for correct usage.
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 lists data source connections, specifies what it returns (id, name, type, callback URL), and distinguishes it from siblings like peaka_get_connection_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (discover data sources), pairs with peaka_get_connection_detail, and instructs on obtaining projectId via peaka_list_projects and user confirmation.
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:

[![peaka-mcp-server MCP server](https://glama.ai/mcp/servers/peakacom/peaka-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/peakacom/peaka-mcp-server)

Score Badge

Copy to your README.md:

[![peaka-mcp-server MCP server](https://glama.ai/mcp/servers/peakacom/peaka-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/peakacom/peaka-mcp-server)

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/peakacom/peaka-mcp-server'

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