TOCA MCP Server

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., toca.workflow.create vs toca.workflow.get vs toca.workflow.advance). The exception is toca.system.health versus toca.verify—both touch on readiness/state but from different angles. Minor overlap is acceptable.
Naming Consistency5/5
All tool names follow a consistent pattern of 'toca.<domain>.<verb>' with clear verbs (get, create, advance, query) and nouns (capability, workflow, approval, audit, event). No mixing of styles or conventions.
Tool Count5/5
12 tools is well within the ideal 3-15 range. Each tool covers a distinct operation across core domains (system, capabilities, workflows, approvals, audit, events), and the count feels appropriately scoped for the server's purpose.
Completeness3/5
The server covers key operations but has notable gaps: workflow lacks an update/abort/delete, approval only has create/get (no approve/deny), and there is no event publishing—only reading. The execute tool is comprehensive but may serve as a generic workaround, yet missing lifecycle operations could still cause agent failures in certain flows.
Average 3.2/5 across 12 of 12 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 919 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint: false, openWorldHint: false, idempotentHint: false, destructiveHint: false), so they provide no safety or side-effect context. The description says 'apply a transition', implying a mutation, but it does not explicitly state that this tool changes workflow state, nor does it mention any irreversible effects, authorization requirements, or return characteristics. The only disclosure is that it is 'evidence-bearing', which is unexplained.
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 sentence and is not verbose, but it is severely under-specified. For a tool with eight distinct action variants, a one-sentence generic statement is not appropriately sized or structured. It lacks any enumeration or breakdown, and it does not front-load key information about the different transitions available. This is more under-specification than concise efficiency.
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?
Given the tool's complexity (oneOf schema with 8 actions, many required parameters, no output schema), the description is grossly incomplete. It fails to mention the existence of multiple action types, the requirement for evidence on every transition, the different parameter sets per action, or any side effects. An agent would have no idea how to choose the correct action or what this tool accomplishes beyond a vague 'transition'.
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% (as per input signal), so the baseline is 3. The schema defines all parameters and constraints, but it provides no semantic explanation of what each action does or how parameters like 'evidence' or 'errorCode' are used. The description adds no additional meaning, but since the schema itself is complete in structure, a score of 3 is appropriate per the rubric.
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 'Apply one explicit, evidence-bearing transition through the existing durable workflow engine' is vague. It names a general concept ('transition') but does not specify the concrete actions (e.g., COMPLETE_STEP, FAIL_STEP, RETRY_STEP, etc.) or the resource being acted upon. It does not distinguish this from sibling tools like toca.execute or toca.workflow.create, making it unclear when this tool is the right choice.
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?
There is zero guidance on when to use this tool versus alternatives. No mention of prerequisites, intended scenarios, or exclusions. The description does not even hint at the fact that the tool supports eight distinct transitions, let alone when to use each. This is a complete absence of usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds no behavioral context beyond the annotations: it does not explain what side effects occur, whether it can be safely retried (idempotency is mentioned as a step but not described), what happens on failure, or what 'audit' means. There is no contradiction, but the description's cryptic phrasing ('provider read-back') offers little actionable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, brief, but it is a terse list of technical jargon without context. It is not 'concise' in the meaningful sense; it is under-specified. It does front-load the main verb 'Execute', but the rest is opaque.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no parameter descriptions, rich annotations like openWorldHint and idempotentHint), the description is severely incomplete. It does not explain return values, error states, or how this relates to the approval and workflow siblings. The agent would likely need to consult capability descriptions or documentation to use this tool correctly.
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 0%, so the description must compensate. It does not explain the meaning of capabilityId, payload, correlationId, or approvalId. For example, it doesn't clarify what a 'capability' is, what format payload should take, or how to obtain an approvalId. The description's mention of 'typed schema' and 'approval' hints at the payload and approvalId, but it is too vague to help an agent construct a valid call.
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 is a dense list of internal resolution steps ('Resolve identity, capability, typed schema, policy, risk, approval, idempotency, handler, provider read-back and audit') but fails to state the actual verb and resource: what does 'execute' do? It implies executing a capability, but the description reads like an implementation checklist rather than a user-facing purpose. It does not clearly distinguish from siblings like toca.verify or toca.workflow.advance, which are also execution-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to use toca.workflow.create, toca.approval.request, or toca.verify instead. The list of resolution steps implies it is the final execution step after approvals, but this is not explicitly stated, leaving the agent to guess context.
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 convey the broad safety profile (not read-only, not destructive, not idempotent), and the description adds useful binding context about the payload and authenticated requester. However, it does not disclose side effects, required permissions, or response behavior, so the added behavioral value is modest.
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 a single front-loaded sentence with no filler; every word contributes. It is concise but perhaps too terse given the schema's complete lack of parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation/request tool with five required parameters, no output schema, and sparse annotations, so a one-sentence purpose statement is insufficient. It lacks usage conditions, parameter detail, and return or side-effect information, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across five required parameters, and the description names none of them. The phrase 'exact typed execution payload' gestures at one parameter but leaves capabilityId, correlationId, expiresAt, and evidence entirely unexplained.
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 a concrete resource, 'formal ApprovalRecord,' and adds scoping constraints ('exact typed execution payload,' 'authenticated requester'). This clearly distinguishes the tool from sibling retrieval tools like toca.approval.get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to request an approval versus using sibling tools such as toca.workflow.create, toca.execute, or toca.verify. The description implies a creation workflow but offers no exclusions, prerequisites, or explicit usage context.
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 read-only and idempotent behavior; description adds an implementation note about not materializing tools, but no further transparency.
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?
Single sentence, concise, but could be clearer about the purpose of the 'without materializing' clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No mention of return values or expected output, and parameter semantics are missing, so incomplete for a search tool.
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?
None of the parameters (limit, query, routeId, provider, executableOnly) are explained in the 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?
Clearly states it searches the capability catalog, distinguishing from sibling tools like describe or workflow creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this search versus other tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds a mention of checking for side effects, but it does not disclose further behavioral details or potential edge cases. It does not contradict the annotations, so it is acceptable but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is well-structured and easy to read. It conveys the essence without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description offers context about what the tool verifies, but it fails to cover parameter meanings and usage guidance. With no output schema and no parameter descriptions, the description is insufficient for a new user to effectively invoke the tool.
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?
The description does not explain any of the five parameters. Since the schema provides no parameter descriptions (0% coverage), this is a critical gap that leaves the user without understanding how to construct the request.
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 verifies three specific aspects: the immutable audit chain, the exact execution descriptor, and fresh provider state for side effects. This is specific and distinguishes it from sibling tools like audit.query and system.health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, scenarios, or conditions that would trigger its use.
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, idempotentHint, and destructiveHint false, so the agent knows this is a safe read. The description adds 'immutable' and 'authenticated tenant boundary', which slightly enhance understanding of behavior but do not contradict annotations. Minimal extra 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core action, resource, and boundary condition. It is well front-loaded with the verb and object, no filler words, and efficiently conveys the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no schema descriptions, the description covers only the correlationId purpose implicitly through 'by correlation'. It omits the meaning of 'limit' (pagination/size) and 'executionId' (execution-scoped filtering). With no output schema, the description should at least clarify parameter usage; it does not. The minimal detail leaves the agent uncertain about how to effectively query the audit ledger.
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 0%, so the description must compensate. It only mentions 'by correlation' which clarifies correlationId's purpose, but entirely omits the role of 'limit' and 'executionId'. The description fails to explain how these parameters influence the query, leaving agent with insufficient guidance for constructing 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 uses a specific verb ('Read'), a clear resource ('immutable audit-ledger records'), and defines the scope ('inside the authenticated tenant boundary'). It clearly distinguishes the tool's function from siblings like toca.workflow.get or toca.event.get, which are not about audit records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternative query tools, nor any mention of exclusions or conditions. While the tenant boundary is a scope constraint, it does not help an agent choose between this and sibling tools like toca.capabilities.search or toca.event.get. The description lacks practical usage context.
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, destructiveHint=false, and idempotentHint=true. The description adds the 'durable' and 'transactional outbox' context, which hints at persistence and eventual consistency. It does not contradict annotations, but could elaborate more on the effects of creating a workflow, such as side effects or state changes. However, with annotations covering safety (non-destructive, idempotent), the description adds reasonable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise, and front-loaded with the main purpose. It wastes no words and gives essential context about durability and transactionality. This is appropriately sized for a JSON description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested steps array) and lack of output schema, the description is too sparse. It does not explain what the tool expects for steps structure, how idempotency works, or what the return value looks like. The annotations help with safety, but the description misses crucial operational details such as default behavior, limits, or required relationships between parameters. An agent would struggle to invoke this correctly without more context.
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 0%, so the description must compensate, but it does not explain any of the 7 parameters. Required fields like routeId, definitionId, steps, idempotencyKey, correlationId, etc., are not described beyond the schema's basic type constraints. The description gives no semantics for parameters, making it hard for an agent to know what values to provide. This is a significant gap.
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 states it creates a durable tenant-scoped workflow using an existing engine and transactional outbox. It clearly indicates the action (create) and resource (workflow), and distinguishes from siblings like get, advance, execute by the creation-focused purpose. However, it could be more specific about the type of workflow or the context (TOCA) beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the creating workflows, but does not explicitly state when to use this tool vs alternatives like toca.execute or toca.workflow.advance. There is no explicit when-not-to-use guidance. Given the sibling list, a clear guideline would help, but it's not entirely missing.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the behavioral trait 'deterministic' and scopes the read to 'surface and persistence readiness' metadata, but it does not disclose output structure or failure semantics; this is acceptable 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?
The entire description is a single front-loaded sentence beginning with the verb 'Return'. It wastes no words and is appropriately compact for a zero-parameter health metadata tool.
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?
Complexity is low: no parameters, no side effects, and annotations cover safety. The description states the output is deterministic metadata around MCP surface and persistence readiness, though it leaves the exact fields of that metadata unspecified; this is still likely sufficient for an agent to select and call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema coverage is effectively complete. With no parameters to explain, the description does not need to add parameter detail, so the baseline score of 4 applies.
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 opens with 'Return', specifying that the tool produces deterministic metadata about 'TOCA Core MCP surface and persistence readiness'. This distinguishes it from sibling tools like capabilities.search or workflow.get, though the jargon 'MCP surface' makes it somewhat less accessible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to call this tool versus alternatives. The name 'health' and the word 'readiness' weakly imply a system-status or pre-flight use case, but there is no concrete when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds useful context about 'canonical' records and the tenant boundary, but it does not disclose behavior for missing IDs or what exactly is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant repetition of the tool name. It is appropriately concise for a simple read operation.
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 one-parameter read tool with strong annotations, the description supplies enough context about scope and record type. However, the lack of parameter semantics and explicit return-value information keeps it from being fully complete.
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?
The schema has one required eventId string with 0% description coverage, and the description never mentions eventId or explains its semantics. The parameter name is somewhat self-explanatory, but the description adds no value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb 'Read' with a clear resource, 'EventRecord', and scopes it to 'one canonical' record inside the 'authenticated tenant boundary.' This distinguishes it from sibling get-style tools like toca.workflow.get and toca.approval.get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for retrieving a single EventRecord by ID and gives context about tenant scoping. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'durable' and tenant-boundary context but does not disclose return shape, not-found behavior, or error semantics; with annotations present, this 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?
Single sentence, front-loaded with the verb and object, no filler, and no repetition of schema or annotation information.
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?
Low complexity (one required parameter, no output schema) and strong annotations make the description sufficient for a simple getter. It could optionally clarify what 'durable workflow' means or behavior for missing IDs, but overall it is complete enough.
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 0% and the description does not mention workflowId or explain how to identify the workflow. The parameter name is self-explanatory, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Read') with a clear resource ('one durable workflow') and scope ('inside the authenticated tenant boundary'), which distinguishes it from sibling mutation tools like toca.workflow.create and toca.workflow.advance.
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 clearly implies a read operation for a single workflow within a tenant context, which is enough to differentiate from create/advance/execute siblings. It does not explicitly name alternatives or exclusions, but the usage 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?
Annotations already establish readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The added value is the access-control disclosure that reads are scoped to records owned by the caller—useful behavioral context not present in the annotations. It stops short of noting failure modes (e.g., 404 vs. 403 on others' records), so not a 5.
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?
A single 8-word sentence that is fully front-loaded with the verb. Every word earns its place, with 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?
For a tool of minimal complexity—1 required param, no output schema, no enums, no nested objects—the description covers the essential ground: the operation, the entity type, and the access boundary. Additional return-format detail would be nice but is not required by output constraints.
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 0% schema description coverage, the description was expected to compensate but does not mention approvalId. However, the resource noun 'ApprovalRecord' implicitly identifies what the ID references, and the single-parameter schema with a self-explanatory name is already clear. The description neither adds nor detracts meaningfully from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read'), a specific resource ('one ApprovalRecord'), and adds a meaningful scope qualifier ('owned by the authenticated requester'). This clearly distinguishes it from siblings like toca.workflow.get and toca.event.get, and conveys it returns a single record rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied via the noun 'ApprovalRecord' and the ownership qualifier. There is no explicit when-to-use vs. alternatives statement, nor any exclusions (e.g., 'for listing use X'). For a simple fetch-by-ID tool this is adequate but not exemplary.
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 establish a safe read profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description is fully consistent with these. It adds genuine value by revealing that input may be an alias subject to resolution and that the return payload carries typed, policy, and lifecycle contract fields — behavior not inferable from the 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?
A single dense sentence of 15 words with zero wasted words. Every phrase carries meaning: 'resolve aliases' (behavior), 'canonical' (output quality), 'typed, policy and lifecycle' (contract shape), 'one' (cardinality). The density is justified by the semantic load, not padding.
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 lookup tool with one string parameter, no output schema, and strong annotations, the description is complete. It conveys the resolution behavior, the canonical nature of the result, and the contract fields returned. Nothing material (auth, error handling, rate limits) is expected at this complexity level for an idempotent read.
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 0%, so the description must compensate for the single capabilityId parameter. It partially does: 'one capability' clarifies singular cardinality and 'resolve aliases' hints that the string may be a valid alias rather than a canonical ID. However, it never explicitly confirms that capabilityId accepts canonical IDs, aliases, or both, leaving the input contract somewhat ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'Resolve aliases and return the canonical typed, policy and lifecycle contract for one capability.' It precisely scopes to a single capability and differentiates from the sibling toca.capabilities.search by emphasizing alias resolution to a canonical form — a distinct read semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through active phrasing: 'Resolve aliases' signals its role as the normalization/lookup endpoint for a single capability, implicitly contrasting with search (for discovery) and the workflow/approval siblings. However, there is no explicit when-to-use, when-not-to-use, alternative naming, or mention of failure behavior for unknown aliases.
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:

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

Score Badge

Copy to your README.md:

[![toca-mcp-server MCP server](https://glama.ai/mcp/servers/luizanunciostoca/toca-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/luizanunciostoca/toca-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/luizanunciostoca/toca-mcp-server'

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