cypher_context_pack
Return the code-orienteering scope for an intent keyword.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| npub | No | ||
| keyword | Yes | Intent keyword from the issue, e.g. 'npub proof', 'books health'. | |
| dpop_token | No |
cypher-mcp
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- Added
- Removed
- Added
- Removed
- Added
- Removed
- Added
- Removed
- Added
- Removed
- Added
- Removed
- Added
TDQS
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication requirements, rate limits, or whether the operation is read-only. The description is minimal and leaves the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is underspecified and lacks front-loaded key information. It sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should indicate the structure of the return value. It only says 'scope', which is vague. Given the complexity and number of sibling tools, the description is insufficient for the agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 1 of 3 parameters has a schema description (keyword). The description adds no extra meaning beyond the schema; it mentions 'intent keyword' but does not explain the 'npub' or 'dpop_token' parameters. With low schema coverage (33%), the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource but 'code-orienteering scope' is unclear and not standard terminology. It fails to explicitly distinguish this tool from many sibling tools that may also return scopes or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus any sibling tools. The description does not mention any context or criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
C2.7/5.0
Disambiguation2/5
The set is heavily clustered: audit_why_exists, explain_capability, suggest_capability_why, and authorize_capability_why all answer the same basic 'why does this capability exist?' question and differ mainly in provenance/authority. Many status and provenance tools (adoption_status, session_status, service_status, issue_provenance, pr_provenance, symbol_provenance, service_provenance) also blur together without close reading.
Naming Consistency4/5
The overwhelming majority of tools follow a predictable cypher_verb_noun pattern in snake_case, which provides strong naming consistency across a very large surface. Minor deviations such as cypher_oracle_about, cypher_oracle_how_to_join, cypher_which_service_handles, and cypher_what_realizes_capability are noticeable but do not break the overall pattern.
Tool Count1/5
112 tools is an extreme count for a single MCP server, regardless of how well the clusters are named; it heavily burdens tool selection, context, and agent discovery. The set spans unrelated domains including payments, coupons, credentials, provenance, issues, patents, queries, pricing, and NOS transformations, which should be split into separate focused servers.
Completeness4/5
Many domain clusters have strong lifeycle coverage: COUPs have mint/list/update/delete/redeem, credentials have courier delivery/box status/update/delete/forget, and the named-query catalog has full CRUD plus published-tool management. Minor gaps exist—e.g., no generic list_services, no delete for capabilities, and no close/resolve action for issues—but most flows have no outright dead end.